Everyone has their own brand of Agile development these days.
Much like it has become cool to say "I have an iPhone", or "My next
laptop will be a Macbook Pro", for developers the catch-cry has
become "I work in an Agile development environment". Unfortunately,
a lot of the time this ends up meaning "where I work, we have
iterations of code." There is a massive misunderstanding of what it
really means to have an Agile project philosophy.
Twelve key elements drive what it means to have an Agile project
philosophy; these are directly from the Agile Manifesto:
- 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.
The number of "agile" environments that meet Element #3
("deliver software frequently") and #12 ("reflect, then adjust")
while ignoring the rest is alarming. The problem with this approach
is that the other ten elements are crucial for
those two elements to be successful. Why are they crucial? Let's
find out.
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
This perhaps, is the key driving feature of any software
development: satisfying the customer. Maybe your customer is the
traditional paying customer. Perhaps your customer is a another
business department. Your software should satisfy your customer,
not frustrate them.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage.
Change Happens. It has long been a fact of life, and frequently
the bane of development in a classic Waterfall environment. For a
project to succeed, change has to be welcomed. For anything
otherwise to happen, the result will be software that does not meet
the needs of the customer. If element #1 is accepted, then it has
to follow that usable software must be the result of the
project.
4. Business people and developers must work together daily
throughout the project.
There are frequently many layers added between developers and
business people. Project managers, technical leads and data
architects to name a few common positions. Every step between the
developers and the business people is another chance for the
message to get misconstrued, misunderstood, mismanaged and
misplaced. In short, it is a mistake.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
The gem that is missed here is the second half. The environment
that your project needs is one where the best tools are used to
accomplish the task at hand, not whatever tools have been
pre-approved for the business to use; your project needs to have
business people willing to meet and work with your developers when
your developers need them, not in two weeks when their schedule is
more open. Project members need to be able to voice opinion without
fear of retribution. Environment is so much more than a desk in a
cubicle with the air conditioner set to 70 degrees farenheit.
Finally, trust your project members to get the job done - after
all, they are motivated individuals, aren't they? You have hired
talented people. You have committed to a project methodology that
is shown to help talented people thrive. Trust those people to get
the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
No doubt in the past one or all of your a project members have
complained about having too many meetings. If you are new to Agile
Development, then surely you have complained about unproductive,
useless meetings. Rightly so, unproductive and useless meetings are
not healthy for any project.
With that said, the clearest, most concise way to communicate
ideas is certainly face-to-face. Email chains can go on for days
before all the stakeholders agree on the direction. Even the best
threaded email clients can make for very confusing conversations
when trying to find the "last" word on a subject. Private phone
calls leave other team members in the dark with regards to what the
current message is.
Fast meetings that are on point and relevent to the meeting
participants with an open forum for clarification that is visible
by all will save you time, every time.
7. Working software is the primary measure of progress.
Without working software, nobody can verify if the project is
headed for success or failure. People can report on how complete a
given feature is, but without the customer being able to use the
feature, they can never know if they adequately conveyed what they
needed. Customers make mistakes. Every member of your project team
is capable of making mistakes. Working software is your safeguard
against prolonging those mistakes. This has tangible benefits for
your project - problems found earliest in the project lifecycle
create less work, and are cheaper to resolve.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
Too many times projects suffer from burn out. The developers are
anxious to be out of the project because the work is dragging on.
The project managers are anxious to be out of the project because
the target dates have been missed. The customers are anxious to be
out of the project because they are reluctant to allow the cost to
continue to increase.
Projects that are managed in an Agile manner should avoid burn
out. If your project management, developers or customers are not
able to maintain pace, this is a sure fire sign that there is
something awry with your Agile implementation.
Your developers shouldn't feel like the project is dragging -
their work should be proactive based on the specification and its
documented change. Your project managers shouldn't be missing their
target dates, because the target dates are adjusted for the
welcomed change. Your customers shouldn't be anxious about
increasing costs because they have been involved with every
cost-increasing change.
9. Continuous attention to technical excellence and good design
enhances agility.
The motivated people hired to complete your projects should also
be talented. They should aspire to better themselves, and have an
interest in delivering a resulting product that showcases these
traits.
Good design requires less rework; this means more time spent
making sure the code that is written is of the highest quality.
Paying attention to your product quality will help you achieve
technical excelence, and results in a very agile process.
There are a lot of words and conclusions there - but the idea is
simple. You start by ensuring you hire people who have a proven
track record of good design. You follow up on this by putting tools
in place that will ensure you have quality in the code that is
comprising the product - continuous integration, with build
monitoring, and source code analysis. Finish this with a purposeful
testing regime, and quality will come forth.
10. Simplicity--the art of maximizing the amount of work not
done--is essential.
This can't be stated enough. If you want to be successful, you
must ensure that you do not do work that does not need to be done.
This is the both the building block and also the culmination of
Agile as a project strategy. In order to be agile, you must do
this. If you are agile, this is the result. Fortunately, this is
not a chicken-and-egg scenario. Starting with good design will put
your project on track for success. Welcoming change early will
continue to avoid work that is not needed. Ensuring frequently that
the software meets the customers needs will reduce the amount of
change needed, and the result will be a maximized amount of work
that does not need to be completed.
11. The best architectures, requirements, and designs emerge
from self-organizing teams.
If you hire people that are competant, talented, motivated and
proven, and the follow up by trusting your project team to each
contribute where their talents lie, you will end up with a team
that works more efficiently than a team where roles are placed by
job title. Repressing your team members talents, and shoe-horning
them into a role they are not comfortable, qualified, or capable of
will always end up with that portion of the project being completed
with a less than satisfactory result.
The agile manifesto boils these twelve elements down very
succinctly, and if the spirit is adopted, then the key elements
follow naturally:
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
What has your Agile implementation been missing lately?