Although agile principles have been around since 2001, it
seems only recently (in the last few months) that I have seen a noticeable demand
for ICT professionals with agile experience, from Business Analysts, Project
Manager and Architects alike. Even Gartner Inc.,
in promoting their upcoming Developer Summit, via email, made the statement:
“By 2012, agile
development methods will be utilized in 80% of all software development
projects”
A bold statement maybe, but never the less a sign of the momentum
that agile is generating in the industry at present.
Sceptics of agile will say it is just the latest buzzword, knocking
off SOA off the top of the list. Others
may say it is another methodology given birth by people wanting to claim a good
idea as their own, or it is rapid application development rebadged. Others may not be as quick to judge, and like
me, might want to form their own ideas and opinion on agile.
So if you genuinely want to know more about agile, or are
thinking of adopting an agile development approach for your next dev project,
where do you start?
In answering this, it’s probably not a bad idea to say where
no to start. Don’t go looking for books,
don’t go Googling about agile methods, like XP or Scrum, in fact avoid Googling
anything (yet)…be warned if you do, be prepared to be bamboozled and
overwhelmed with information.
First step, go to where it all began, the original Manifesto
for Agile Software Development http://agilemanifesto.org/ and also link
through and read the 12 principles behind the manifesto http://agilemanifesto.org/principles.html
Now don’t be put off by the site…it is a bit of a shocker, I thought, could this site be any duller, more
basic, less exciting…but in saying that the site sort of keeps in line with
some of the principles, in particular – no.10 Simplicity…yeah I know it is a
stretch.
You’ve now read about the manifesto and the 12 principles,
so now what. Well this is where things
get interesting. How do you go about
applying these principles to a particular project, or even your every day
work? What methods or tools are
available to that support and compliment the agile principles? How do these agile principles fit in with PM
methodologies such as Prince2? (um don’t
have an answer to that last one)
So where to begin…well I’ll share with you the methods and
tools that I’ve used, and explain why they worked for me. Please don’t read into this that these are the
only tools and methods to use. It is an
approach that I’ve taken which has evolved over the last 5 or so years that works
well given the work environment I’m in.
The following section describes the agile methods and models
that I adopt during a project. The
methods are grouped into typical project phases. Please don’t consider the phasing as being
sequential, that sort of defeats the purpose of agile, it simply illustrates where
that method belongs in a typical project lifecycle.
Discovery &
Analysis
User Stories
User stories are an easy way to begin eliciting
requirements, as they are conversational and follow a simple structure:
Title: of the story which
is based on an activity
Narrative:
As a I
want to to .
Looking at the structure you’ll probably find that the role, action and goal
are covered in discussions you might have with the client and stakeholders –
nothing really new here. However, what the
story structure does is formalise the conversation, as it begins to define the
parties involved, the functions to be delivered whilst ensuring each function
is linked to a business goal or benefit outcome.
For me, the only trick with the user stories is to refrain
from writing separate stories for all the various permutations. For example, you may have a story which looks
like this:
Title: Customer purchases song from iTunes
Narrative: As a customer, I want to purchase a song from
iTunes, as it is cheaper and more convenient than purchasing the song from a
music store.
In discussions with your client another story is created:
Title: Customer purchases
an album from iTunes
Narrative: As a customer, I want to purchase an album from
iTunes, as it is cheaper and more convenient than purchasing the song from a
music store.
The two user stories are essentially identical, in that, the
same role is involved, the same function is performed and for the same
benefit. The fact that the item
purchased were different is immaterial.
Both stories could be consolidated into something like:
Title: Customer purchases music from iTunes
Narrative: As a customer, I want to purchase one
or many music items from iTunes, as it is cheaper and more convenient than
purchasing music from a music store.
You might also wish to extend the story to cater for
additional or exception scenarios. For
example, an extension to the above story might be to illustrate what happens
when the customer has insufficient funds to purchase the item(s), or how a
discount or voucher could be applied to the purchase…the list goes on. Documenting the exceptions to the story does
not necessarily need to be done here but if an exception discussion does occur,
I normally include it, mainly through fear that I might forget it down the
track. Illustrating the exceptions is typically
done during the Detailed Analysis & Design phase and through Use Cases.
If your after a good reference on User Stories, I can
recommend “User Stories Applied: For Agile Software Development” by Mike Cohn.
Detailed Analysis
& Design
Class Diagrams
Activity Diagrams
Use Cases
These three modelling techniques are referred to commonly as
agile models, perhaps because they link well with user stories and are a
natural evolution which further illustrates the roles, functions and responses
required by the application. If someone
has a better answer to this, please let me know.
User Scenarios - Usability
Sessions
Paper Prototyping
I combine user scenarios and paper prototyping into
usability sessions or walkthroughs as a way of validating my functional and
interaction design.
It enables me to validate business requirements, through the
description and goal of the scenario, as well as testing the user interaction
to see how easily the user can successfully complete the prescribed task.
These methods bode well with agile as they are collaborative
in nature. The use of a paper prototype
enables me to quickly change a design and revalidate it early in the design
process.
Development &
Implementation
Scrum or XP methodologies
There are a number of ‘Lean’ or ‘Adaptive’ software
development mythologies which support agile principles, each with a different
twist. I’m not going to regurgitate what
each does, rather point you to an article written by one of the agile manifesto
and principal founders, Martin Fowler http://martinfowler.com/articles/newMethodology.html
In this article Martin talks about each of the popular
development methodologies, in particular the two most common XP and Scrum.
For me, the methodology you follow isn’t that important, I
won’t say one is better than the other.
It is simply a matter of following or adapting a methodology that suits
the environment you are working in. From
my perspective, it is a bit of a mix between, XP, Scrum and traditional
SDLC. Whilst I have control over the
approach adopted for the discovery analysis and design, the project management
approach and reporting is very much based on a traditional SDLC model. The main reason for this is that the
organisation has invested heavily in Prince2 as their PM framework. Transitioning or adapting such a framework to
agile I think will sit fairly and squarely in the too hard basket for a little
while to come.
Recent Comments