Association of Geographic information

Laboratories for Europe

1. Why is it called agile? I would say because the scope/features are

flexible and the timescale is fixed, whereas traditional development
projects seek to control scope/features.

In many traditional development environments, doing a release every

three weeks is very frequent, with many typical projects lasting many
months. It may not be agile compared with a newspaper environment,
but it certainly is compared with many traditional project environments.

In my opinion, it shouldnt necessarily be the case that you can only

release at the end of a sprint or iteration, particularly of course if the
changes are critically important.

It is convenient and efficient to stick to a fixed release cycle, however,

so being disciplined about release cycles unless changes are important
exceptions is beneficial to the teams productivity and therefore the
product in the end.

The issue to address in the situation you describe is the underlying

quality. In this case thats where the principles and practices of XP
(extreme programming), which is an agile engineering methodology,
would help more than Scrum, which is a (complimentary) agile
management methodology.

Automation can be important to agile software testing because the

development process is much more iterative and requires frequent testing.
A waterfall development cycle only requires major testing at the end of
the development process; whereas, agile development requires testing
throughout.

Whats the difference between waterfall and agile software development?

Below is a typical example of the waterfall methodology. As illustrated,
the process leads developers through a series of sequential steps with
major testing done towards the end.

Waterfall Software Development Cycle

The agile methodology is much different than the waterfall methodology.

Agile development requires very active project management. The process
begins with planning, but then instead of building an entire application
at once, agile development builds each functional component separately
in what are called Sprints. The illustration below shows how the process
constantly involves end-users, business analysts, and end users.

Agile Software Development

Agile software development is a flexible process that rapidly builds each

piece of a software project, adding functionality every few weeks until
the entire project is complete. This kind of rapid development has the
flexibility to meet the demands of evolving business requirements.
Agile development teams are often broken into small groups that can work
on individual pieces of the overall project. Agile development requires
organized communication between business analysts, programmers, and end
users in order to ensure all business requirements are being met.

For example

For example, imagine two companies building an email program. Company A

uses the waterfall methodology, so they create a requirements document
of what their email client will need to do. They list everything from
sending and receiving mail, to managing an address book, to scheduling
appointments. Then they begin development and build the entire email
program over a few months. Once the entire program is built, they begin
testing. Often using a combination of manual and automated testing, they
go through the program with a fine toothed comb and identify issues. Then
they go back to the program and remedy all the bugs before releasing it
to end users.

Company B uses an agile development process, so they get a team started

right away on basic functionality. In the first week they build the
framework and test the user interface. The following week they create the
ability to receive emails. The week after that they build the ability to
send emails. This continues week after week. They build a small piece of
the program, test it, and release it to end users. Their team has already
released the program to the client and is adding functionality every week.
This gives Company B the ability to remain flexible while responding
quickly to user feedback.

Where does testing come in?

In the waterfall development methodology, testing is at the end. Once the

project is complete, the entire program is tested using a combination of
automated and manual testing. A large list of test cases is worked through
to ensure proper functionality of the entire program.

In the agile development methodology, testing is conducted throughout the

process, often on a daily basis. That is why agile software development
requires increased automated testing because the testing is much more
frequent. It would be nearly impossible, or at least in-efficient, to
manually test an entire program on a daily or weekly basis throughout the
development process. In that way, automated testing makes it possible
because it can run through a large series of test cases rapidly,
efficiently, and most importantly, effectively.
 Manifesto for Agile Software
Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over

processes and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck James Robert C.

 Mike Beedle Grenning Martin
Arie van Jim Steve Mellor
Bennekum Highsmith Ken Schwaber
Alistair Andrew Hunt Jeff
Cockburn Ron Jeffries Sutherland
Ward Jon Kern Dave Thomas
Cunningham Brian Marick
Martin Fowler

Principles behind the Agile

Manifesto

We follow these principles:

Our highest priority is to satisfy the customer

through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in

development. Agile processes harness change for
the customer's competitive advantage.
 Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work

together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of

conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of

progress.

Agile processes promote sustainable development.

The sponsors, developers, and users should be
able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence

and good design enhances agility.
 Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and

designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts
its behavior accordingly.

10 Key Principles of Agile

10 Key Principles of Agile Development

1 - Active User Involvement Is Imperative
2 - Agile Teams Must Be Empowered
3 - Time Waits For No Man
4 - Agile Requirements Are Barely Sufficient
5 - How Do You Eat An Elephant?
6 - Fast But Not So Furious
7 - Done Means DONE!
8 - Enough Is Enough
9 - Agile Testing Is Not For Dummies
10 - No Place For Snipers

10 Key Principles of Agile Development

by Kelly Waters, 10 February 2007 | 10 Key Principles of Agile Development

Agile Development is one of the big buzzwords of the software development

industry. But what exactly is agile development?
Agile development is a different way of managing software development
projects. 10 Key Principles of Agile Software Development, and how it
fundamentally differs from a more traditional waterfall approach to software
development, are as follows:

1. Active user involvement is imperative

2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle test early and often
10. A collaborative & cooperative approach between all stakeholders is
essential

Agile Principle 1: Active User Involvement Is

Imperative
by Kelly Waters, 24 February 2007 | 10 Key Principles of Agile Development

In my mind, active user involvement is the first principle of agile development.

Its not always possible to have users directly involved in development projects,
particularly if the agile development project is to build a product where the real
end users will be external customers or consumers.

In this event it is imperative to have a senior and experienced user

representative involved throughout.

Not convinced? Heres 16 reasons why!

Requirements are clearly communicated and understood (at a high

level) at the outset
Requirements are prioritised appropriately based on the needs of the
user and market
Requirements can be clarified on a daily basis with the entire project
team, rather than resorting to lengthy documents that arent read or
are misunderstood
 Emerging requirements can be factored into the development
schedule as appropriate with the impact and trade-off decisions
clearly understood
The right product is delivered
As iterations of the product are delivered, that the product meets user
expectations
The product is more intuitive and easy to use
The user/business is seen to be interested in the development on a
daily basis
The user/business sees the commitment of the team
Developers are accountable, sharing progress openly with the
user/business every day
There is complete transparency as there is nothing to hide
The user/business shares responsibility for issues arising in
development; its not a customer-supplier relationship but a joint
team effort
Timely decisions can be made, about features, priorities, issues, and
when the product is ready
Responsibility is shared; the team is responsible together for delivery
of the product
Individuals are accountable, reporting for themselves in daily updates
that involve the user/business
When the going gets tough, the whole team business and technical
work together!

Agile Principle 2: Agile Development Teams

Must Be Empowered
by Kelly Waters, 4 March 2007 | 10 Key Principles of Agile Development
An agile development team must include all the necessary team
members to make decisions, and make them on a timely basis.
Active user involvement is one of the key principles to enable this, so
the user or user representative from the business must be closely
involved on a daily basis.
The project team must be empowered to make decisions in order to
ensure that it is their responsibility to deliver the product and that they
have complete ownership. Any interference with the project team is
disruptive and reduces their motivation to deliver.
The team must establish and clarify the requirements together, prioritise
them together, agree to the tasks required to deliver them together, and
estimate the effort involved together.
It may seem expedient to skip this level of team involvement at the
beginning. Its tempting to get a subset of the team to do this (maybe
just the product owner and analyst), because its much more efficient.
 Somehow weve all been trained over the years that we must be 100%
efficient (or more!) and having the whole team involved in these
kick-off steps seems a very expensive way to do things.
However this is a key principle for me. It ensures the buy-in and
commitment from the entire project team from the outset; something
that later pays dividends. When challenges arise throughout the project,
the team feels a real sense of ownership. And then its doesnt seem so
expensive.

Agile Principle 3: Time Waits For No Man!

by Kelly Waters, 11 March 2007 | 10 Key Principles of Agile Development

In agile development, requirements evolve, but timescales are fixed.

This is in stark contrast to a traditional development project, where one of the

earliest goals is to capture all known requirements and baseline the scope so
that any other changes are subject to change control.

Traditionally, users are educated that its much more expensive to change or
add requirements during or after the software is built. Some organisations quote
some impressive statistics designed to frighten users into freezing the scope.
The result: It becomes imperative to include everything they can think of in
fact everything they ever dreamed of! And whats more, its all important for
the first release, because we all know Phase 2s are invariably hard to get
approved once 80% of the benefits have been realised from Phase 1.

Ironically, users may actually use only a tiny proportion of any software
product, perhaps as low as 20% or less, yet many projects start life with a
bloated scope. In part, this is because no-one is really sure at the outset which
20% of the product their users will actually use. Equally, even if the
requirements are carefully analysed and prioritised, it is impossible to think of
everything, things change, and things are understood differently by different
people.

Agile Development works on a completely different premise. Agile

Development works on the premise that requirements emerge and evolve, and
that however much analysis and design you do, this will always be the case
because you cannot really know for sure what you want until you see and use
the software. And in the time you would have spent analysing and reviewing
requirements and designing a solution, external conditions could also have
changed.
So if you believe that point that no-one can really know what the right
solution is at the outset when the requirements are written its inherently
difficult, perhaps even practically impossible, to build the right solution using a
traditional approach to software development.

Traditional projects fight change, with change control processes designed to

minimise and resist change wherever possible. By contrast, Agile Development
projects accept change; in fact they expect it. Because the only thing thats
certain in life is change.

There are different mechanisms in Agile Development to handle this reality. In

Agile Development projects, requirements are allowed to evolve, but the
timescale is fixed. So to include a new requirement, or to change a requirement,
the user or product owner must remove a comparable amount of work from the
project in order to accommodate the change.

This ensures the team can remain focused on the agreed timescale, and allows
the product to evolve into the right solution. It does, however, also pre-suppose
that theres enough non-mandatory features included in the original timeframes
to allow these trade-off decisions to occur without fundamentally
compromising the end product.

So what does the business expect from its development teams? Deliver the
agreed business requirements, on time and within budget, and of course to an
acceptable quality. All software development professionals will be well aware
that you cannot realistically fix all of these factors and expect to meet
expectations. Something must be variable in order for the project to succeed. In
Agile Development, it is always the scope (or features of the product) that are
variable, not the cost and timescale.

Although the scope of an Agile Development project is variable, it is

acknowledged that only a fraction of any product is really used by its users and
therefore that not all features of a product are really essential. For this
philosophy to work, its imperative to start development (dependencies
permitting) with the core, highest priority features, making sure they are
delivered in the earliest iterations.

Unlike most traditional software development projects, the result is that the
business has a fixed budget, based on the resources it can afford to invest in the
project, and can make plans based on a launch date that is certain.

Agile Principle 4: Agile Requirements Are

Barely Sufficient
by Kelly Waters, 17 March 2007 | 10 Key Principles of Agile Development

Agile development teams capture requirements at a high level and on a

piecemeal basis, just-in-time for each feature to be developed.

Agile requirements are ideally visual and should be barely sufficient, i.e. the
absolute minimum required to enable development and testing to proceed with
reasonable efficiency. The rationale for this is to minimise the time spent on
anything that doesnt actually form part of the end product.

Agile Development can be mistaken by some as meaning theres no process;

you just make things up as you go along in other words, JFDI! That approach
is not so much Agile but Fragile!

Although Agile Development is much more flexible than more traditional

development methodologies, Agile Development does nevertheless have quite
a bit of rigour and is based on the fairly structured approach of lean
manufacturing as pioneered by Toyota.

I personally believe Agile Development teams can build better products if they
have a reasonably clear idea of the overall requirements before setting out on
development, so that incorrect design decisions dont lead the team down dead
ends and also so a sensible investment case can be made to get the project
funded.

However any requirements captured at the outset should be captured at a high

level and in a visual format, perhaps for example as a storyboard of the user
interface. At this stage, requirements should be understood enough to
determine the outline scope of the product and produce high level budgetary
estimates and no more.

Ideally, Agile Development teams capture these high level requirements in

workshops, working together in a highly collaborative way so that all team
members understand the requirements as well as each other. It is not
necessarily the remit of one person, like the Business Analyst in more
traditional projects, to gather the requirements independently and write them all
down; its a joint activity of the team that allows everyone to contribute,
challenge and understand whats needed. And just as importantly, why.

XP (eXtreme Programming) breaks requirements down into small bite-size

pieces called User Stories. These are fundamentally similar to Use Cases but
are lightweight and more simplistic in their nature.

An Agile Development team (including a key user or product owner from the
business) visualises requirements in whiteboarding sessions and creates
storyboards (sequences of screen shots, visuals, sketches or wireframes) to
show roughly how the solution will look and how the users interaction will
flow in the solution. There is no lengthy requirements document or
specification unless there is an area of complexity that really warrants it.
Otherwise the storyboards are just annotated and only where necessary.

A common approach amongst Agile Development teams is to represent each

requirement, use case or user story, on a card and use a T-card system to allow
stories to be moved around easily as the user/business representative on the
project adjusts priorities.

Requirements are broken down into very small pieces in order to achieve this;
and actually the fact its going on a card forces it to be broken down small. The
advantage this has over lengthy documentation is that its extremely visual and
tangible; you can stand around the T-card system and whiteboard discussing
progress, issues and priorities.

The timeframe of an agile development project is fixed, whereas the features

are variable. Should it be necessary to change priority or add new requirements
into the project, the user/business representative physically has to remove a
comparable amount of work from scope before they can place the new card
into the project.

This is a big contrast to a common situation where the business owner sends
numerous new and changed requirements by email and/or verbally, somehow
expecting the new and existing features to still be delivered in the original
timeframes. Traditional project teams that dont control changes can end up
with the dreaded scope creep, one of the most common reasons for software
development projects to fail.

Agile teams, by contrast, accept change; in fact they expect it. But they manage
change by fixing the timescales and trading-off features.

Cards can of course be backed up by documentation as appropriate, but always

the principle of agile development is to document the bare minimum amount of
information that will allow a feature to be developed, and always broken down
into very small units.

Using the Scrum agile management practice, requirements (or features or

stories, whatever language you prefer to use) are broken down into tasks of no
more than 16 hours (i.e. 2 working days) and preferably no more than 8 hours,
so progress can be measured objectively on a daily basis.

One thing I think should certainly be adopted from PRINCE2, the very
non-agile project management methodology, is the idea of making sure all
items are deliverables rather than activities or tasks. You can see a deliverable
and kick the tyres, in order to judge its quality and completeness. A task you
cannot.

Agile Principle 5: How Do You Eat An

Elephant?
by Kelly Waters, 25 March 2007 | 10 Key Principles of Agile Development

How do you eat an elephant? One bite at a time!

Likewise, agile development projects are delivered in small bite-sized pieces,

delivering small, incremental *releases* and iterating.

In more traditional software development projects, the (simplified) lifecycle is

Analyse, Develop, Test first gathering all known requirements for the whole
product, then developing all elements of the software, then testing that the
entire product is fit for release.
In agile software development, the cycle is Analyse, Develop, Test; Analyse,
Develop, Test; and so on doing each step for each feature, one feature at a
time.

Advantages of this iterative approach to software development include:

Reduced risk: clear visibility of whats completed to date

throughout a project
Increased value: delivering some benefits early; being able to
release the product whenever its deemed good enough, rather than
having to wait for all intended features to be ready
More flexibility/agility: can choose to change direction or adapt the
next iterations based on actually seeing and using the software
Better cost management: if, like all-too-many software
development projects, you run over budget, some value can still be
realised; you dont have to scrap the whole thing if you run short of
funds

For this approach to be practical, each feature must be fully developed, to the
extent that its ready to be shipped, before moving on.

Another practicality is to make sure features are developed in *priority* order,

not necessarily in a logical order by function. Otherwise you could run out of
time, having built some of the less important features as in agile software
development, the timescales are fixed.
Building the features of the software broad but shallow is also advisable for
the same reason. Only when youve completed all your must-have features,
move on to the should-haves, and only then move on to the could-haves.
Otherwise you can get into a situation where your earlier features are
functionally rich, whereas later features of the software are increasingly less
sophisticated as time runs out.

Try to keep your product backlog or feature list expressed in terms of use cases,
user stories, or features not technical tasks. Ideally each item on the list
should always be something of value to the user, and always deliverables
rather than activities so you can kick the tyres and judge their completeness,
quality and readiness for release.

These are important characteristics of iterative, feature-driven development

and theyre essential if you plan to deliver in fixed timescales one of the 10
key principles of agile software development.

Agile Principle 6: Fast But Not So Furious

by Kelly Waters, 31 March 2007 | 10 Key Principles of Agile Development

Agile development is all about frequent delivery of products. In a truly agile

world, gone are the days of the 12 month project. In an agile world, a 3-6
month project is strategic!

Nowhere is this more true than on the web. The web is a fast moving place.
And with the luxury of centrally hosted solutions, theres every opportunity to
break what would have traditionally been a project into a list of features, and
deliver incrementally on a very regular basis ideally even feature by feature.

On the web, its increasingly accepted for products to be released early (when
theyre basic, not when theyre faulty!). Particularly in the Web 2.0 world, its
a kind of perpetual beta. In this situation, why wouldnt you want to derive
some benefits early? Why wouldnt you want to hear real user/customer
feedback before you build everything? Why wouldnt you want to look at
your web metrics and see what works, and what doesnt, before building
everything?

And this is only really possible due to some of the other important principles of
agile development. The iterative approach, requirements being lightweight and
captured just-in-time, being feature-driven, testing integrated throughout the
lifecycle, and so on.

So how frequent is *frequent*?

Scrum says break things into 30 day Sprints. Thats certainly frequent
compared to most traditional software development projects.

Consider a major back-office system in a large corporation, with traditional

projects of 6-12 months+, and all the implications of a big rollout and
potentially training to hundreds of users. 30 days is a bit too frequent I think.
The overhead of releasing the software is just too large to be practical on such a
regular basis.

But consider a web site, a web-based product or even more dynamic

something like my blog. Theres no rollout overhead its an automated
central deployment to all users, and for the blog its a single click. No-ones
paying for the service. If somethings wrong, no-one dies. And it can be rolled
back as quickly as its deployed. There may be thousands of users, even
millions of users of a web site every month. But none of them need to be
trained. And you can evaluate the impact on the user experience, and the users
behaviour, through metrics within 24 hours and on an ongoing basis.

In that scenario, 30 days is a lifetime!

Competitors wont wait. Speed-to-market is a significant competitive edge. The

value of first-mover advantage is potentially enormous. Whilst its not always
the case, research shows that those first to market 80% of the time win; and end
up clear market leaders.

So how frequent is *frequent enough*?

Think carefully about your own situation. Think about the two extremes Ive
described above. Think about whats right for you; your organisation; your
product; your market; your customers. Think about whats right for *you*, in
your *particular situation*. There is no right or wrong answer. Only what
works for you, and what doesnt.

What is fairly important is to make this a positive decision to decide whats

appropriate for you. And then to stick, if you can, to a regular release cycle. A
regular release cycle allows you to plan. It allows your infrastructure and ops
teams to plan. It allows your business colleagues to plan. It allows your launch
events, marketing campaigns, etc to be planned. And because agile
development works to a fixed timescale, these plans are assured.

A regular release cycle also allows you to learn more effectively. Your
estimating might be good, it might be bad. Hopefully its at least consistent. If
you estimate features at a granular level (ideally less than 1 day) and track your
velocity (how much of your estimate you actually delivered in each Sprint), in
time youll begin to understand your *normal* delivery rate. And when you
understand this well, youll be surprised how predictable you can be.

And lets face it, managing expectations is really all about predictability. If
people know what to expect, theyre generally happy. If they dont, theyre not
happy. Maybe even furious!

So, in agile development, focus on frequent delivery of products. And perhaps

even more importantly, focus on consistent delivery of products.

Agile Principle 7: Done Means DONE!

by Kelly Waters, 8 April 2007 | 10 Key Principles of Agile Development

In agile development, done should really mean DONE!.

Features developed within an iteration (Sprint in Scrum), should be 100%

complete by the end of the Sprint.

Too often in software development, done doesnt really mean DONE!. It

doesnt mean tested. It doesnt necessarily mean styled. And it certainly
doesnt usually mean accepted by the product owner. It just means developed.

In an ideal situation, each iteration or Sprint should lead to a release of the

product. Certainly thats the case on BAU (Business As Usual) changes to
existing products. On projects its not feasible to do a release after every Sprint,
however completing each feature in turn enables a very precise view of
progress and how far complete the overall project really is or isnt.

So, in agile development, make sure that each feature is fully developed, tested,
styled, and accepted by the product owner before counting it as DONE!. And
if theres any doubt about what activities should or shouldnt be completed
within the Sprint for each feature, DONE! should mean shippable.

The feature may rely on other features being completed before the product
could really be shipped. But the feature on its own merit should be shippable.
So if youre ever unsure if a feature is done enough, ask one simple question:
Is this feature ready to be shipped?.

Its also important to really complete each feature before moving on to the
next

Of course multiple features can be developed in parallel in a team situation. But

within the work of each developer, do not move on to a new feature until the
last one is shippable. This is important to ensure the overall product is in a
shippable state at the end of the Sprint, not in a state where multiple features
are 90% complete or untested, as is more usual in traditional development
projects.

In agile development, done really should mean DONE!.

Agile Principle 8: Enough Is Enough!

by Kelly Waters, 15 April 2007 | 10 Key Principles of Agile Development

Paretos law is more commonly known as the 80/20 rule. The theory is about
the law of distribution and how many things have a similar distribution curve.
This means that *typically* 80% of your results may actually come from only
20% of your efforts!

Paretos law can be seen in many situations not literally 80/20 but certainly
the principle that the majority of your results will often come from the minority
of your efforts.

So the really smart people are the people who can see (up-front without the
benefit of hind-sight) *which* 20% to focus on. In agile development, we
should try to apply the 80/20 rule, seeking to focus on the important 20% of
effort that gets the majority of the results.

If the quality of your application isnt life-threatening, if you have control over
the scope, and if speed-to-market is of primary importance, why not seek to
deliver the important 80% of your product in just 20% of the time? In fact, in
that particular scenario, you could ask why you would ever bother doing the
last 20%?

Now that doesnt mean your product should

be fundamentally flawed, a bad user experience, or full of faults. It just means
that developing some features, or the richness of some features, is going the
extra mile and has a diminishing return that may not be worthwhile.
So does that statement conflict with my other recent post: done means
DONE!? Not really. Because within each Sprint or iteration, what you *do*
choose to develop *does* need to be 100% complete within the iteration.

As a slight aside, I was at Microsoft last week for an executive briefing on all
their latest products. Sharepoint 2007 looks great by the way; a real leap from
the earlier versions which were not really up to scratch. Vista, for those that
havent tried it, looked rather slow even on a laptop with 4GB RAM! And apart
from being slightly prettier didnt really seem to offer much. Windows
Workflow Services and .Net v3 looked pretty cool, if you can afford to develop
in Microsoft tools ;-)

Anyway, back to my point about the 80/20 rule, Microsofts own research
found that the average user of Word uses only *8%* of the functionality.
Thats 8%! And I wouldnt mind betting at least 80% of us use the same 8%
too! [assertion]. If Microsoft had developed only the important 8% of Word,
maybe they could still have captured the same market share? Maybe, maybe
not; sadly we will never know.

Its also worth considering the impact on user experience. Google has shown us
that users often prefer apps that do just what you want. Thats *just* what you
want. And no more. The rest is arguably clutter and actually interferes with the
user experience for only a limited benefit to a limited set of users.

So in an agile development world, when youre developing a brand new

product, think very hard about what your app is *really* all about. Could you
take it to market with all the important features, or with features that are less
functionally rich, in a fraction of the time?

Apart from reduced cost, reduced risk and higher benefits by being quicker to
market, you also get to build on the first release of the product based on real
customer feedback.

So all of this is really common sense I suppose. But its amazing how often
development teams, with all the right intentions, over-engineer their solution.
Either technically, or functionally, or both.

The really tough question, however, is can you see up-front *which* 20% is the
important 20%? the 20% that will deliver 80% of the results. In very many
cases, the answer sadly is no.

Agile Principle 9: Agile Testing Is Not For

Dummies!
by Kelly Waters, 22 April 2007 | 10 Key Principles of Agile Development

In agile development, testing is integrated throughout the lifecycle; testing the

software continuously throughout its development.

Agile development does not have a separate test phase as such. Developers are
much more heavily engaged in testing, writing automated repeatable unit tests
to validate their code.

Apart from being geared towards better quality software, this is also important
to support the principle of small, iterative, incremental releases.

With automated repeatable unit tests, testing can be done as part of the build,
ensuring that all features are working correctly each time the build is produced.
And builds should be regular, at least daily, so integration is done as you go
too.

The purpose of these principles is to keep the software in releasable condition

throughout the development, so it can be shipped whenever its appropriate.

The XP (Extreme Programming) agile methodology goes further still. XP

recommends test driven development, writing tests before writing the software.

But testing shouldnt only be done by developers throughout the development.

There is still a very important role for professional testers, as we all know
developers cant test for toffee! :)

The role of a tester can change considerably in agile development, into a role
more akin to quality assurance than purely testing. There are considerable
advantages having testers involved from the outset.

This is compounded further by the lightweight approach to requirements in

agile development, and the emphasis on conversation and collaboration to
clarify requirements more than the traditional approach of specifications and
documentation.

Although requirements can be clarified in some detail in agile development (as

long as they are done just-in-time and not all up-front), it is quite possible for
this to result in some ambiguity and/or some cases where not all team members
have the same understanding of the requirements.

So what does this mean for an agile tester? A common concern from testers
moving to an agile development approach particularly from those moving
from a much more formal environment is that they dont know precisely what
theyre testing for. They dont have a detailed spec to test against, so how can
they possibly test it?

Even in a more traditional development environment, I always argued that

testers could test that software meets a spec, and yet the product could still be
poor quality, maybe because the requirement was poorly specified or because it
was clearly written but just not a very good idea in the first place! A spec does
not necessarily make the product good!

In agile development, theres a belief that sometimes maybe even often

these things are only really evident when the software can be seen running. By
delivering small incremental releases and by measuring progress only by
working software, the acid test is seeing the software and only then can you
really judge for sure whether or not its good quality.

Agile testing therefore calls for more judgement from a tester, the application
of more expertise about whats good and whats not, the ability to be more
flexible and having the confidence to work more from your own knowledge of
what good looks like. Its certainly not just a case of following a test script,
making sure the software does what it says in the spec.

And for these reasons, agile testing is not for dummies!

Agile Principle 10: No Place For Snipers!

by Kelly Waters, 30 April 2007 | 10 Key Principles of Agile Development

Agile development relies on close cooperation and collaboration between all

team members and stakeholders.

Agile development principles include keeping requirements and documentation

lightweight, and acknowledging that change is a normal and acceptable reality
in software development.

This makes close collaboration particularly important to clarify requirements

just-in-time and to keep all team members (including the product owner) on
the same page throughout the development.

You certainly cant do away with a big spec up-front *and* not have close
collaboration. You need one of them thats for sure. And for so many situations
the latter can be more effective and is so much more rewarding for all
involved!
In situations where there is or has been tension between the development team
and business people, bringing everyone close in an agile development approach
is akin to a boxer keeping close to his opponent, so he cant throw the big
punch! :-)

But unlike boxing, the project/product team is working towards a shared goal,
creating better teamwork, fostering team spirit, and building stronger, more
cooperative relationships.

There are many reasons to consider the adoption of agile development, and in
the near future Im going to outline 10 good reasons to go agile and explain
some of the key business benefits of an agile approach.

If business engagement is an issue for you, thats one good reason to go agile
you shouldnt ignore.

Key points if you are following Agile Software

Development

Key points if you are following Agile Software Development

1. More working hours doesn't necessarily mean "more effective work".

2. Be adaptable to new changes (if they are billable :)) and let positive energy flow
with your blood i.e "Don't worry be happy".

How Agile Are You? (Take This 42 Point Test)

by Kelly Waters, 21 January 2008 | Agile Adoption

Recently I saw a brief set of questions from Nokia to assess whether or not a
team is agile.

And by agile, I think they meant to what extent the team was following agile
practices Scrum and XP (eXtreme Programming), not whether or not they
could touch their toes :)

Im not sure if it was deliberately brief to emphasise the things that are the real
*essence* of agile, but weve developed the questions into a more
comprehensive set of statements. A set of statements that make a fuller
assessment of someones status with agile principles and methods.

Here they are

1. The team is empowered to make decisions.

2. The team is self-organising and does not rely on management to set and
meet its goals.
3. The team commits and takes responsibility for delivery and is prepared
to help with any task that helps the team to achieve its goal.
4. The team knows who the product owner is.
5. Each sprint/iteration has a clear goal
6. All team members, including testers, are included in requirements
workshops.
7. Requirements documentation is barely sufficient and the team
collaborates to clarify details as features are ready for development.
8. Test cases are written up-front with the requirements/user story.
9. There is a product backlog/feature list prioritised by business value.
10. The product backlog has estimates created by the team.
11. The team knows what their velocity is.
12. Velocity is used to gauge how many user stories should be included in
each sprint/iteration.
13. Sprints/iterations are timeboxed to four weeks or less.
14. Sprint budget is calculated to determine how many product backlog
items/features can be included in the sprint/iteration.
15. The sprint/iteration ends on the agreed end date.
16. All tasks on the sprint backlog are broken down to a size that is less than
one day.
17. Requirements are expressed as user stories and written on a card.
18. The team estimates using points which indicate the relative size of each
feature on the product backlog/feature list.
19. The team generates burndown charts to track progress daily.
20. Software is tested and working at the end of each sprint/iteration.
21. The team is not disrupted during the sprint/iteration.
22. Changes are integrated throughout the sprint/iteration.
23. Automated unit testing is implemented where appropriate.
24. There is an automated build and regression test.
25. Stretch tasks are identified for inclusion in the sprint/iteration if it goes
better than expected.
26. The Product Owner is actively involved throughout each sprint.
27. All code changes are reversible and it is possible to make a release at
any time.
28. Testing is integrated throughout the lifecycle and starts on delivery of
the first feature.
 29. Impediments that hold up progress are raised, recorded on the
whiteboard and resolved in a timely fashion.
30. When someone says done, they mean DONE! (ie shippable).
31. The team uses the whiteboard to provide clear visibility of progress and
issues on a daily basis.
32. The sprint/iteration goal(s) is clearly visible on the board.
33. All user stories and tasks are displayed on the whiteboard for the
duration of the sprint/iteration.
34. Daily scrums happen at the same time every day even if the scrum
master isnt present.
35. The daily scrum is resticted to answering the standard 3 scrum questions
and lasts no more than 15 minutes.
36. There is a product demonstration/sprint review meeting at the end of
each sprint/iteration.
37. All team members, including testers and Product Owner, are included in
the sprint/iteration review.
38. The sprint/iteration review is attended by executive stakeholders.
39. There is a sprint retrospective at the end of each sprint/iteration.
40. Key metrics are reviewed and captured during each sprint retrospective.
41. All team members, including testers, are included in the sprint
retrospective meeting.
42. Actions from the sprint retrospective have a positive impact on the next
sprint/iteration.

Our approach to these statements is this:

Ask every team member of an agile team (including the product

owner, tester, manager, everyone) to review the statements honestly.
Ask them only to mark a score with a 1 if and only if they believe
they are consistent and it could be audited. In other words, if I was to
turn up at any time and ask for evidence, are you confident you could
provide it. Otherwise score 0.
Add up the 1s for each team member. Then average the score for the
team.

To what extent a team is really effective at all these points is another matter, of
course.

But if a team has really got agile principles and practices consistently nailed,
and according to every team member

They score 42 of course! :)

How agile are you?

10 Good Reasons To Do Agile Development
by Kelly Waters, 11 June 2007 | Agile Adoption, Agile Project Management

Here are 10 good reasons to apply agile development principles and

practices

1. Revenue

The iterative nature of agile development means features are delivered

incrementally, enabling some benefits to be realised early as the product
continues to develop.

2. Speed-to-market

Research suggests about 80% of all market leaders were first to market. As
well as the higher revenue from incremental delivery, agile development
philosophy also supports the notion of early and regular releases, and
perpetual beta.

3. Quality

A key principle of agile development is that testing is integrated throughout the

lifecycle, enabling regular inspection of the working product as it develops.
This allows the product owner to make adjustments if necessary and gives the
product team early sight of any quality issues.

4. Visibility

Agile development principles encourage active user involvement throughout

the products development and a very cooperative collaborative approach. This
provides excellent visibility for key stakeholders, both of the projects progress
and of the product itself, which in turn helps to ensure that expectations are
effectively managed.

5. Risk Management

Small incremental releases made visible to the product owner and product team
through its development help to identify any issues early and make it easier to
respond to change. The clear visibility in agile development helps to ensure
that any necessary decisions can be taken at the earliest possible opportunity,
while theres still time to make a material difference to the outcome.

6. Flexibility / Agility
In traditional development projects, we write a big spec up-front and then tell
business owners how expensive it is to change anything, particularly as the
project goes on. In fear of scope creep and a never-ending project, we resist
changes and put people through a change control committee to keep them to
the essential minimum. Agile development principles are different. In agile
development, change is accepted. In fact, its expected. Because the one thing
thats certain in life is change. Instead the timescale is fixed and requirements
emerge and evolve as the product is developed. Of course for this to work, its
imperative to have an actively involved stakeholder who understands this
concept and makes the necessary trade-off decisions, trading existing scope for
new.

7. Cost Control

The above approach of fixed timescales and evolving requirements enables a

fixed budget. The scope of the product and its features are variable, rather than
the cost.

8. Business Engagement/Customer Satisfaction

The active involvement of a user representative and/or product owner, the high
visibility of the product and progress, and the flexibility to change when
change is needed, create much better business engagement and customer
satisfaction. This is an important benefit that can create much more positive
and enduring working relationships.

9. Right Product

Above all other points, the ability for agile development requirements to
emerge and evolve, and the ability to embrace change (with the appropriate
trade-offs), the team build the right product. Its all too common in more
traditional projects to deliver a successful project in IT terms and find that
the product is not what was expected, needed or hoped for. In agile
development, the emphasis is absolutely on building the right product.

10. More Enjoyable!

The active involvement, cooperation and collaboration make agile development

teams a much more enjoyable place for most people. Instead of big specs, we
discuss requirements in workshops. Instead of lengthy status reports, we
collaborate around a task-board discussing progress. Instead of long project
plans and change management committees, we discuss whats right for the
product and project and the team is empowered to make decisions. In my
experience this makes it a much more rewarding approach for everyone. In turn
this helps to create highly motivated, high performance teams that are highly
cooperative.

Implications of embracing agile development principles

But there are implications. Theres no such thing as a free lunch! And theres
no magic bullet for software development. Sorry, no, you cant just drink the
cool aid :-) In exchange for all these benefits, you do get less predictability,
software and humans are still difficult, you cant blame someone else if things
dont go right, and it generally requires much more commitment and effort
from everyone involved i.e. teamwork is even more important.

Nevertheless, the advantages of agile development are really compelling.

7 Key Principles of Lean Software Development

by Kelly Waters, 16 August 2010 | Lean Development

I
havent blogged much about lean development. Im not an expert on lean, but
agile development is a great example of lean thinking in action. So I thought it
might be interesting to blog a bit about lean software development, and how I
see it

Before you can really put anything into practice, I think its important first to
understand the key principles.

Lean principles originate from the lean manufacturing approach also known as
just-in-time production, and pioneered by Toyota. Lean manufacturing is a
process management philosophy that transformed the car manufacturers
approach to building vehicles.

Lean software development originated from a popular book by Tom and Mary
Poppenieck that translates lean manufacturing principles to software
development. Tom and Marys books, training, and talks at various agile
conferences, have resulted in lean software development becoming widely
accepted within the agile development community.

So what are the 7 key principles of lean software development? They are:

1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimise The Whole

Over the next few weeks, Ill blog about each of these lean principles in turn,
explaining it as concisely as I can and giving you my personal perspective on
it