Softening Iterations - Setting up for success

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 -

1. 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.
2. 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.
3. 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 ready user stories. There is no milestone or stage gate that separate softening from later iterations - nor any formal approval process exists that signals the end of softening. It is it up to the team to decide when it has done just enough to begin coding features that are production ready.

Below is a standard set of stories that are typical of softening iterations. Needless to say, this will largely depend on your specific project needs and environment - the idea is to provide a baseline that is relevant to most situations.

Finally, we need to consider what roles different individuals will play during softening. The project manager will primarily coordinate the infrastructure setup and team building - in addition to fulfilling the regular PM responsibilities. The developers work on architecture. The product owner plays a critical role, where s/he works very closely with developers to pull together the application features - and also, works with the user interface designer to create the baseline user wireframe.

The involvement of product owners in these activities during softening enables the developers to establish a good working relation with them. It also brings the business and IT together right from the beginning, working toward a shared goal of succeeding in the project.

About the Author

Yousuf Ahmed currently works as the Director of Software Development at Commonwealth Business Media. He has spent over 16 years in software development - serving in a number management and consulting roles. Yousuf has successfully implemented agile processes in both co-located and distributed organizations.