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?