You have an approved project that is about to begin - the project team is in place, the product owner has been identified - the stakeholders are eagerly waiting to see results of this agile approach that they have all heard good things about ...
Here's your dilemma ... the stakeholders are expecting to see tangible progress at the end of the first iteration in two or three weeks - having been through presentations of Agile processes. But you know that it's really not feasible to deliver anything remotely useful in that short a period. Agile processes warrant early delivery of business value, stressing on working code. Release planning and iteration planning are all based around user stories completed to the extent of being ready to deploy. But the reality is often different.
At this stage in any project of significant size - the team has to spend a lot of time in setting up the baseline architecture, understanding the overall requirements of the application and trying to get a grasp of the business that the application will serve. Very rarely will a team be able to actually produce production grade code that directly adds business value, in the early iterations. This problem can be especially critical in situations where an agile approach is being introduced - as product owners and other business stakeholders can very quickly give up on the process when their raised expectations of early delivery are not quite met.
In legacy processes, the initial phases of the development lifecycle are devoted to analysis and design. Under Unified Process, the inception and elaboration phases address these issues nicely. But needless to say, the stage gate approach of these methodologies is essentially contradictory to agile processes, and if followed can potentially ruin the project.
To effectively resolve this dilemma, I would like to introduce the concept of one or two iterations in the beginning of a project that are devoted to unknotting the jumble of the largely unknown project. These iterations have very specific roles for everyone in the team - including the product owner. They also have specific deliverables - code and non-code. These iterations are distinguished from the rest of the iterations that follow by their activities as well as by name. The term I like to use is " Softening Iterations " - as a counterpart to the "Hardening Iterations" that are typically used at the end of a project to tie loose ends. The purpose of characterizing these iterations is three fold -
- Set the expectation of stakeholders - By communicating the unique nature of the early iterations, we alleviate the risk of losing the excitement factor in stakeholders. They now know that during softening, the focus is slightly different and they themselves are full participants in ramping up for later iterations.
- Enable the team to go through the essential start-up stories - A standard set of start-up stories that are common to most development projects are reviewed. Some of these may not be necessary for a project - while some others may come up in the process of going through the steps. I have listed the most common softening stories later. This way the team goes through the discipline of a process - without being constrained by it.
- Allow the team to get used to working together - An essential part of softening is to strengthen the team. Success of Agile depends on a establishing a team that effectively collaborates to achieve team goal. Practices like pair programming and daily stand-ups need a level of understanding that comes with some focused team building.
I need to emphasize that softening iterations are truly agile iterations - they have little in common with an analysis phase of classic waterfall or with the inception and elaboration phases of a non-agile RUP implementation. Like other later iterations - softening iterations are time-boxed, have daily scrum style stand-up meetings, have an iteration plan and have stories that need to be delivered. The only difference is in the nature of the stories. They are not always classic user stories that translate to product features. They are related to infrastructure setup, architecture, user experience, understanding of feature requirements and finally - team building.
The fundamental difference between softening in Agile and the early phases in more traditional methodologies is that softening iterations seamlessly morph into the later iterations that deliver deployment