Home  Articles Previous Editions
|
Softening Iterations - Setting up for success |
|
|
|
|
Written by Yousuf Ahmed
|
|
Sunday, 11 May 2008 |
 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
- 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 () |
 |
|
|
|
Tags:
Click to add your tags...,
|
|
|
Latest Issues of Agile Journal
Coming Up - Editorial Calendar
- August 13 - Quality Agile Development
- September 10 - Agile News
- October 08 - Valuable Agile Practices
- November 12 - Introducing Agile to the Organization
- December 10 - The State of the Agile Community
See the full 2008 Editorial Calendar >
|
