This document provides an overview of Agile software development. It begins by defining Agile as a project management process that encourages frequent inspection and adaptation. It then discusses some common Agile practices like Scrum and eXtreme Programming. The Agile Manifesto values individuals and interactions, working software, customer collaboration, and responding to change. Finally, it provides advice for different roles on how Agile can benefit them and their work.
2. Adrian Carr
•Software Developer for 10 years
•Currently work for Jewelry Television in Knoxville
•Worked for Fidelity Information Systems in Atlanta
•Worked for Alltel Information Systems in Atlanta
•Worked for a large non-profit in Boone, NC
•Founder and Organizer of Knoxville Agile Practitioner’s
Group (http://agileknoxville.com)
3. Disclaimer
• Be skeptical, but open minded.
• This is how I develop software. Take the parts
that make sense to you. Ignore the rest.
– Ron Jeffries
• If you currently have a high rate of success on
your projects, then this may not be the best
thing for you.
5. Some Agile Myths
• No documentation
• Cowboy coding
• No up-front design
• Agile is a silver bullet.
6. What is Agile Software
Development?
•project management process that encourages
frequent inspection and adaptation,
•a leadership philosophy that encourages
teamwork, self-organization and accountability,
•a set of engineering best practices that allow
for rapid delivery of high-quality software,
•a business approach that aligns development
with customer needs and company goals
http://en.wikipedia.org/wiki/Agile_software_development
7. Agile Practices
• Scrum-
– Small, self-organizing, cross-functional teams
– Defined roles within a team.
– Defined rules, based on project management.
– Work in short iterations, or “sprints”
– Demo progress at the end of every iteration.
– Re-plan for the next iteration, always doing
the highest value things first.
8. Agile Methodologies
• XP
– Very disciplined.
– Onsite customer
– Pair programming
– Unit testing
– Refactoring
– Frequent delivery
– Continuous integration
– Test-Driven Development
– Simplicity
9. The Agile Manifesto
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.
14. IT has an Image Problem
• Typically, we’re seen as a roadblock.
When we do succeed, we're viewed as
too slow, too expensive, or delivering
poor quality.
16. I Own or Run This Business-
What’s in it for Me?
• What is the #1 killer of projects?
– Answer: Time
• In traditional projects, we often run out of time
and something has to go. What is it?
• Quality, documentation, testing.
• In agile projects, testing and quality is a part of
every iteration. What get cut is features, and
that’s not necessarily a bad thing.
17. I Own or Run This Business-
What’s in it for Me?
• ROI
• There's a reason why you're paying these
expensive people to do this work for you.
– You want your stuff.
– You want it as soon as possible.
– You'd rather not pay more for it than you have to.
• Or, since you’re going to have to pay for it, you
at least want to get the most for your money.
– A team of 8 -10 people costs about a million dollars a
year.
18. I Own or Run This Business-
What’s in it for Me?
• Traditional Projects and the Cost of Change
– Feature bloat. You’re paying for unused or rarely
used features.
• Idea> Analysis> Development> Testing>
Deployment> Return on Investment
– Most of the costs are in the Analysis, Development,
and Testing.
• Reduced time to market.
– Agile teams will do the most important things first,
and deploy them in production as soon as possible.
19. I Own or Run This Business-
What’s in it for Me?
• Reduced risk. You get to assess it and
decide on it every few weeks.
– If you want to stop, you can.
• Changes after deployment: Agile teams
can respond more quickly, assuming they
have unit tests and quality code.
20. I Own or Run This Business-
What’s in it for Me?
• Everything is just fine…..
http://cargolaw.com/2007nightmare_ital.florida.html
21. I Own or Run This Business-
What’s in it for Me?
• Reality always wins in the end, so get
there sooner.
http://cargolaw.com/2007nightmare_ital.florida.html
22. I Own or Run This Business-
What’s in it for Me?
• What if the project is doomed to fail?
– If you are going to fail, do it fast.
http://www.cargolaw.com/2007nightmare_msc.napoli.html
23. I’m a Project Manager-
What’s in it for Me?
• Project Manager’s job is to create a
schedule, monitor progress, control the
risks, and keep people informed.
• This is very difficult to do. Especially when
people are afraid to tell the truth.
• How does a project get to be a year
behind schedule?
– Answer: One day at a time.
24. I’m a Project Manager-
What’s in it for Me?
• You can have people get started earlier.
– Typically, you don't give the green light for
developers to actually get started developing
anything until we know all the requirements. With
Agile, you don't assume that you ever know all the
requirements until you are done. You do need to
know enough to get started, but you don't need the
entire picture in detail.
– When you don’t know enough about a project, you
may want to go ahead and get started. Have very
short sprints and get feedback early and often.
25. I’m a Project Manager-
What’s in it for Me?
• Instead of managing risk with lots of
documents and contracts that create an
"us vs. them" environment, you manage
risk with real, working software, and
contracts that encourage collaboration
between different parties.
28. I’m a Project Manager-
What’s in it for Me?
• The culture of transparency makes it
easier for you to provide visibility and a
more realistic status up the chain.
• Unknowns should be known much earlier
in the process.
29. I’m a Project Manager-
What’s in it for Me?
• Managing Risk:
– There are known knowns. These are things we know
that we know. There are known unknowns. That is to
say, there are things that we know we don't know.
But there are also unknown unknowns. There are
things we don't know we don't know.
-Donald Rumsfeld
• When problems pop up early, we have lots
of options. When problems pop up at the end
of a project, our options are very limited; work
more, cut quality, etc.
30. I’m a Tester-
What’s in it for Me?
• How is QA viewed today on most
traditional projects?
– Often viewed as a roadblock, or second class
citizen.
– If bugs get into production, who gets the
blame?
– Are you ever told "Don't talk to the developers
while they are working. They are too busy,
and I don't want you to waste their time." ?
31. I’m a Tester-
What’s in it for Me?
• Agile teams elevate the role of testing.
• Quality becomes essential when teams are
repeatedly deploying software.
• You will be working on a close-knit team.
32. I’m a Tester-
What’s in it for Me?
• Inspection to find defects is waste. Inspection to
prevent defects is essential.
• A quality process builds quality into the product.
If you routinely find defects during verification,
your process is defective.
• If you have test and fix cycles, you are testing
too late. This is churn, and wasteful.
Move QA people from end of process to beginning
and middle of process. Find defects as soon as
they are created.
http://www.poppendieck.com/
33. I’m a Developer-
What’s in it for Me?
• ROI
– Developers often don't think about ROI. They view this as a
business term, and often don't care. Well, here's a revelation:
Your salary is calculated as ROI. You, your benefits, your
computer, are all calculated as ROI. You are being paid to do
something. The people paying you want a return on their
investment. The better investment you provide, the better you
will be viewed.
• A better way of working. Support vs. control.
– Imagine a work situation where your manager says “What can I
do to help you?”, instead of saying “do this, now do that, and do
it this way.”
• Trust vs. micromanagement
– The team decides the best way to reach the goals put forth in
front of them.
34. I’m a Developer-
What’s in it for Me?
• You will be working on a
close-knit team.
• Can get more done
together than you can
separately.
• Collaboration, support
system.
35. I’m a Developer-
What’s in it for Me?
• Increased communication.
• Everyone on the team is working toward
the same goals.
• Laughing.
• Sense of community.
• Sense of ownership.
36. I’m a Developer-
What’s in it for Me?
• You should gain skills you didn’t have
before.
• Less useless documentation.
• Those obstacles that you tolerate now?
They should become more obvious, and
some of them will go away if your
management is doing their job.
37. I’m a Developer-
What’s in it for Me?
• Freedom to pick tasks. No one assigns
tasks, and you have ownership over your
tasks.
• Great feeling of accomplishment.
• Food is often involved.
• Almost always results in higher morale.
38. From: “The Principles Behind the
Agile Manifesto”
• Build projects around motivated
individuals. Give them the environment
and support they need, and trust them to
get the job done.
39. Principles behind 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.
• Working software is the primary measure
of progress.
40. Principles behind the Agile
Manifesto
• 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.
41. Principles behind the Agile
Manifesto
• 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.
42. Principles behind the Agile
Manifesto
• Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely.
43. Principles behind the Agile
Manifesto
• Continuous attention to technical
excellence and good design enhances
agility.
• Simplicity--the art of maximizing the
amount of work not done--is essential.
44. Principles behind the Agile
Manifesto
• 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.
45. How Do I Start?
• Ideally, get support from the top, and
jump in with both feet.
– Hire a good consultant.
– Get your people trained. Make sure they
understand the principles as well as the
practices.
• Do it “by the book” for a year, and then
change parts of it only if it really makes
sense.
46. How Do I Start?
1. Start with Scrum.
– Fairly easy to implement.
– Quick wins
– Improved Morale
2. Add XP development practices
– Continuous integration
– Unit testing
3. Transition to Lean (After a year of successful
Scrum)
– One piece flow
– Optimizing the whole
47. How Do I Start If I can’t get
support from on top?
• Stealth agile.
– Don’t mention the words “agile”, “scrum”, or
anything else that would make people
nervous. The last thing you want is for people
to freak out.
– Talk to end users and stakeholders yourself.
Establish a relationship with your customers.
– Ask people what they intend to do with all
that documentation.
48. How Do I Start If I can’t get
support from on top?
• Stealth Agile Continued….
– Get your team to have short daily meetings.
– Talk your team into working together for one
hour or more every day in a conference room.
– Invite people to a demo every few weeks.
– Prove the results and earn respect.
– Be patient. Change takes time. Don’t get
frustrated.
49. Either Way….
• Work towards a culture of continuous improvement.
– Work to improve your skills, your company, your delivery of
software.
• Reduce complexity whenever possible.
– No one ever goes to bed thinking “Gosh, I hope my work gets a
lot more complicated tomorrow.”
• Try to make it fun. Be a part of the solution.
• “Don’t let your doubts tell you what you can’t do. This works
against change. If you really can’t do that, you can probably
do something similar. Figure it out and do it.”- Bob Schatz
• Or, as Brian Prince said not long ago…
“You can change your company or you can change your
company.”
50. Random Thoughts for Managers:
• Create a culture of trust and transparency.
• Good leadership will establish and
communicate common goals.
• At the beginning of any project, and when
new team members come on board, the
vision should be set. They should know
why they are doing the work they are
doing.
• Be a coach, not a policeman.
51. More Random Thoughts for
Managers
• The time to negotiate is before you say “yes” to a
project.
– What? Scope, cost, and time are not negotiable? They will be
later when the project is failing.
• Ask your teams what you can do to help them deliver
software better, faster, more efficiently, then do it.
• Be relentless about eliminating waste in the process.
– Tools, technologies, people that stand in the way, arcane rules,
bureaucracy, etc.
• Do more of what works and less of what doesn’t, but get
these from your people.
52. Acknowledgments
• Many of the ideas presented here are
from:
– Bob Schatz of Agile Infusion
– Jean Tabaka of Rally Software