Chance findings

In a recent meeting, a colleague of mine mentioned that we wanted to use agile development this time with that new project and that I would provide some insight as an ‘agile development expert’ (not that this would be a term I would use). This in turn brought me some curious looks and a pretty general question during the discussion: what is the benefit of an agile development model from a business perspective anyway?

If I remember correctly, my answer went in the direction that with an agile approach you can change your mind about what you really need/want to implement throughout the project, if you learn something ‘new’ about what is really required. The second important aspect is that you get quicker feedback which allows for more influence in case things don’t turn out right. After the meeting I started pondering the question a little, as I had the impression that my answer wasn’t that convincing, so what you find below is a more detailed written elaboration of it.

Basically, what “you can change your mind throughout the project” boils down to is that agile development gives you more options to make use of opportunities coming up along the way/throughout the time you need to implement the project. The most important idea here is that you don’t make decisions too early, because that limits your options. For an example, let’s assume that one feature we specify is that we want to have a ‘Facebook like’-button on the order page. Now, if we’re following the waterfall style ‘implementation follows after specification has been completed’ development model, you would specify that and design the page with the button and at some time in the future, you hopefully get your Facebook button. But maybe during the hypothetical nine months from now in which development happens, what if Germany’s privacy laws enforce new severe restrictions on the use of such buttons and, btw., Google+ is now the new hip site you have to support? You have to go through a (with larger features typically quite costly) change process, redo the specification, etc. This essentially makes the cost you had in writing the specification as well as for the design etc. a double problem: you didn’t get out any ROI, obviously, but additionally time has passed while writing specs, doing design etc. in which you didn’t really work on any results for the customer (lost opportunity: gather new clients with at least some new features).

So, you would have been better off with having the idea that at some point throughout the project you want ‘social media integration for marketing reasons’ and delaying what to do exactly until you’re really there (from a priority point of view) where this is a feature that you want implemented — i.e. you do the specification when your planning that feature to get implemented in the next development phase (which is typically two to four weeks with an agile development team). The idea is to take small, well defined steps that can be taken fast and starting out with the most important/valuable ones first, rather than to spend a lot of time on some ‘complete specification’ which withers fast throughout the projects implementation time.

The problematic point here is obviously, that it’s pretty difficult to say when exactly is the right point in time to make a decision. In general, there is no ‘right point’ — also often called the last responsible moment after which some opportunity is lost (I think the phrase was coined by Mary and Tom Poppendieck, see the excerpt from ‘Lean software development’) — but multiple points in time, depending on many aspects. Influencing aspects are things like business opportunities (e.g. a new feature nobody else has at that time) or reducing risks (projects risks) (cf. Alistair Coburn reconsidering the least responsible moment). The best answer I currently have seen when to make a decision is that it should be taken when you have ‘enough knowledge’, i.e. when you have carefully considered your options and evaluated them (cf. real options). Even thinking about options alone is typically a highly valuable undertaking in itself, because all to often people just assume that the ‘obvious way’ is the best one.

So, the general answer is probably along the way of: for the business side, agile development has the benefit that it provides more flexibility and more influence throughout the project phase while at the same time (possibly) generating real value/revenue more early. There is, of course, more to it that also has appeal from a business perspective, but that’s probably the main point. Feel free to add different opionions.

If you just stumbled over this blog entry searching for what the heck all that buzzing about agile methods amounts to, I may have unfortunate news for you: An agile approach to development might for a lot of people all over the world, but may be not for you. For starters, take a look at the agile manifesto and its principles. These have quite a lot of implications, directly translating into presuppositions about you, if you wanted to participate in an agile development project.

Now, perhaps you’re the well communicating, team oriented developer type who happens to work in a surrounding which you respect and general feel well motivated. But real life experience with your typical geek or ex-geek-turned-professional-developer suggests that having a hard time with direct communication, face-to-face, happening very often with those pesky guys and girls you don’t really like is a more likely scenario (“Eeek, those business and marketing people” anybody?). Now, you might say, baah, I know some communication is a necessary evil of professional software development, but maybe I can get away with my old habits of trading documents (specs, bug reports, etc.) against direct communication, since that is the trusted old way and what do you mean by face-to-face communication being more effective? Everybody hates those horrible meetings eating up all your time, right?

The point is that if you’re wanting to go agile you should better soon adapt your view or else you won’t see any of the promised benefits of all of those agile processes. Agile development is not only about using test driven design, timeboxing, iterations and releasing often. More than anything else, agility is about how people effectively interact with each other as quickly and direct as possible in order to come to solutions. To me, this basically boils down mainly to three issues: adaptability to (changing) situations, an open mind toward communication and taking responsibility for the project at hand.

Being lazy, sticking bone-headed to “trusted paths”, not seeking confrontation when it’s needed, avoiding communication because of being too busy “doing” is the anti-pattern to agility. You could keep a product and sprint backlog, present new features every other week to your customer and even use continuous integration and still would be muddling in pseudo agile, doomed to fail water. What I would suggest is that you should revisit the agile manifesto and think about what those principles might imply for you and your current behaviour. Let’s try an example: If you find that you might end up pointing fingers at your customer (or product owner to use the terminology from Scrum) because he won’t behave as demanded in the agile manifesto, you should reconsider if that fits in with what the agile manifesto demands of you: you wouldn’t do the project any good. You would build up frontiers where there should be a single team including the target of your pointed finger. This is not to say that you shouldn’t point out the defect, no communication about problems is another all too familiar reason for frustration and lack of commitment. What is necessary is direct communication and finding a way that works for all people involved.

Let me sum up this posting: if you’re interested in agile approaches to software development, that’s fine. If you don’t feel comfortable about what this might imply for you, that’s fine too. But it might also tell you that agile development approaches might not work for you.

Update: Irionically, I stumbled via Infoq about the one essential agile ingrediment which says all about it much nicer than I ever could have done, only that Mark Schumann shows the confidence that agile works for the most part whereas I hold the more pessimistic view that it’s not going to work for some, but for exactly the same reasons.

ObTitle: Hermann Hesse, “Steppenwolf”