Softening Iterations - Setting up for success

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 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.

Story

Example

Infrastructure setup

Ensure everyone in the team has the necessary hardware, software, access levels needed

In case of distributed teams - decide on the virtual stand-up meeting format and put the necessary tools in place.

Setup development and test environments (servers and data)

Architecture

Evaluate deployment architecture options. This is the architecture of the infrastructure layer. The tasks include (but not limited to) determining the deployment of servers, network, databases and application servers. This is done in true agile fashion - in a whiteboard session, without spending a lot of time in creating an extensive document, and with an understanding that there is always a possibility that the final architecture may be different.

Develop an application architecture framework - this will include the structural elements of the different application layers.

Evaluate and select any special tools that need to be used in the application.

User Experience

Develop wireframes that demonstrate navigation, look and feel of the application. Review the wireframes with the product owner and other stakeholders. The idea is to develop a prototype that demonstrates the behavior of the system.

Hold workshops to review the wireframes and collect enough information to start designing the final user interface.

Application Features

Put together the initial product backlog that includes all user stories that are known to be part of the release.

Write short descriptions of the user stories - just enough to put the story in context so that they can be elaborated just in time - during the iteration they will be built.

Team Building

This is an often ignored critical factor for any project. It is especially critical when a new team is put together for a project. Team building is done in many ways, and it really depends on what the organization supports. The goal is to include this as a step in softening.

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.

About the author

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email [email protected].

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.