Agile smagile! - Agile

Uncle Bob stirs the pot again with "Dependency Injection Inversion"

Petar Shomov — Sun, 24 Jan 2010 23:48:53 GMT

Uncle Bob posted what was considered a rather controversial blog post, which basically pointed that just because Dependency Injection is a good thing, does not mean you cannot shoot yourself in the foot with the DI framework. He drew attention to the fact that these frameworks in their desire to be more usable have all kinds of bells and whistles, which you might just stop and think about before you jump in and start using them.

My initial reaction to this post was very positive since I always have considered the DI container something external and (potentially) replaceable. Looking from a DDD point of view (I tend to look from that one, don't I? ;) it is infrastructure which is not central to my apps, which means it should not be meshed with my core code. Hence my tweet:

I liked the point he made: you see, you can do Dependency Injection without a container. I would add, I think everyone who is doing Dependency Injection should do an exercise once in a while - write a small app without a DI container. There are two points in this exercise: one - to make sure one remembers the point Uncle Bob made, and two - to appreciate the DI containers.

Towards the end he says:

Most of the time the best kind of Dependency Injection to use, is the manual kind. Externalized dependency injection of the kind that Guice provides is appropriate for those classes that you know will be extension points for your system.

Not so sure how I feel about this one though. Most of the time I do use DI container unless the app is very very small, but unless I try I will never know, right ;)

Interestingly enough the .NET alpha-geek crowd jumped(and again and again) Uncle Bob on this one. Agreed with him for the most part and bashed him for the quote I just mentioned as well as for his example being too simplistic. I feel they are being a bit arrogant(bashing the Java tooling and all that) but they do have a point though. What do you think?

Introduction to the Core - Core Series Part 1

Pétur Orri Sæmundsen — Mon, 09 Nov 2009 00:18:22 GMT

We have been implementing the idea of a working agreement within teams when we do Scrum consulting. The team develops a list of principles which the team members agree not to break. Popular principles include things like "Respect each other", "Don't be late" and "Say what you think". The working agreement defines a social contract that help people work together. When I was introduced to the idea of a working agreement I immediately liked it since I saw it as a good way for team members to connect better with each other. But that was about it.

More than 6 months ago my Sprettur partner Daði introduced us to the Core by sending a video featuring Jim McCarthy from Agile 2008. I found out that the Core is a system to support a shared vision within a team. It is a working agreement that has been in development for over 10 years and is in version 3.02. Listening to Jim talk about the Core made me realize that the working agreement is the most important aspect of teamwork because it supports a shared vision (even more important than the right development method :) ). I already knew that a shared vision is crucial if a team is to succeed but always had vague ideas about how to get there.

We, the Sprettur guys, have now been using the Core for 6 months now and its power is amazing. Always when we run into trouble in our teamwork it's because we are not using the Core enough or we find out we didn't fully understand how to use it. The Core is so powerful that I have started using it at home with my family :)

The Core defines 11 commitments and 11 protocols. The commitments are similar to the working agreement discussed before but the protocols are procedures to support the keeping of the commitments (more on the protocols later). Following are the 11 commitments which should be read "I promise, X ":

I commit to engage when present.
I will seek to perceive more than I seek to be perceived.
I will use teams, especially when undertaking difficult tasks.
I will speak always and only when I believe it will improve the general results/effort ratio.
I will offer and accept only rational, results-oriented behavior and communication.
I will disengage from less productive situations
I will do now what must be done eventually and can effectively be done now.
I will seek to move forward toward a particular goal, by biasing my behavior toward action.
I will use the Core Protocols (or better) when applicable.
I will neither harm—nor tolerate the harming of—anyone for his or her fidelity to these commitments.
I will never do anything dumb on purpose.

In this series I will go through all the commitments and the protocols and describe how we, the Sprettur guys, have been using them and failing with them.

Lessons learnt the hard way

Petar Shomov — Fri, 02 Oct 2009 22:35:50 GMT

I just got off a large project that one of our customers is running. I will not go into details but it should suffice to say that it is a rather large multi-phase project that is supposed to create the future IT backbone for that customer. Before I move on I though I should stop and analyze what we did right, what went wrong and what can I learn from this experience. And I thought I would share it with you dear reader ;)

1. Deploy by the end of the first month to a user
In large companies there are usually many reasons why a project cannot be deployed: dependency on another project which in turn depends on another project and so on, or someone has to get legal approval for something to be released. Yes, there are many excuses not to deploy, but in the end that's all they are - excuses. The business needs to see value, your team needs to get feedback from real users about the system otherwise you are risking building something no one is interested in and/or the business people loosing their business patience. My future rule of thumb would be - if you have not deployed to actual users by the end of the first month of the project, you need to do get angry and demand this to happen right away.

2. Do not accumulate technical debt, push back on Product Owner who does not understand technical debt
Technical debt(from here on referred to as tech-debt) is hard to explain to product owners that have not programmed. This is understandable and there is no easy way around it. We tried all kinds of metaphors but I don't think we succeeded in communicating what tech-debt is and why it is important. The best approach that I can see working is to negotiate a slice of each sprint to go into paying off tech-debt and demand extra on top of that at the first sign of trouble. Letting it pile and telling yourself that it is ok, that you are going to fix it "later" does not work. Never has, not for me. "Later" the debt is usually so big and the bad stuff has usually spread all over the place and fixing it becomes an all-or-nothing mini-rewrites that are very hard to do and are rather unpleasant and unsatisfying experiences.

3. Do not allow architectural astronauts to tell you what tools to use
It is a strange phenomenon but seems quite persistent: a company becomes mid-sized and someone decides that now they need to unify "how we do things around here". And then an Architect (may be even Chief Architect) is appointed who starts googling and creating a list of tools and technologies allowed to be used. And this is the moment when you start to be told what tools to use to do your job by the guy who has never done your job or it has been a while since he has last done your job. Do not let this happen, say "no" to company politics and demand that you decide what tools to use. The list of tools should be coming from you and the rest of the guys that are working in your organization. Architects can be valuable, but this is not the way. Do not buy into tool vendors based on power point presentations and one day carefully orchestrated demos from the salesman. You and your peers should be making the standard in your company. 'nough said.

4. Manage expectations so that they are achievable
I have come to appreciate marketing as a *very* important aspect of product development. The same product may be perceived as two complete opposites depending on how its being marketed. One thing that I've found out is not wise, is to proclaim that your product will be a universal panacea that will fix all there is to fix. This might sound obvious and plain common sense, but I am mentioning it for a reason: the larger the promise you make, the more difficult is to keep it. So I would advise to do small achievable projects and build software products incrementally and iteratively. And the product owners have always to be on the lookout how to generate value with minimum effort.

Well, I am off to the new project ... ;)

Batman

Daði Ingólfsson — Sun, 01 Feb 2009 21:51:39 GMT

"Já, Scrum lítur vel út, en hvernig eigum við að höndla allar litlu beiðnirnar um hjálp, alla eldana sem við þurfum að slökkva, í þessum sprettum?"

Þetta er ein þeirra spurninga sem oftar en ekki koma upp þegar við erum að byrja að koma teymum af stað með Scrum. Hún á líka fyllilega rétt á sér. Staðreyndin er sú að aðstæður margra teyma eru þannig að það VERÐUR að vera hægt að takast á við það sem ekki er hægt að áætla í upphafi spretts. Mörg teymi sem fara af stað með Agile aðferð, eins og Scrum, lenda nefnilega í því að allar truflanirnar vegna villna í raunumhverfi sem "þarf" að laga NÚNA, símtala frá notendum (innanhúss eða utan) sem vilja breytingar/lagfæringar, o.s.frv., gerir þeim ómögulegt að skuldbinda sig svona og standa við það.

Það eru nokkrar leiðir færar í þessu máli. Þegar ég segir færar á ég við leiðir sem hafa það að markmiði að gera teymi kleift að skuldbinda sig í upphafi spretts til þess að ná settu markmiði og notandasögum því fylgjandi og standa við það. Þær sem ég lýsi iðulega fyrir teymum sem spyrja þessarar spurningar eru

Sérstakt slökkviliðs-teymi
Batman hlutverkið
Nægur slaki í spretti til að leysa óvænt mál (á við stabílli umhverfum).

Ég ætla þó bara að fara í 'Batman' hlutverkið í þessari færslu. Þess ber að geta að ég tók þessa hugmynd úr hinni stórgóðu bók Jim Shore, The Art of Agile Development.

Batman hlutverkið

Í stuttu máli snýst þetta um að teymi ákveður að einn meðlimur þess hafi á sinni könnu að takast á við að slökkva eldana ("batman saves the day!"). Með því veitir Batman hinum í teyminu frelsi til að einblína á það sem áætlað var að gera í upphafi spretts.

Þessu er venjulega stillt þannig upp að teymismeðlimir skiptast á að gegna þessu hlutverki innan hvers spretts. Sum teymi skipta á hverjum degi, önnur nota 2 dagar/3 dagar reglu og enn önnur skipta á vikufresti. Það skiptir í sjálfu sér ekki máli svo lengi sem við reynum að nota reglu sem hentar teyminu og hjálpar því að halda fókus og standa við sínar skuldbindingar.

Batman-inn í teymum sem ég hef unnið með nær yfirleitt að leysa a.m.k. 60-70% af "eldunum" án þess að trufla aðra í teyminu. Eftir því sem þekkingin í teyminu dreifist betur, því hærri verður þessi prósenta.

Hvað segið þið? Eru einhver teymi þarna úti sem nota Batman hlutverkið? Endilega kommentiði á þessa færslu um ykkar reynslu!

Soft as in "Software" - part II (The Fear of Change)

Petar Shomov — Mon, 15 Dec 2008 23:15:18 GMT

In my last post I described my epiphany about the way the business looks at IT (or at least one very possible look) and left off just before I described the common reasons for delivering crappy software. So here they come:

Fear of change
Rigid structure

First, and probably foremost, is the fear of change. The uncomfortable feeling every one of us has felt at one point or another (probably more likely at a lot of points, but may be that's just me ;) ) in his career when he has to change something in code that has been in production. Will it work with all the other components that are deployed? What about the bug that we fixed last month, does it affect the fix in any way? What will happen if it does not work, can I go back to the old version of the code?

These are all questions which we are often quite uncertain about how to answer. How can we eliminate this discomfort?

By building quality in our products and continuously inspecting them for that quality - with unit testing, integration testing, and acceptance testing.

Having nailed down the behavior of your software this way gives you a lot of confidence and eagerness to continue improving and developing your software. Do the green bars mean that you are 100% safe? Definitely not, but now you have a base which will free your mind from trying to remember all the little things you need to make sure your software works as you expect. If you take the time to keep this base growing as your code grows it will allow you to go quite far. The alternative I have seen is where you reach a point where you cannot go any further and remain sane, and then it is time to start over (or the "big refactoring" comes ... ). Time for the bullies to go asking for investment in rewriting.

Next, the Zen of software development ...

The Decline and Fall of Agile

Guðlaugur Stefán Egilsson — Mon, 17 Nov 2008 23:17:42 GMT

James Shore posted an excellent blog entry titled The Decline and Fall of Agile about what he's seeing happening with many Scrum teams, provoking a myriad of responses all over the agile blogosphere.

A few of the posts:

Robert C. Martin (Uncle Bob)

InfoQ

Jeremy Miller:

In my opinion, Scrum is a kind scaffolding around the team where value is actually created, used to construct the real process, one improvement at at time. And, if you know where you can go, those improvements should lead more or less towards XP engineering practices. The reality is that Scrum is a lot easier to sell than XP in its entirety, especially when it comes to getting people to rally around a process change to begin with. XP, on the other hand, with its 12 practices, can be mind boggling to start with if you don't have a coach who really knows the drills.

People, knowing only Scrum without the technical practices to make shorter cycles work in the long run, are going to get into trouble. It's as simple as that. Of course not everybody is going to be equally good at it, but awareness is a key element. If not believing something is possible makes sure it won't happen then not knowing about a possibility is an even better way to ensure it never happens. So introducing Scrum as a complete package into a company without at least ensuring awareness of the technical practices, is a risky practice IMHO.

We are fully aware of these risks here at Sprettur, and are ready to provide training in the engineering practices talked about in these posts. Contact us for details.

Soft as in "Software"

Petar Shomov — Tue, 04 Nov 2008 22:50:05 GMT

Recently my company organized a nice conference about software agility and building an agile company. Among the speakers were Jeff Sutherland and Dean Leffingwell - two names that are very well known in the agile community. We had dinner with Dean on one of those days and were looking at the software industry from high and above (do not remember the context really but that is not that important for my point) and then Dean made a remark that made me think for a while. He noted that software rots a lot and that's the reason we (software people in general) keep getting hired, so we would write the software (again) using the new cool platforms and APIs of the day.

As good as this may sound for software people I wonder what kind of perception business people investing in IT have of us. Do they feel uneasy every time they hear about the need to invest in re-writing the information system they have just started using the last year because you see the database has to be upgraded since the vendor is putting an end to that product, and now has a new more expensive product with more features. These businessmen probably wonder what happened to the "soft" in "software". And they get crushed with acronyms if they try to say "but ... do we need that?' - SOA, REST, AJAX, WEB 2.0, WSDL, WPF, WWF, WCF, etc. You get the picture.

Imagining these things I figured these people that are the real customers of our industry are probably not real happy. Probably feel more like bullied into it then really buying into it. I mean they need IT there is no way around that, we have put them in one big vendor lock, haven't we ;)

So what is stopping software people from really making the customers happy? What would it take to make software that is long-lasting and easy to adapt to new platforms and APIs?

To be continued ...

Áhugaverð blogg úr Agile heimum #3

Daði Ingólfsson — Sun, 26 Oct 2008 22:07:54 GMT

Það sem vakti helst athygli mína í Agile bloggheimum síðan síðast:

Project Automation eftir Naresh Jain - Naresh um hvað hann telur þurfa að sjálfvirknivæða í hugbúnaðarverkefnum
Agile RFP sería eftir Peter Stevens - Peter er búinn að skrifa fyrstu tvo partana af þessari seríu og eru þeir báðir mjög áhugaverðir - sérstaklega fyrir þá sem eru annað hvort að bjóða hugbúnaðarverkefni út eða taka þátt í útboðum
Kanban Systems eftir James Shore - Einstaklega skýr og upplýsandi grein um hvað Kanban, hvernig teymi eru að nota það og hvað Jim líkar við þess konar vinnulag. Mæli líka með kommentunum frá lesendum.
The new user story backlog is a map eftir Jeff Patton - Hef nú bloggað um "story mapping" hugmynd Jeffs áður og í þessari grein fer hann vel í gegnum hana
Jeff Sutherland's Sprint Emergency Landing Procedure eftir Dean Leffingwell - Dean að fjalla um nokkuð sem Jeff Sutherland fór í gegnum á Agilis 2008 - varð bara að minnast á þetta þar sem Ísland og Sprettur koma fyrir í blogginu ;)

Áhugaverð blogg úr Agile heimum #2

Daði Ingólfsson — Wed, 01 Oct 2008 10:28:59 GMT

Það sem vakti helst athygli mína í Agile bloggheimum síðan síðast:

Micro-Design v/s Macro-Design v/s BUFD frá Naresh Jain - Naresh um mismunandi skala hönnunar (kóða)
Should the Daily Standup Be Person-by-Person or Story-by-Story? - Mike Cohn með nokkra vinkla á daglega scrum-ið
Husbanding willpower - Steve Freeman með merkilega færslu um viljastyrk og af hverju við eigum ekki að breyta öllu í einu þegar kemur að lífstíl eða vinnuaðferðum
Is Distributed Development Viable - Jay Fields hefur skoðanir á og reynslu af dreifðri þróun
red, green, refactor ...commit - Kevin Rutherford talar um hvar "commit" skrefið er í hans TDD ferli