Agile ConceptsAgile Concepts
by Tomek Włodarek
1.00.00© 2006-2009 Tomasz Włodarek. Lincensed under Creative Commons (by-nc-nd) conditions
bnd
agile demystified a bit
This course is
I. Not to format you blank
II. Not to convince you there is the ONE AND ONLY
only software production method (whatever it
might be)might be)
III. To give you a foundation to grow your own ideas
on how software development should look like
Excercise – The Line
Please form a line to the following continuum:
A. Your professional experience with software
development processes (1 – no process at all aka
pure chaos or student projects, 10 – formal, rigidpure chaos or student projects, 10 – formal, rigid
production processes)
Why are you standing right there?
B. Your experience with agile methods (1 – never heard
of, 10 – ya’ talkin’ to me?)
What makes you believe you’re staning at the right
place?
Why are you here, at this very session?
failed projects?
I love deadlines. I like the whooshing sound they make
as they fly by.
–Douglas Adams*http://pl.wikipedia.org/wiki/Douglas_Adams
Suprisingly lots of IT projects are being screwed up one way or another*
*some are convinced that majority of them is (Chaos Report, Standish Group)
would you like todo that again?
what’s the measure of a success?
keeping up with the scope? costs? dates?
the fact we (somehow) completed it after all?
would you like todo that again?
a) no chance on Earth!
b) yeah, maybe, but …
c) count me right in!
on time, within the budget,
to the scope...
requirements, budget, deadline...
(@#$@!) seems you can
have two of these only!?
first (intuitive) approach…
time?
scope
cost?
time?
capture all requirements�
create a plan �
follow the plan�follow the plan�
so all requirements are
fulfilled
plan–execution
traditional approach(from lack of a better name)
Planning is detailed and wishfulPlanning is detailed and wishful
Credibility of a plan is related to the scale of the project
Preparation and maintenance of the plan is costly, thus...
...exceptions are costly too
Good for defined and repeatable processes
Imply distinct production phases
Organizational structure follows, therefore competence silos emerge, communication is impaired as a result
Long production cycles, capitalization prolonged
*
more possibilities here: www.projectcartoon.com
HereHereHereHere isisisis whatwhatwhatwhat customercustomercustomercustomer wantedwantedwantedwanted………… …………herehereherehere isisisis whatwhatwhatwhat thethethethe team team team team delivereddelivereddelivereddelivered
time and budget and a
handful of requirements
ok, what’s the first thing you learn about a
project?
handful of requirements
(most important ones)
can we leverage that?
second approach…
scope?
timetime
cost
vision–exploration
adaptive (or empirical) approach(from lack of a better name)
Planning is adaptive, processes are empirical, product emergegraduallygradually
Change is at the bones of this approach
(constant verification of the way the product evolves)
Processes optimization is a must (lowering production cost and shortening time needed to explore the vast space of possibilities)
Production phases overlap
Organizational structure built upon cross-functional, self-managingteams (small ones, for the cummunication to be lightingh fast)
Short (extremely short) production cyclesFast capitalization possible
software≠mass production
software=new product development
agile software development postulate
(always)
my arguments to support this postulate
• Fast pacing technology (SW/HW)
• Complexity, cross-dependencies
• Innovation is a must in this industry (do you
know one it isn’t?)know one it isn’t?)
• Constant requirements churn (darn customers!)
• Low cost of changing the product even at
customers’ doors (yes, we can argue around
this one)
my point is...
Most of the time (read: at sane companies) new, unique
product emerge. Technology could be the same, people
could be the same, but no one really develops exactly
the same software again.
Why is that?
Because our customer needs are very, very
different each time we talk to them.
agile manifesto*
In our professional lives we 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
*http://www.agilemanifesto.org
*Historical facts
• Toyota Production System (1960), Toyota ProductDevelopment System
• Holistic approach to product development –HirotakaTakeuchi, Ikujiro Nonaka „The New New ProductTakeuchi, Ikujiro Nonaka „The New New ProductDevelopment Game” (Harvard Business Review, 1986) based on empirical studies at Fuji Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox i Hewlett-Packard and others
• Spriral life cycle model, prototyping and other methodswere traditionally used to mitigate the requirementsand complexity problems
What we expect going agile?
� better productivity achieved by focusing on the right requirementsand waste elimination
� significantly shorter time-to-market
� better allignement of software delivered with customers’ needs(requirements and expectations)
� lower project failure rate, reduced and better control of project risks
� better teamwork focused on true (market) value of delivered software � better teamwork focused on true (market) value of delivered software (oh yes, cutomer counts here!)
� more innovative ideas (thanks to team synergy)
� better quality questionable
� lower development costs highly questionable
*Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison Wesley Professional (2003)
*Poppendieck, Mary, and Poppendieck Tom, Implementing Lean Software Development, Addison-Wesley (2007)
What we should not expect about it?
• it is not a meta-process for software development
(there isn’t one, sorry) we can only show you the
direction, not a detailed roadmap
• it is not a silver-bullet – you must be really• it is not a silver-bullet – you must be really
frustrated now...
how would you
like it served?
iterative and incremental delivery
like it served?
piece of cake concept aka „walking skeleton”
� short production cycles (matter of weeks)
� each cycle vertical subset of the system emerges
fulfilling a...
� ...small subset of requirements, but in a complete� ...small subset of requirements, but in a complete
manner („end-to-end”, including testing and
documentation – have those, right?)
� in most cases system architecture might emerge
along with functionality (here’s where XP
engineering practices become really usefull)
planning horizonthey say 60% of functionality delivered
they say 80% of customer perceived productvalue stems from 20% of functionality
delivered (Pareto)
they say 60% of functionality deliveredis rarely used or is not used at all*
*Jim Johnson, et al. 2002. Keynote Speech XP 2002. The StandishGroup
an example production cycle
Diagram courtesy of Softhouse Consulting, Sweden
self-determination
agile means teamwork*
� shift from command-and-control to leadershipmanaging approach
� responsilibility for product and developmentprocesses gets delegated to the team actuallyperforming the work
*oh yes, the customer counts here!
sustainable development pace
it is quite a challenge —
to deliver working, potentialy shipable
software each 2-4 weeks according to
the commitments taken
user or looser?(did I mention the customer counts?)
ready to kiss that frog?
� prepare to work timeboxed, using short production
cycles (matter of weeks); frequent software
delivery is required to validate the vision
� focus put on business value delivered each cycle� focus put on business value delivered each cycle
(read: follow customer needs)
� focus put on processes and tools optimization
(read: cycle and cost optimization), inspecting and
adapting often (preferably every single cycle)
� ready to embrace transparency and collaboration
*Incomplete list of software production methods which fit intoagile movement and follow Lean Thinking and Agile Manifestoconcepts and believes:
• Scrum (Ken Schwaber, Jeff Sutherland, Mike Beedle)
• Dynamic System Development Method (Dane Faulkner)
• Adaptive Software Development (Jim Highsmith)• Adaptive Software Development (Jim Highsmith)
• Crystal (Alistair Cockburn)
• eXtreme Programming (Kent Beck, Ron Jeffries)
• Lean Software Development (Mary and Tom Poppendieck)
• Feature Driven Development (Jeff DeLuca)
• ...
my point is...
As long as you are motivated to deliver working
software often and you are ready and able to
prove it...
...actual ceremony you follow (project planning and
tracking tools and methods, engineering practices, office
layout, customer contracting, etc.) are not that important.
You’ll find these out.
http://www.agilemanifesto.org
http://www.agilealliance.com
http://www.apln.org
The New New Product Development Game, Hirotaka Takeuchi, Ikujiro Nonaka, Harvard Business Review, January-February 1986
Toyota Production System: Beyond Large-Scale Production, Taiichi Ohno
*
Lean Software Development: An Agile Toolkit, Mary Poppendieck, Tom Poppendieck
Agile and Iterative Development: A Manager's Guide, Craig Larman
Agile Project Management: Creating Innovative Products, Jim Highsmith
Agile Estimating and Planning, Mike Cohn, Prentice Hall, 2006
User Stories Applied, Mike Cohn, Addison Wesley, 2004
photo credit: http://www.istockphoto.com
Thank you!
Oh, and did I mention customer
counts?
Top Related