Agile, a Different Methodology

Introduction

In the past year, Agile development methodologies have
moved from the fringes to being considered a mainstream
method for software development. The Agile movement started
in the late 90's with the advent of Extreme Programming
(XP), SCRUM, DSDM, Feature Driven Development and others.
The Agile manifesto created in February of 2001 contained
the core principles of Agile development. Why is this
important to us?

Agile is important, because in the end, it has helped to
bring business discipline to software development. Agile has
a lot in common with Lean methods, exemplified by the Toyota
Production System. Lean methods have begun appearing in
Agile teams, bringing even more business focus to software
development/IT teams.

Comparing Agile against what?

When discussing Agile, what are we comparing it against?
I am comparing Agile against strict Plan driven development
approaches. Often called waterfall, your company may not
have a specific name for it. But if the current process
involves making sure that all the requirements are nailed
down before the project is started, and changing those
requirements includes a request to walk on water before it
can be changed this is the process we are comparing Agile
against.

To get a sense of the high level view of Agile you can
read the manifesto at AgileManifesto.org.
The manifesto begins with four statements:

These statements may seem a little touchy, feely, so let
us put some meat on the bone, to understand how to implement
this in your shop.

For each of the statements in the Agile manifesto,
concrete practices from Agile methods are used. Each
statement is a section that will contain what practices are
used to achieve the intent.

Individuals and interactions over process and tools

This statement may indicate to you that Agile has no
process. In fact I have found this to be far from the truth.
Agile does not throw process out the door, rather Agile says
that Individuals and interactions trump the process and
tools.

This shows in the frequent planning and daily standup
meetings common to most Agile methods. In XP, Scrum, Lean
the daily standup meeting is a staple. At this meeting all
committed team members interact with each other via these
questions:

What did I do yesterday?

What am I working on today?

What is blocking my work?

The daily standup should help communicate project
progress. In other words, what is communicated in the
standup (individuals AND interactions), may need to
supersede the project plan. It is during these meetings that
hurdles are uncovered. But usually they are discovered in
time to fix the problems quickly. If a technology is not
working as expected, or the business logic actually
conflicts with other logic, it is brought up in these
meetings, and after the meeting the action plan is
created.

Working software over comprehensive documentation

This phrase is best described by the practice of
delivering software on a regular, fairly quick schedule.
Normally in XP and Scrum, you work in iterations. The team
selects the length of the iteration at the beginning of the
project, and generally stays with that length for the
duration of the project. Within an iteration, the team
selects the stories or features they will complete. Once in
that iteration, the stories that are being worked on cannot
be changed. Any changes can be introduced at the beginning
of the next iteration.

Normally, at the end of the iteration, there is a demo
and planning meeting. In this meeting, your team demos the
solution including the new features/stories to the
stakeholders/customer. The intent is that if the customer
likes this, the team could release that version of the
software immediately. In practice this can mean that the
team releases the software to QA or User Acceptance state
where customers can test/use the new features. Other teams
may release to production (think of all the google beta
software you have used).

One note on iterations, the length is generally
considered to be 1 week to 1 month. This is up to the team.
Again, this decision should be made as a self determining
team, it should not come from management.

Many Lean/Kanban teams do not use iterations, but they do
frequent releases. The releases happen on a similar schedule
as iterations. This allows the Lean/Kanban teams to release
working software frequently.

The reason for valuing working software over detailed and
comprehensive documentation is that the value delivered is
the software. Documentation of your system should be baked
into the process of delivering software. Agile does this, by
encouraging good software engineering principles like Test
Driven Development using automated unit tests and automated
user acceptance tests.

Test Driven Development using unit tests, and acceptance
tests, encourage test writing that serve as documentation. A
well written unit or acceptance test should document the
requirement the developer is testing for. When any
maintenance is needed, different developers should be able
to look at these unit tests and understand the requirements
needed.

In addition, this suite of tests add a fantastic safety
net for modifications later in the life of the software. If
the software sits for a year before modifications, the new
team can start development on new features, knowing that
those tests ensure that they cannot break existing
features.