25/9/2017 Extreme Programming: A Gentle Introduction.

Extreme Programming:
A gentle introduction

The first Extreme Programming project

was started March 6, 1996. Extreme
Programming is one of several popular Agile
Processes. It has already been proven to be very
successful at many companies of all different sizes
and industries world wide.
Extreme Programming is successful
because it stresses customer satisfaction. Instead
of delivering everything you could possibly want
on some date far in the future this process delivers
the software you need as you need it. Extreme
Programming empowers your developers to
confidently respond to changing customer
requirements, even late in the life cycle.
Extreme Programming emphasizes
teamwork. Managers, customers, and developers
are all equal partners in a collaborative team.
Extreme Programming implements a simple, yet
effective environment enabling teams to become make no sense, but when combined together a
highly productive. The team self-organizes around complete picture can be seen. The rules may
the problem to solve it as efficiently as possible. seem awkward and perhaps even naive at first,
Extreme Programming improves a but are based on sound values and principles.
software project in five essential ways; Our rules set expectations between team
communication, simplicity, feedback, respect, and members but are not the end goal themselves.
courage. Extreme Programmers constantly You will come to realize these rules define an
communicate with their customers and fellow environment that promotes team collaboration
programmers. They keep their design simple and and empowerment, that is your goal. Once
clean. They get feedback by testing their software achieved productive teamwork will continue even
starting on day one. They deliver the system to as rules are changed to fit your company's
the customers as early as possible and implement specific needs.
changes as suggested. Every small success This flow chart shows how Extreme
deepens their respect for the unique contributions Programming's rules work together. Customers
of each and every team member. With this enjoy being partners in the software process,
foundation Extreme Programmers are able to developers actively contribute regardless of
courageously respond to changing requirements experience level, and managers concentrate on
and technology. communication and relationships. Unproductive
The most surprising aspect of Extreme activities have been trimmed to reduce costs and
Programming is its simple rules. Extreme frustration of everyone involved.
Programming is a lot like a jig saw puzzle. There Take a guided tour of Extreme
are many small pieces. Individually the pieces Programming by following the trail of little
buttons, starting here.
What has changed here? | Links and Books | Extreme Programming Rules | About the Author
Copyright (c) 1999, 2000, 2001, 2004, 2009 Don Wells. All Rights reserved.
Last modified October 8, 2013.

http://www.extremeprogramming.org/ 1/1
25/9/2017
Agile Software Development: A gentle introduction
Computer science is a young science.
Computer programmers my age were trained by
engineers. That training dictated how we
approached software development for an entire
generation. But now after decades of building
software to be expensive, unwanted, and
unreliable we have come to realize software is
different. Building software is more like creating a
work of art, it requires creativity in design and
ample craftsmanship to complete. Software
remains malleable, often illogical, and incomplete
forever. Agile software development is based on
fundamental changes to what we considered
essential to software development ten years ago.
The most important thing to know about
Agile methods or processes is that there is no
such thing. There are only Agile teams. The
processes we describe as Agile are environments
for a team to learn how to be Agile.
We realize the way a team works together
is far more important than any process. While a
new process can easily improve team productivity
by a fraction, enabling your team to work
effectively as a cohesive unit can improve
productivity by several times. Of course to be
eligible for such a big improvement you must be
working at a fraction of your potential now.
Unfortunately, it isn't that uncommon.
The most brilliant programmers alive
working competitively in an ego-rich environment
can’t get as much done as ordinary programmers
working cooperatively as a self disciplined and
self-organizing team. You need a process where
team empowerment and collaboration thrive to
reach your full potential.
The second change is making the
Links and Books | Manage by Features | The Paradox of Process | Agile Modeling | Process Proverbs | About the Author
http://www.agile-process.org/
Agile Software Development: A gentle introduction.
customer, the one who funds the software
development, a valuable and essential team
member. When the dead line gets close a
traditional approach to reducing scope is to let the
developers decide what will work properly and
what won't. Instead let the customer make scope
decisions a little at a time throughout the project.
When your customer, or domain expert
works directly with the development team
everyone learns something new about the
problem. True domain expertise and experience is
essential to finding a simple, elegant, correct
solution. A document can have plenty of
information, but real knowledge is hard to put on
paper. Left alone programmers must assume they
know everything they need. When asking
questions is difficult or slow the knowledge gap
grows. The system will get built, but it won't solve
the problem like one guided by an expert on a Agile also means a fundamental change in
daily basis. how we manage our projects. If working
Perhaps the biggest problem with software is what you will deliver then measure
software development is changing requirements. your progress by how much you have right now.
Agile processes accept the reality of change We will change our management style to be based
versus the hunt for complete, rigid specifications. on getting working software done a little at a time.
There are domains where requirements can't The documents we used to create as project
change, but most projects have changing milestones may still be useful, just not as a
requirements. For most projects readily accepting measure of progress.
changes can actually cost less than ensuring Instead of managing our activities and
requirements will never change. waiting till the project ends for software, we will
We can produce working software manage our requirements and demonstrate each
starting with the first week of development so new version to the customer. It is a hard change
why not show it to the customer? We can learn so to make but it opens up new ways to develop
much more about the project requirements in the software.
context of a working system. The changes we get Take a guided tour of Agile Development
this way are usually the most important to by following the buttons starting here. Or
implement. continue your guided tour of Extreme
Programming by following the buttons. Let's
look at how we manage by features next.
Copyright 2009 Don Wells all rights reserved.
1/1
25/9/2017
Manage Your Goals Instead of Activities
With a traditional process we schedule
our activities one after another until the project
end date. Design always starts when analysis is
finished. Coding starts when the design is done,
etc. We make a plan to get everything finished on
time. At the end of the schedule we demonstrate
our new software and see if the customer likes it.
We can visualize our requirements
remaining constant throughout the project.
Requirements flow through the different activities
like a production line. We finish each activity on
all the requirements at the same time and deliver a
fully functioning program at the end. This
approach offers many cost and effort efficiencies.
We can have people who specialize in one
specific activity and change our team as each
phase is finished. Unfortunately most projects
Agile-Process.org home | Quality is Important | About the Author
Copyright 2009 Don Wells all rights reserved. Excerpt from T he Hitchhiker's Guide to the Galaxy by Doug Adams.
http://www.agile-process.org/byfeature.html
Manage by Features
can't use that efficiency because requirements get
changed before the project ends, usually right
from the start.
Agile processes like Extreme
Programming (XP) and Scrum accept that
requirements will change and create opportunities
for improvement and competitive advantage. We
just can't count on requirements being a constant.
Instead we will represent each feature the
customer wants as a user story. Story cards are a
low cost mechanism for scoping out a project
without spending our entire analysis budget up
front.
Now we can flip the axis of the previous
chart. We visualize the activities, our process itself
as the constant. Our process is applied to our
user stories in sequence. The activities are on
going and the user stories get what ever they
need.
Don't panic. With professional software
engineers on our project we can relax knowing
that the team will do what is needed to get the job
done. Any activity needed with any combination
of people will just get done without any further
scheduling or ceremony. This is the spirit and
benefit of a self organizing team.
So now when we create our schedule we
pencil in the features in order of importance. This
offers us a different kind of efficiency; we can
change our minds about what we want without
huge cost over runs. We can also stop at any time
and have the most important features done.
An Agile process takes the traditional
process and turns it 90 degrees on its side. This
allows managers to get an estimated cost per
feature instead of per activity. Customers can
make the difficult decisions about what can be left
undone in an intelligent way. If you find yourself
running short on money you will not have wasted
your money on analysis and design for features
that will never be coded and tested. Costs make
more sense this way since customers can't pick
and choose which activities should be done. This
gives us a "shopping list" style of requirements and
planning.
One of the costs of managing this way is
to always be ready for new features. We must
keep code and design quality up throughout the
entire project.
1/1
25/9/2017
Is software designed to be simple and
elegant more valuable than software that is
complex and hard to maintain? An Agile process
accepts this as an important fact.
It may surprise you to learn software rots.
Intellectually we know it really doesn't, but it
might as well. Software rot is caused by improper
design and limited project resources. Complexity
creeps in as easy code changes are made instead
of difficult design changes. Code duplication
accumulates rapidly during maintenance tasks.
After a while we notice that fixing one bug
causes several even more subtle (and expensive)
bugs to occur and the cost of maintenance goes
up significantly. Eventually the cost of maintenance
exceeds resources. It seems as if our code has
decayed on its own in spite of our best efforts.
Barry Boehm found that as software
proceeded through its life cycle the cost of
making a change became larger. Ratios of 100:1
for making a change after delivery versus project
start are common. But ratios as low as 5:1 can be
found. How flat this curve stays depends on many
individual project factors.
This cost curve is commonly interpreted to
mean that you must create infallible requirements
documents followed by complete, detailed, and
error-free designs or pay a huge price later. That
isn't what it means. Boehm's findings are not a
condemnation of change but rather a caution to
be prepared when changes occur. A well run
project keeps the cost of changes lower longer.
There are three life cycle events that seem
Agile-Process.org home | Most Important Features First | XP guided tour | About the Author
http://www.agile-process.org/change.html
Surprise! Software Rots!
Surprise! Software Rots!
to accelerate software rot. When we proclaim the
design is done and accept no more changes.
When we move the system into maintenance and
change the team's process. Last when the cost of
making vital changes exceeds our resources we
reach the wall of unmaintainability.
To stay Agile you must fight software rot.
Refactoring is the art of making design changes
over time to keep the software fit for its purpose
and ready for more changes. Unit and acceptance
tests can almost eliminate the fear that drives
inappropriate easy changes on a that minimizes the total cost of development. It
delivered system. Early delivery of partial systems
helps detect big changes before they become
expensive. An Agile process accepts that
requirements, analysis, and design are never truly
done. An Agile process runs equally well in
maintenance or development easing the transition.
We know that some changes will cost
much more than others. Boehm's findings were
that 20% of the changes make up 80% of the
effort. We accept that. We counter it with honest
estimates and use a planning process that requires
the customer to guide our spending decisions and
Copyright 2009 Don Wells all rights reserved.
cost compromises. We fight software rot from
start to finish so it can never dominate our
decisions.
One common misconception about testing
software is the cost. Most developers only know
two data points; no tests, and too many tests.
Finding bugs cost you something. If you don't test
your software you are essentially moving that cost
to your users/customers. If you only pay for fixing
bugs but not finding them you save money.
On the other hand if you set out
determined to test every possible input to your
software you will find the cost of testing rises
exponentially as you get close to 100% tested. Of
these two data points not testing is obviously
cheaper.
We know now that you can not effectively
increase software quality at the end of the project
by testing and fixing bugs. It remains low quality
but with fewer bugs. Second, designing code to
be testable lowers the cost of testing it. There is a
sweet spot between no tests and too many tests
lies some where close to testing everything that
could actually break.
Agile processes are a re-evaluation of the
way software is created. The quality of the source
code is much more important than you may think.
Just because customers don't see code doesn't
mean we are excused from the effort needed to
be ready for changes by keeping quality up,
complexity down, and full test coverage.
1/1
25/9/2017
How can we help our business grow? It
seems like an obvious question for everyone to
ask. Yet many software teams never do. When
we consider adopting an Agile process we worry
about iterations and testing. But the very first thing
you must do to become Agile is establish a good
relationship with your customers, users, and
domain experts; who ever it is that directly or
indirectly pays for your work.
The first symptom of a damaged customer
relationship is when your customer considers it a
waste of time to participate in the project. You
may have delivered software that just doesn't
meet return on investment (ROI). You may have
delivered software that is frustrating to use. You
may even have treated the customer with disdain.
In any case your customer is important and you
need to repair your relationship first.
One way to start a partnership with your
customers is to listen to their needs and respond
immediately. The best way to guarantee your
customer's time (and thus money) isn't wasted is
to involve them enough to guarantee success.
Customers who don't want to be involved in their
own software project believe the software will be
built the same even if they don't participate. This
belief needs to be dispelled.
Damage to the customer relationship can
be the result of careless disdain for the customer's
expertise by the development team. It doesn't
matter how smart you may think you are, you
simply can't expect to know as much as your
customer. You can't learn in weeks what someone
else learned over years. Respect your customer
by acknowledging their expertise, listen carefully,
defer to their authority, and never insert your own
opinions into your code.
Repairing an abused relationship takes
time. Trust takes months to establish but minutes
to destroy. Start out by being honest about your
process. Everyone will give up something before
the project is over. Giving up something first is a
good way to start. Give up on having the most
interesting and complex system around by
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
http://www.agile-process.org/fi rst.html
Most Important First
Most Important Features First
simplifying and listening to customer objectives.
Communicate with your customers simply
and in a language they understand. Most
specifications are way too technical for customers
to understand. Do you really expect your
customer to approve your SQL queries? So
where do you draw the line? What is technical
by-product and what is requirements? Many
Agile projects use stories and face to face daily
communication as requirements.
Agile projects keep a set of unfinished
features as stories in a simple spreadsheet, list, or
stack of cards that form the backlog of product
features. You want to prune or groom this list on
a regular basis by removing and destroying things
your customer or product owner doesn't need
anymore. Only keep features you would consider
paying good money for, the rest go into the trash
can or shredder. time to developers, and negotiable increments of
From the list of unfinished features you will scope to managers. Stories without value to
choose the most important. Important means the customer are counterfeit. Destroy any stories
different things to different teams. You can choose that have no value. If you find that you can't tear
the highest return on investment (ROI). You can up or delete a story without second thoughts then
choose the architecturally significant features first. you are making your stories more valuable than
Risk is a very important way to sort. You can mere currency by spending too much time on
choose the features in groups that make good them. Use cases can be especially hard to throw
business sense together. Most projects settle on a away once created unless you limit them to title,
combination. The one constraint is that the estimate, and a brief description at first.
customers guided by estimates of effort from Important project decisions are difficult
developers choose what is most important next. and stressful. Agile projects distribute the
This collection of most important features responsibility for decisions amongst the entire
is the input to the planning process. Features are team. Developers make technical desicions,
represented in a minimal way that allows rough managers make people descicions, and customers
estimates of effort, but not detail. You will make business decisions. The best way to ensure
probably only implement a fraction of the bad choices is to have one person make them all.
features, so spending time on details is a waste Spending a million dollars on a software
until they are actually part of an iteration or sprint project does not mean you have software worth a
plan. Many Agile teams use a quick way to scope million dollars. If your customers think being part
projects called story cards. of software development is wasteful you might be
Stories are the currency of your project. building the wrong software. Don't just sort user
Like money they don't have much value stories by importance, sort your entire portfolio of
themselves, just a piece of paper, but they potential projects by importance as well.
represent value and can be used to buy things. Once we know what we want to build
Stories represent valuable software to customers, next we will use iterative planning to stay on
track.
About the Author
Copyright 2009 Don Wells all rights reserved.
1/1
25/9/2017
I prefer to say iterative planning instead of
iterative development because it places the
emphasis where it belongs: You must adapt as the
project unfolds by changing your plans. You can
plan out an entire project into detailed iterations in
advance, but that isn't Agile. You change plans
based on feedback from incremental delivery of
working software. The customer/product owner
is part of your team so let them guide your project
not just at the start but day by day. Show them
the system as it is being built so they can learn
more about the solution and then listen to them.
Some Agile projects don't even have
iteration ends. They remain Agile by balancing the
need for stable requirements with the need to
change requirements while launching working
software on a regular and frequent basis.
Iterations are just an easy way to demarcate
when changes are accepted, when a new plan is
created, and when working software is released
to customers. Shorter iterations give more
opportunities to plan.
There are three Agile levels of planning.
Release planning is a group of stories selected
because they represent a usable set of features
that can be released together. These types of
plans are made by selecting the stories and
deciding how many iterations are needed or by
selecting a release date and seeing how much can
be done by then. Release plans have no details
other than a list of stories to be done by a date.
The second level of planning is the
iteration or sprint plan. This plan is a subset of the
release plan stories that will be done in the very
next iteration or sprint. Only one iteration plan
exists at a time. With our chosen collection of
important features we can now estimate the
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
http://www.agile-process.org/iterative.html
Iterative Planning
Iterative Planning
amount of effort to implement them. The people
who will do the work, namely the developers,
have authority to set the estimates. The manager
will set the total amount of work that the next
iteration can have planned. The customer then
chooses a subset of the most important features
that will fit into the next iteration.
The iteration plan will often be verified by
breaking the stories into development tasks and
estimating them with finer grain units. At this level
use cases could also be created. This greater level
of detail is permissible because iterations or
sprints are kept very short.
The third level is the daily plan. A daily
plan isn't usually represented by any artifacts. At
the daily scrum or stand up meeting everyone will
announce their plan for the day and then act on it.
Even greater detail is allowed because the plan's
duration is one day and no more. anyway.
When you slip your schedule you The changes we get late in a project are
acknowledge how far you have come and make a usually the most valuable because that is when we
new plan based on the new information. Trying to know the most about our problem domain and
catch up only puts you further behind long term. solution. Consider every dollar spent on
Even if you can make it up in a short time the development as also being spent on learning
strain on the team puts them behind schedule next about a better solution. The last change request is
week. Keep a sustainable pace going. always the one you paid the most for, so use it to
When you get ahead of schedule you your advantage.
make a new plan. Being ahead of schedule does Iterative planning is exactly what you think
occasionally happen. Keep your pace steady. it is; make a plan, build some software, and then
Some slack time is nice, but you need to keep make another plan based on what you learned.
your team challenged or they will challenge Agile processes are based on the idea that
themselves in ways you wouldn't have chosen. planning throughout the project is just as
When your customer learns something important as having a plan. Things change, plans
important about requirements or a competitive must either be short in duration or very sketchy in
advantage you make a new plan. Changes to details to remain useful.
requirements are welcome because we have How do we know how much we can get
already decided we will be making new plans done in an iteration or sprint? We need to talk
about creating honest plans.
About the Author
Copyright 2009 Don Wells all rights reserved.
1/1
25/9/2017 Honest Plans

Honest Plans

How wide is my table? I look at my table
and see it is about 6 feet wide. I then triple that to
18 feet wide so I don’t underestimate. But I
know this room is only 14 feet wide. So my final
estimate is 14 feet wide. Unfortunately we also
estimate software projects this way. Agile
processes support honest estimates by accepting
and mitigating honest mistakes.
An agile process makes honest plans
based on feedback. If a mistake is made a new
plan is created by accepting how far we have
come and revising our plans based on the new
information. There is no blame, there is no sense
of failure, we have learned something we didn't
know before.
Let's try a simple exercise. Estimate these
three lines for me. You probably just made three
estimates in inches or centimeters. Those seem
like good units of measure except every different
type of monitor displays those lines differently.
Let's estimate them in hectopixels instead. That
still doesn't help too much does it? Let me tell you
the top line is 1.5 hectopixels long. Now it is easy
to estimate the remaining two as 3 and 2
hectopixels.
That was a silly exercise but it has a
serious point. We estimate software development
using units that seem familiar to us like hours,
days, and weeks, but do we really know how
long that is? Every team will produce a different
amount of work in an hour. You can't multiply an
hour by the number of people and compute how
much will get done. People just don't add up like
that on a team. At the start of our project we
don't know what our units of estimation are. We
learn what our units mean only after we get our
first measurement of actual progress.
Some Agile projects face the problem by
using a fictitious unit like story point. It makes no
real difference what units we use so long as the
estimates are proportionate to each other. There
is nothing wrong with using units of time so long
as everyone knows they can't be measured by the
clock on the wall.
Velocity will be an important parameter to
our iterative planning process. We compute
velocity by adding up hours, days, or story point
estimates to get a single number that represents
work finished this iteration. The project manager
can use this to suggest how much work can be
done in the next iteration or sprint. The team can
commit to more or less, but it is a good number to
start with. For our very first iteration we may not
have a velocity. If we did some initial prototypes
and measured our progress we can make a guess,
but we don't know yet.
We don't break down velocity by team
members because people don't scale, only teams
do. Everyone contributes something different to a
team effort. Assuming any one team member out
of a team of 8 will be 12.5% of the capacity is
just plain wrong.
Comparing velocity between two teams is
also a bad idea. Any two teams will have different
velocities. Consider for example a team moving
as fast as possible without making mistakes. What
happens when you tell them to go faster like some
other team? Take an incredibly productive team
that severely under estimates their work, what
happens if you then decide to pay them less
because some other team consistently over
estimates? Don't start a competition to see who
has the largest estimates, that is how my table got
to be 14 feet wide.
Product owner/customer, team members/
developers, and Scrum master/manager all work
together to figure out what is feasible in the time
that is available. Product owners don't get every
feature, developers don't just work on interesting
things, and managers don't get to tell the team it
isn't doing enough. There are cost and timing
trade offs to be made and getting everyone
together to make them is best.
Honest plans are more than just truthful
estimations. They are about realizing that plans
have an expiration date. Scrum recommends a
month, Extreme Programming (XP) suggests one
week. Be honest about how long a plan can
remain useful and plan on creating a new plan
soon.
When asked to prioritize a group of
features your customer may say they are all
needed this iteration or sprint. What you have is a
customer who does not want to make the hard
decision and is delegating to the manager. If the
manager responds by saying "we will try" then he
is delegating to the developers. When a customer
refuses to prioritize features and drop one or a
manager demands a change in estimates it may
seem like that customer or manager is grabbing
control. They are in fact loosing control by
refusing to make a difficult decision. Pushing a
decision onto another person or group isn't
honest. An honest plan means you have made all
the difficult decisions you are responsible for
making.
Another change is the way estimates are
detailed; they aren't. You want a single estimate
for each feature represented in the product
backlog. Customers must weigh the different
options to find the most important things to do
next. You can't burden them with such issues as
dependencies. Put the cost of developing that
feature and that feature alone on every story.
If building this feature lowers the cost of
that feature then you have already designed some
shared code. Separate technical decisions from
requirements decisions by estimating each feature
independently and as if that is the only feature you
will build. If developing this feature still lowers
that feature's estimate then lower the estimate only
after this feature is working. Remember that you
are creating a shopping list for people without
technical backgrounds.

One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
About the Author

Copyright 2009 Don Wells all rights reserved.

http://www.agile-process.org/honest.html 1/1
25/9/2017
If your Agile project doesn't have a
heartbeat declare it dead. A steady heartbeat has
a fixed length iteration as short as you can make
it. A strong heartbeat produces working software
ready for deployment to production with
completely finished iteration/sprint commitments.
A responsive heartbeat creates a new plan each
iteration based on feedback from the previous
iteration and changing customer needs, not what
was left unfinished.
Steady your heartbeat by making your
iteration length a constant then shorten the length
to less than you think is possible. Push against
resistance to short iterations forcing your team to
learn and adapt to Agile processes. Don't just
accept that a one week iteration seems
impossible. Trust your people to figure it out and
fix existing broken procedures. Shorter iterations
actually increase the chances of being done on
time not reduce it.
Within an iteration make each day a
heartbeat all its own. Start each day with a stand
up/scrum meeting. Integrate code at least once a
day if not every couple hours. With everyone
integrating often you can frequently pull the latest
code from your repository so that you always
work in the context of the latest versions of
everything. Work as if everyday has a deadline
too.
The one essential ingredient that changes
repetitive development into iterative development
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
http://www.agile-process.org/heartbeat.html
A Project Heartbeat
A Project Heartbeat
is feedback. A shorter iteration gives you more
frequent feedback and more opportunities to
learn and steer your project. Scrum recommends
30 day sprints while Extreme Programming (XP)
recommends one week iterations.
You want your team to have a sense of
iteration length to work at a steady pace, estimate
better, and be fully prepared for iteration end.
You want your customer/product owner to see
new functionality often so they feel optimistic
about progress and can learn about their problem
and potential solution quickly. You want
managers/scrum masters to feel a sense of
urgency in removing obstacles to success so the
team continues steadily throughout the iteration
and not rush at the end.
You want to set expectations that in a
short while customers will receive a new version
of the system with the features they identified as almost nothing. With a steady easy to predict
most important. You want to reflect on how the pace we can make plans that are more likely to
process went and make improvements. You will come true.
make new plans for the next heartbeat. You will Always deliver working software at the
finish as much working software as you can and end of each and every iteration. Conduct a
make a simple measurement of progress. demonstration of new features every iteration.
A measurable, predictable, sustainable End every iteration with a retrospective on what
pace helps you plan and meet your commitments. could be done better next time. Start every
Developers are known to steal from the future by iteration with a planning meeting. Iterations must
working many extra hours to stay on schedule start from scratch and not what was left over from
today. But we all know trying to catch up always last iteration. Every iteration should feel like a
puts us farther behind because we can't continue fresh start, a blank canvas full of new
that pace. Eventually our pace slows down to opportunities for an empowered team.
About the Author
Copyright 2009 Don Wells all rights reserved.
1/1
25/9/2017
Traditional teamwork has the project
manager controlling everything. The manager is
given responsibility and authority over all
decisions and plans. If you can only trust one
person with power then this makes sense. But, if
you have a team of good people it becomes
inefficient and inhibits working at your full
potential. Don't bottle neck decisions with a single
authority. Change from one person controlling
everything to empowering the entire team.
Who is responsible, who has authority?
Everyone. The most important thing on a project
is good leadership; the least important thing is
who leads. Leadership and management are two
very different things. Leadership is about seeing a
problem then getting people together to solve it.
Any team member who knows enough to foresee
a problem also knows enough to lead the
solution. It is your responsibility to do so.
It may be counter intuitive, but a team that
is calm and confident about their work is very
decisive without a single person as boss. There
are plenty of jokes about committees being
unable to produce a good design. Bad designs
can happen to any team if the product vision isn't
strong and well voiced. That is the responsibility
of the customer/product owner.
Being the customer on an Agile project
isn't easy. You will find yourself almost constantly
in a leadership role. You must be actively involved
in most discussions to make sure your vision is
followed. You will often be put in the unenviable
position of breaking hotly debated deadlocked
discussions. You will decide when the team's
code is ready for deployment. The most difficult
part will be setting priorities and making the hard
decision of what will get done and what won't.
This is a far different role from signing the front
page of a requirements specification.
If your customer is too valuable to spend
time with your software team then maybe you are
building the wrong software. Ask the customer
what would be valuable and exciting enough to
make him want to be there with the team.
The role of developer/team member
includes programmers, architects, DBAs, testers,
all of us digital construction workers. Our
responsibilities now include deciding how to get
organized and what to do next. We will accept
the responsibility of leading ourselves and looking
for potential problems while mitigating risks. This
is different than just writing code as directed.
The manager/scrum master will have many
new responsibilities. The biggest change is just
watching the team interact and being there in the
middle of it. If relationships are broken then the
manager must repair them. If the customer isn't
leading with a consistent product vision the
manager must act. An unsuitable customer can
lead a team in circles and get nothing done. A
developer that breaks the process can slow the
entire project down. Replacing customers or
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
http://www.agile-process.org/team.html
Team Empowerment
Team Empowerment
developers is a hard choice and must be done
wisely and kindly.
People develop emotional attachments to
their projects. Agile projects are even worse
because we work together tightly. Some people
will fear getting hurt if a project fails and try to
sever their emotions or leave before they are hurt.
It can seem like people are trying to make the
project fail. I call these types of bad behavior
"escape velocity." Managers might wonder why
team members would want to hurt the project and
consider replacing them. That is the wrong point
of view; wonder instead why the project makes
people afraid they will be hurt, then fix the
project.
One management responsibility that
doesn't change is removing obstacles to success.
What does change is that you don't get to decide
what is an obstacle and what must be accepted as
non-negotiable. Your team tells you everyday at
the daily stand up/scrum meeting and you must
act to the best of your abilities.
The manager also decides if the team
should be refocused during an iteration/sprint. The
manager has the authority to schedule planning
meetings (or abnormal sprint termination) and
must do so wisely. Too many planning meetings
can create chaos and nothing will get done, too
few planning meetings doesn't provide the
customer opportunities to steer the project.
Scrum recommends no changes during the 30 day
sprint. Extreme Programming (XP) recommends
short iterations of one week so an opportunity to
change directions is never more than a few days
away. You must listen to why a mid-iteration
change is needed and decide.
Everyone needs to get used to distributed
leadership. The people most involved with a
decision make it when they face it. There is some
evidence from the Lean Development people that
putting off decisions till the latest responsible
moment when you know the most about the
impact is a good idea. I prefer to simply say that if
you know enough to see a decision must be made
and believe you know most of the consequences
then you know enough to make it. If you find it
wasn't a good decision later just estimate the cost
of going back to it and let the team negotiate with
the customer.
Highly productive self organizing teams
are not easy they require discipline. Good
leadership isn't doing what ever you want when
ever you want. The team member with the least
discipline has the most control by simply not
following the process. You must set and meet
team expectations at all times. Other team
members must be able to trust you and know
what to expect from you.
There will be decisions to make and they
don't always get made well. Decisions being
made by whoever gets there first can cause
significant amounts of disharmony. Accept that
decisions will need to be made. Accept that you
About the Author
Copyright 2009 Don Wells all rights reserved.
will not make all of them. Your responsibility as
an empowered team member is to be aware of
discussions going on that you feel strongly about.
You are responsible for joining in, and
contributing without prompting.
One thing that can expedite team
empowerment is to remove blame. Some of your
team will hesitate to make important decisions if
they feel someone else will bully them over it later.
In some companies being late with someone else
to blame is just as good as being on time.
Eliminate blame as acceptable by making it clear
no one wants to hear it.
One of the biggest misunderstandings of
team empowerment is that teams just become
empowered when you announce Agility has
arrived. The team starts out following a set of
rules designed to set expectations between team
members. Most people don't like rules because
rules usually constrain. An Agile team sets rules to
become free. Create simple rules focused on
defining the interfaces between team members. A
good example is the daily stand up/scrum
meeting. A rule to have it in the same place at the
same time for no more than 15 minutes actually
frees up time for other things.
Eventually you will feel the ebb and flood
of leadership. You learn to follow reluctant
leaders because you know they see something
you overlooked. You get organized around
problems without prompting. You will understand
team empowerment enough to mold your process
to suit your project and company easily.
If it seems like chaos could result you are
correct, unless you also change the way you
communicate. With a single control point you only
need a single completely informed person. Team
members can go months without speaking to each
other so long as one person knows everything
and controls everything. Unfortunately even with
smaller projects this command and control model
breaks down quickly. You must eliminate barriers
to communication for Agile to work. No one
works alone anymore.
1/1
25/9/2017 Daily Communication

Daily Communication

The team sits together, hopefully in a large

of granularity and frequency. It is important to
open space that promotes continuous communicate within the proper granularity. Don't
communication between everyone everyday. By waste bandwidth by getting too detailed in front
everyone I mean developers, managers, business of the wrong audience.
people, and even customers. Everyone talks face If you find yourself explaining details at the
to face every single day. That is what daily higher level ask yourself why? If you feel the need
communication means and is essential to team to explain you may be trying to justify your
empowerment. actions, so don't. Honest plans accept honest
Many Agile processes have a stand mistakes, learn from the mistake, make a new
up/scrum meeting everyday. One meeting with the plan, then move on. Remove blame from your
entire team can eliminate much miscommunication project so that everyone speaks freely and
later. Setting a consistent time and place helpsopenly. You don't need an excuse for making a
make the meeting happen and adds to the feeling mistake you just need to learn from it.
of a project heartbeat. During the daily meeting One important communication channel
everyone answers at least three questions; what omitted from the flow chart are the walls that
did you do yesterday, what will you do today, and
surround your project space. Post large charts
what blocks your progress. Let this be an honestthat can be read from a distance to encourage
plan for what you will do today. change without bullying. Post designs as Agile
When you keep the meeting short you models on white boards or Agile documents. The interactively. Make a customer part of your
won't have a problem getting people to walls of your projects space can communicate project team.
participate. Scrum has rules about who can speakhonestly and neutrally if you use them well. On a traditional project we do our
at this meeting. The customer/product owner, Count how many people are on the analysis up front as a specified activity with an
developers/team members, and manager/scrum project, now communicate like a group that size. end date. The result is a project milestone called
master talks, everyone else is welcome to listenEven a project in a huge company can the requirements document. This document is
and take notes. People outside of the team like to
communicate like a small start up among approved by the customer as correct and
show up and drop stressful deadlines in these themselves. Communication efficiency drops off complete. Now you may start building. The
meetings. You may need Scrum's rule about who rapidly with increasing distance so get everyone problem with this is that we often encode our
can talk if management uses this meeting as a together. Being able to see meetings and requirements in a language no customer should be
convenient way to lecture to the entire team gatherings occur and eavesdrop as needed boosts expected to learn and understand. Signing off on
instead of a give and take communication communication. Hermits don’t share, communities a document written in a language you don't
as intended. are based on sharing and being near each other. understand is just as valuable as you expect.
There is more to owning software than Instead sit together and talk about what you want.
just paying for it. Intellectual property is only I often hear people criticize Agile
valuable if you understand it, can modify it, or processes because the expert's time is way too
reproduce it as needed. People are not valuable to be available. They often speak with
disposable, they are needed to continue owning anger and suggest customer representatives as a
the intellectual property you are investing in. viable alternative. My thoughts are always the
Allow everyone to talk to everyone else to avoid same; if the return on investment (ROI) is so low
loosing your competitive edge. Keeping people that you can't afford spending an expert's time
isolated doesn't just slow down your development you are solving the wrong problem.
process, it throws your intellectual property away. You will also be adapting your process to
"The customer didn't know what he your project in an iterative way. On a regular and
wanted" is a common excuse for project failure frequent basis you will talk about your project
and it is invalid. The customer knows exactly and corporate culture to figure out how the
what he wants; a solution to the problem at hand. process needs to change. These meetings are
If the project fails because the wrong software called retrospectives and are a very important
was built it isn't the customers who are at fault it is part of the iterative process. Schedule a
This flow chart shows feedback loops or the developers. Developers are responsible for
retrospective after each iteration or at least every
channels of communication recommended by asking the right questions until a clear picture of
other iteration. Ask team members what needs to
Extreme Programming (XP) you should have the problem and a good solution is found
be improved and what worked well. Also ask
many of them on any Agile project. These
what is extra process baggage that can be
communication channels are arranged in a spiral
eliminated.

One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
About the Author
Copyright 2009 Don Wells all rights reserved.

http://www.agile-process.org/communicate.html 1/1
25/9/2017
Very important to Agile projects but often
overlooked is getting working software done
regularly and frequently. The definition of working
software may vary slightly between projects, but
not much. Working software is fully integrated,
tested, and ready to be shipped to customers or
deployed into production. That doesn't mean you
tried it a couple times and it ran without aborting.
It means you created unit tests, QA tests, and
actually looked at output to prove it works. It isn't
as difficult as you think. In fact some teams
deploy new software into production every single
day.
When we were managing our projects by
activity we needed a way to guard our progress.
The people who finished an activity like analysis
might not participate in design or coding. So we
safe guarded all progress by creating extensive
documentation of what was decided and what
was done. We had people with authority sign the
front page to verify our efforts were going in the
right direction.
An Agile project has all activities going on
all the time as needed. We can't use documents
with signatures to guard our progress. Instead
Agile teams rely on automated tests and working
software to safe guard progress. We show
working software to our customer/product owner
often and accept changes to ensure our efforts
continue in the right direction. You can't empower
your team to find its own solution using
documents with signatures, you need the intense
feedback that working software provides.
Agile-Process.org home | The Paradox of Process | About the Author
http://www.agile-process.org/working.html
Working Software
Working Software
Working software is an Agile theme that
affects everything you do. You will set a project
heartbeat, but unless you produce working
software each and every iteration your heart beat
won't be meaningful. Honest plans are only
possible if you have honest estimates based on
done meaning finished and working. Iterative
planning adapts to changes, but good changes
only come from customers looking at, and trying
out a working incremental version of the system.
A big part of your project heartbeat is delivering
working software into production regularly and
frequently.
Take your iteration end seriously. If you
are using one week iterations it can be tempting to
just push unfinished work into the next iteration. If
you find yourself approaching iteration end with
several unfinished stories the right thing to do is
get your team together and decide which stories
how much is working right now. You can't
could be finished if you work together on them. consider the project half done if all you have is a
Your project's velocity is a measure of how much
design document. This means you will need to
software you got working, not how much you
iteratively deliver working software and
promise to have working next week.
demonstrate that it is fit for it's purpose. Anything
When we produce working software in else isn't considered measurable, predictable
small increments we are no longer locked into a
progress.
minimum cost to get return on investment (ROI).
Working software ready for production
We don't need to spend the entire budget (usually
release is easy when you have automated unit
with overruns) to get something back from our tests, automated acceptance/QA tests, and a one
project. We can stop when ever we think we button build that runs them in a reasonable time.
have done enough or a higher priority projects Your customers don't always know the best way
comes along. how to solve their problem, help them by
Measure your progress honestly. If
demonstrating working software frequently.
software is what you intend to deliver than count
Copyright 2009 Don Wells all rights reserved.
1/1
25/9/2017 The Paradox of Process

The Paradox of Process

An agile process creates plans as needed

and allows teams to self organize directly around a below shows the number of unit tests for the
problem. We must trust our process to keep our EarlyPay project at InStream Financial Services.
project on track, but there is a paradox It was a large system that didn't have unit tests
associated with any process: If you don't use your yet. We added tests when we added new features
process it can't help you; if your process doesn't and fixed bugs. After a year there were no bugs in
help, you won't use it. production anymore. The big pay off came after
I use a personal digital assistant (PDA) or two years when we had complete coverage and
handheld organizer as a metaphor. You want your could confidently redesign the system. We
PDA to alert you every time you have a meeting. simplified and removed about one third of the
But right out of the box that PDA won't alert you code while maintaining a perfect record of no
to anything. You must move all your appointments production bugs.
onto it. But even more than that your PDA comes Many of the rules and practices of Agile
The obvious consequence of the paradox
with a hidden process: You must constantly keep processes seem like a waste of time when you
of process is that when you begin a new process
it up to date. You must enter every appointment start them. It takes time and patience to get to a
it seems totally useless and a waste of time. You
with out fail. If you don't it will fail to remind you. point where they begin to help you in unexpected
need to have faith and really use the process until
A PDA is a tool that helps implement the ways.
it begins to return on your investment.
hidden process of writing down every Unit testing is a prime example. The graph
appointment in one place and then checking for
appointments regularly. You could use a pencil
and a paper calendar to implement that process
and get most of the benefit. It's that hidden
process that's important, not the implementation.
People have told me their software process is
Rational Rose(TM). Rose is a UML tool, not a
process. Installing an automated build tool instead
of a real continuous integration process is another
common mistake. Never confuse having a tool
with actually having a process.

Agile-Process.org home | Models are Paintings | XP guided tour | About the Author

Copyright 2004, 2009 Don Wells all rights reserved. Rational Rose is a trademark of the IBM Corporation.

http://www.agile-process.org/process.html 1/1
25/9/2017
Agile Models Are Paintings, Not Photographs.
Models are useful as tools of discovery.
The process of creating a model is just as
important as the model itself, often more. When
you are unsure about how to proceed you can
model to get your direction. When confronted
with code that defies understanding modeling can
help. Models include flowcharts, class diagrams,
interaction diagrams, UI mock ups, etc. There are
many different model types well suited to learning
new things about your project.
Models can become very anti-agile if you
let them. Don't think of models like a photograph,
instead consider them like a painting. Above is a
photograph of the night sky. It correctly notes the
position and size of all the stars. Above right is a
Van Gogh painting of the night sky. The artist is
communicating something important about the
sky. Van Gogh is telling us his impression of what
a night sky means. This is exactly how you want
to approach modeling.
"If you understand your painting
beforehand, you might as well not paint it."
Salvador Dali could just as easily have been
talking about Agile models. Create them to
understand. Printing huge models generated by a
tool from code is another way to view your code
but it isn't an Agile model. A painting of your
code that highlights important objects and
interactions for a specific operation or process
step is an Agile model.
The best modeling tools are an old
fashioned fountain pen and an artist's blank sketch
book with pages that pull out. These simple tools
let each model be unique with a language of its
own. Some things will be exaggerated, others
omitted. A model should express the modeler's
Agile-Process.org home | Agile Process Proverbs | About the Author
http://www.agile-process.org/model.html
Agile Models are Paintings
Create a model to answer specific
questions, keep the answer short and concise. If
you think others could learn from your model you
can keep the document, but make it Agile. Saving
a document is an implicit agreement to keep it up
to date or destroy it. Restrict documents to one
page and post them on a wall. Then you can
easily update them by finding all the old versions
and replacing them with the new edition. If you
thoughts and subjective point of view. So be
decide to destroy it, just pull down all the
creative, use a drop shadow to indicate more
obsolete pages and throw them out.
important objects, put a shinning star on newly
created objects, try drawing little stacks to show
collections. UML was created to document
complexity, not expose it. Instead of the typical
class hierarchy diagram try an instance diagram to
find complexity. Don't let conventions stop you
from communicating your thoughts rather than
details.
Don't spend time getting everything just
right. You certainly don't want to spend time
getting all the lines straight. When modeling ask
yourself a simple question: How much effort
should I put into this model if it will be thrown
away tomorrow? That is how you know when
you are done modeling.
CRC cards can be used two different
ways. Originally a card would have class name, Depending on your project you may also
responsibilities, and collaborations. The second need some larger documents for validation or
way is more Agile. Get your team together and standards compliance. Those are not Agile
use cards as instances instead of classes. Move documents but need to be created and archived
the cards around with your hands to show anyway. Don't use your Agile process as an
messages and interactions. Stack them to show argument to avoid creating them. Create them
collections. Overlap them to show collaborations. just-in-time and as efficiently as possible.
Designing this way uses the artistic right side of Having a model printed out with straight
your brain, the side that understands relationships lines and square corners in a specially labeled
and movement. You will find that you don't need binder does not mean you have a good design, it
to label more than a few cards to tell them apart. just means you have a well documented one. I
Sometimes the activity of modeling can be have found that a huge UML document is an
more important than the model. Agile CRC cards excellent way to hide a complex design. Agile
are an expression of that. You model together as modeling can help discover areas of complexity
a team. At the end the model disappears but the and eliminate them. You can use tools that create
understanding, insight, and team collaboration diagrams as an alternative to browsing source
remains. Designing this way is more dynamic and code, but not as an alternative to Agile modeling.
object oriented than static versions.
Copyright 2009 Don Wells all rights reserved.
1/1
25/9/2017 Agile Process Proverbs

Agile Process Proverbs

Here are some things to think about. I Documentation/Models Process

have summarized them into pithy sentences, Agile models are paintings, not photographs. If you don't use your process it can't help
added bullet points and called them proverbs to The creation of a document is an implicit you; if your process doesn't help, you won't use
make them sound important. Don't be fooled. agreement to keep it up to date or destroy it. it.
These are ideas, not rules. Ideas to help you think Without the use they are just cases. The one essential ingredient that turns
about making your current process, what ever it Ideas move faster than documents. repetitive development into iterative development
is, a more Agile process. is feedback.
Customers/Product Owners If less doesn't work try more, if more doesn't
Iterative Planning There is more to owning software than just work try less, if neither works stop doing it.
The best way to meet customer objectives is paying for it. If 10 people slow the project down by just
to explicitly schedule their completion. Negotiating is basic to being human, don't 10% each it will take twice as long.
Trying to catch up is the fastest way to get give it up that right before the project even begins. If it isn't fun you're doing something wrong.
further behind. A hammer without a good process is a sore
The changes you get late in a project are Managers/Scrum Masters thumb waiting to happen.
very valuable because you paid the most to get Challenge your team intellectually or they will Process is something you do, not something
them. challenge themselves in ways you wouldn't have you do to someone.
One third of your requirements will represent chosen. The person least likely to save time is the
two thirds of the project's value. Demanding estimates change seems like person in the biggest hurry.
Showing someone something they taking control, but you lose control by not making The least disciplined team member has the
can change is helpful, showing something they a decision. greatest control over your process.
can't change is spiteful. People don't scale, teams do.
Iterative development gives you a few "oh The only way to guarantee bad decisions is Simplicity
drat"s during development instead of one big to make all of them yourself. Simple is subjective so judge it subjectively
"AW SHIT" at the end. as testable, browsable, understandable, and
Developers/Team Members explainable.
Honest Plans Big changes cause big problems. The best way to guarantee it costs too much
An estimate not based on a measurement is Egoless programming doesn't work; expand is to add something you don't need.
a guess; an estimate based on a measurement is a your ego to include everyone's code. If it takes you too long to refactor than you
prediction. Don't guess, measure it. are not refactoring enough.
He who does the work sets the estimate. Don't theorize, try it. A simple solution always takes less time than
If software is what you want to deliver then Everything you did today can be done over a complex one.
measure progress by how much you have tomorrow in half an hour and be better. If you always try the simplest thing next you
working right now. Measure twice cut once saves wood, but will always work as simply as you can.
software isn't made of wood.
Team Empowerment The best way to get help is to offer help. Design
The most important thing on a project is Who ever finds a problem knows enough to
good leadership; the least important thing is who Testing design a solution.
leads. The first test is the hardest. Flexibility isn't building for every imaginable
If you can see a need for leadership you Your test suite is more valuable than your possibility; it's having as little to change as
know enough to lead. code. possible.
When you only have responsibility you will The harder the test is to create the greater A good design can be explained to someone
know worry, but when you also have authority your savings. else using four blank cards.
you will know opportunity. Where there is a will there is a way to test. A design which doesn't meet business needs
The organization of your team will be If you want a good suite of tests next year is bad, no matter how pretty.
reflected in the code. (Conway's Law) you must start collecting them today. UML was designed to document complexity,
Calm and relaxed plus confident yields not expose it.
decisive.
Count how many people are on the project, Finish your guided tour with Links and Books.
now communicate like a group that size.
Hermits don’t share, communities are based
on sharing.
Agile-Process.org home |Links and Books | About the Author

Copyright 2009 Don Wells all rights reserved.

http://www.agile-process.org/proverbs.html 1/1