We have 3180 guests and 8 members online
Home > Articles > Columns > Articles > Softening Iterations - Setting up for success

Softening Iterations - Setting up for success

 E-mail
Written by Administrator   
Sunday, 11 May 2008 13:00
may-08-settingbigYou 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 -

  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.

ya0508-1


Story

 Example
Infrastructure setup
  • Ensure everyone in the team has the necessary hardware, software, access levels needed
  • Setup email groups, project wiki, source control and document repository
  • Reserve meeting rooms, whiteboards, digital camera
  • 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.

Comments (0)Add Comment


Write comment

feedShow/hide comment form
You must be logged in to post a comment. Please register if you do not have an account yet.

busy
< Prev   Next >
Last Updated on Tuesday, 21 April 2009 14:11
 

Agile Marketplace - Announcements and Special Offers

White Paper: Code Review IS an Agile Process!
Peer code review is one of the most effective ways to improve Software Quality – but is it Agile? Done correctly, it absolutely is. This white paper tells you how.
Download Today!

Virtual Conference: Collabnet Agile ALM
Stay current by attending CollabNet’s virtual conference, Agile ALM for Distributed Development, Thursday, April 15, from 7:30 am to 3:30 pm PDT. Free registration.
Register Today!

Webcast:  Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!

Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial

Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper

PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now