|
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 -
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.
Set as favorite
Bookmark
Email this
Hits: 6444 Comments (0)
|
| < Prev | Next > |
|---|


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