Agile Montage

Let's visit a very common conversation that I have often been involved in or heard of: Q: What's the difference between Waterfall and Agile? A: Agile doesn't involve the upfront analysis that Waterfall plans and invests in. This is probably the first thing you hear in terms of differences between Agile and Waterfall. The follow-up question usually is, "How can you do software development without any analysis?" It starts the classic dialog that a lot of agilists repeatedly have. The Luck Factor How can we really deliver business value without 'proper' analysis? We may be able to deliver some, but it'd just be a matter of luck. That's exactly the inspiration to invest in upfront analysis; eliminate the factor of luck. The temptation to know it all and plan everything is just too much. Sometimes, before you even realize someone reminds you that your planning and analysis is starting to look like Waterfall. Not planning, I think, is wrong. Not analyzing is a blasphemy. You are wasting money and time if you are not planning and analyzing. But if its all on paper, powerpoint or visio and planning your software to the Nth possibility you are most likely about to run into a lot of potential waste. Release Zero The solution to this paradox is to have a release of whatever you are tyring to build as soon as possible. Get that extra-lean yet functional piece of software out to your small test-user base ASAP. A colleague of mine termed it 'Release Zero'. In addition to a lot of usability feedback, this would provide your analysts a working system that they can analyze. Scenarios, situations, dead ends, etc. that I as an analyst have come across in actual working software could never ever have been thought of if I were to design theses flows in detailed functional requirement documents and system design documents. The stretch of imagination needed to design a good system on paper becomes so thin and flaky that it starts to consume extraordinary amounts of energy and time to make them useful. So, do just enough, think only so much ahead in time. Before you proceed any further on that theoretical trajectory, get it built. Do your analysis on this release and iterate further. Example Imagine designing a content management and publishing system where a user should be able to:

• Create article, etc.
• Publish, revise, republish articles.
• Rate and comment on articles.
• Search on articles
• Provide sneak peak into some work-in-progress articles to readers.
• Workflow between writers and editors.

This can prove out to be a very complex system to design if we introduce the concept of user groups. i.e. a group of Writers, Admins, etc. in addition to the Readers. Now let's say there's another user group in it called Classified. And let's say that this is a group of users that writes very sensitive information that shouldn't be leaked to the rest of the publishing house and certainly not to the readers before the due date. Imagine how complex the analysis can get. Content should be available to a certain group for editing before the publishing date, but to others after it has been published. Search should not return classified material or should return only parts of it to some readers. Internal editorial comments should not be visible to the readers and/or vice-versa. As an analyst this product would be a big challenge. As I said earlier, my analysis will start becoming flaky beyond a certain functional depth. Decision on functional aspects will start taking long time because product owners, designers, and developers will have very little common understanding. Hypothetical and imaginary usage scenarios will start to consume time. In this situation I'd recommend to start development with a simple model in place. Two user groups - editors and readers, simple search, and basic data privacy and security in place. Once I have this system in place in 3-4 weeks, I can start analyzing on this system and have users test it. In this paradigm, there will be frequent releases and the analysis will be based on the last release. It may or may not be available to the end users yet for feedback. It won't be a surprise if a lot of the current requirements may not be requirements anymore 3 months down the line. Having a working system around to play with will likely make some requirements unattractive or not worth the investment. Image taken from: http://www.time.com/time/magazine/article/0,9171,1630556,00.html