P Certification AC IPM e th d an , nt me ge na Ma ct oje Pr , nt me lop ve Agile De

Getting Agile Right Understanding the Elephant Andrew Stellman and Jennifer Greene

http://www.stellman-greene.com

Jennifer Greene and Andrew Stellman have been building software projects and writing about project management together since they first met in 1998. Their first book, “Applied Software Project Management,” was published by O’Reilly in 2005 and received widespread praise from both working project managers and academic researchers. Their second book, Head First PMP, which is now in its second edition, has helped tens of thousands of project managers pass the PMP exam. Andrew and Jennifer have given talks at companies and conferences around the world.

2005

2007 (1st ed) 2009 (2nd ed)

2008 (1st ed) 2010 (2nd ed)

2010

m a te a r fo s m le b ro p g in us ca is ss ce A wate rf a ll p ro If you’d told me what you really wanted from the beginning, I’d have built something completely different! Now I’ve got to go back to the drawing board, and the code is going to suck.

What do you mean it’s going to take another six weeks just to get back to where we were last week? What you been working on the whole time?

Project Manager Programmer

You keep building the wrong thing! Can you just take a little time to understand our business?

Business User

The team’s getting real tired of this. Keep making them miserable and they’ll jump ship.

Team Lead

Changes happen to every project, but the way we used to run our projects seemed almost designed so that changes cause conflicts.

A g ile to th e re sc ue ! (R igh t?) Unit testing, refactoring, continuous integration, and automated builds are great! They’ll definitely help me build better code!

Between our task boards, project velocity, and burndown charts we’ll have way better control of the project.

Scrum Master Developer/Architect

Doing Release Planning with User Stories really lets me explain to the team exactly what the users need.

Daily Standups and Retrospectives will bring the team together. It’ll be great once we’re all talking about the project.

Team Lead Product Owner Everybody wants something different from the project, and they each see a few practices that do something specific to help them.

ce n re fe if d a s e k a m s ct je ro p to e il g Adding a We’re definitely building better code than before, but we had to make some technical sacrifices to meet the schedule.

I’ve got some control over the way the project is run. It’s not perfect, but it’s better.

Scrum Master Developer/Architect

Great. Now I’m expected to work for the team full time. I already have a job - Can’t they meet me halfway on this?

I guess we’re delivering more often, and that’s good. But this really doesn’t feel all that different from before.

Team Lead

Product Owner It was definitely worth “going agile,” but the team didn’t get the “astonishing results” they expected. Is this really all there is to agile?

A lot of teams had this experience!

83% Of respondents to the VersionOne State of Agile Development Survey 2010 felt that projects were the same or faster than non agile projects.

Leading Causes of Failed Agile Projects Lack of Experience using Agile Methods Company Philosophy at odds with Agile Values Don’t know External Pressure To Follow Waterfal Practices Lack of Cultural Transition

87% Of respondents to the VersionOne State of Agile Development Survey 2010 felt that Agile Methodologies either improved or significantly improved their ability to manage changing priorities

Lack of Management Support Unwillingness of the Team New To Agile/Haven’t Completed Project Yet Insufficient Training

3.5

Teams do see benefit in time to ability to respond to change, butcompletion and projects fail it’s often because when Agile philosophical differences betweenof cultural and Waterfall and Agile methodologies.

7

10.5

14

* Source: VersionOne “State of Agile Development” Survey 2010

“See! I was right all along!” When someone sees individual agile practices working, he recognizes that they take what works for him already and make it better by removing extraneous formalities. Now he’s sold on agile, which is good! A team that already gets software out the door finds it easy to embrace the individual agile practices, because they provide improvements to practices the team already does. But nobody’s really changed the way the build software. They’ve just made marginal improvements. In fact, each person is more convinced than ever that he was right all along, because he just thinks agile got everyone on board with his original ideas, and that’s what made a difference. When the team brings fractured perspective to agile, they get mixed but better-than-not-doing-it results.

Why does a fractured perspective lead to just “better-than-not-doing-it” results? If I’m a project manager, then I naturally ask myself, “What does a project manager do in agile?” I’ll try to do that job the best that I can. But if I only care about doing that job, I can overplan, and guide the team away from changes that might alter the plan. It’s not just project managers. Programmers can goldplate, product owners can overreact to minor customer requests, testers can overautomate, architects can overengineer, team leads can micromanage. Just being really good at our jobs isn’t enough to become hyperproductive. We need to find a way to all work together - in a way that lets us respond to changes.

Is there a way to “un-fracture” the team’s perspective?

e h t e e s s m a te s lp e h o t s e if Th e A g ile M a n p u r p o s e b e h in d e ach p rac t ic e e on n o y r e v e g in t t e g t u o b a This is ates m m a e t ir e h t o t g in lk a t the team es iv t c e sp r e p ir e h t g in d n a and underst g on n si u c o f r e p y h st ju f o d instea t. one aspect of the projec

By keeping everyone end goals instead of focused on the intermediate proble stumbling on keep the project m ms, the team an oving forward.

The Agile Manifesto Individuals and interactions

Customer collaboration over

over processes and tools

contract negotiation

Working software over

Responding to change over

comprehensive documentation

following a plan

It’s easy for a to lose track hyper-focused team actually need. of what the users the users’ pers This makes sure that genuinely repre pectives and ideas are sented.

...because working the wrong plan causes the team to build the wrong software.

That’s what “principles over practices” means Satisfy the customer through continuous delivery Welcome changing requirements Deliver working software frequently Business and developers work together Motivate people with environment, support, and trust Face-to-face conversation is most effective

Measure progress through working software Use a process to maintain a constant pace Technical excellence and good design Simplicity is essential Self-organizing teams deliver the best designs The team regularly reflects and adjust

e v ti ec sp er p t n re fe if d a om fr ct Ever yo ne se e s th e p ro je It’s technical Design and Code.

It’s work that needs to be done.

Scrum Master Developer/Architect

It’s something valuable that solves a Real business need.

It’s a goal that the team needs to meet by working together.

Team Lead Product Owner And they're all right... but none of them can see the whole picture alone -- and that's why the adoption somehow feels incomplete.

e v ti ec sp er p t n re fe if d a om fr ct Ever yo ne se e s th e p ro je It’s a Rope!

It’s A WALL.

Scrum Master Developer/Architect

It’s A Pipe. It’s a Pillar.

Team Lead Product Owner “All of you are right. The reason every one of you is telling it differently is because each one of you touched the different part of the elephant. So, actually the elephant has all the features you mentioned." http://en.wikipedia.org/wiki/Blind_men_and_an_elephant

Agile is made up of many practices but it’s more than just the sum of those practices

User s tories Retrospe

d

ona

I

O R

n atio

b Test-first k s Ta Cumulative Flow Diagrams

m c com i t o Osm

g

IRR

Epic

I Reteration plan lea P DSDM ning se roce Atern pla ss ta ilor nn ing Pe ing rs

defe c

ped

Esca

Ri Sp sk-b ik as ed e Pro gre ssiv Co ela lla b e o bo rat rat ion ion

Daily stand-ups

g

liance

rn

Bu s Val ue graph stre a map m ping

in

Comp

V

NP

XP

el

m

Tea

od m

flict n n o C utio ce l o s re spa

ip

ersh

lead

Burn up Charts Crystal Clear

le

ant

to

gence

Definition of done

gi A

of ation nce r a l c De de depen inter

ally Minim able et Mark e r Featu

ts

Iter

ve ue va rific nt lid at at ion ion development an

Relative st ranking or Spike A Th em y p g c tives Iterative oi e R i pr ela le n C Cycle timeing Development ha io tiv rte ts ri e M rin m lphi Kanban boards ti e g ir ram D za a Ris d a n P og a ti k b Responding to change ni Pr on adj Wide Ba ust ck ed Emotio f b a Burn down y lo t i ckl n g Veloc k n o s intelli al es i w g R o Charts d

Adaptive leadership

v Ser

Product r oadmap

y

r Sto

in ol

s d r oa

pFsr a m eq

to

Re

Scrum

e

Ti

ing factor

tion a c i n u

Planning Poker

le gi

g n i x o b e m

te

Working Software

tion

im

am TDD Negotiation at r f e rm r ous g u r in t n o n o i C i f iz lf n ato I W Se gan n i io t a tegr d in F Or ams a M r M

Co-loca

A

ion

Improvement

Individuals and s interaction

s

Test-driven develo pment

lt

WI

ed prioritizati on

ea

s t i m es P li

Relative sizing FD D Continuous

Customer-valu

Id

Affinity Estimatin g

Greater than the sum of the parts Daily standup Self-organizing teams

The team understood some relationships between practices right away... Task board organizes user stories

Task boards

Release planning gives a big picture for task board User stories

Release planning Incremental design

Burndown chart and project velocity help check release planning goals

...but there’s so much more at work Self-organizing teams manage their work with task boards

Project velocity

Daily standup help teams self-organize Refactoring

Test-driven development Burndown chart

User stories and the task board drive incremental design Incremental design allows self-organizing teams to build robust architecture Test-driven development and refactoring enforce and expand incremental design Project velocity is impacted by TDD and refactoring work ... and more ...

Methodologies help you get it all in place at once Teams that pick and choose from the agile practices select only those practices that are similar to the ones they already have in place. They end up with an incrementally better version of what they have today. Adopting a whole methodolgy all at once fills in the missing links, and puts the team on the path to astonishing results.

LEAN

XP Scrum

Al l ag ile me th odolo gie s are ba se d on th e same pr inc iples, an d rel y on ever yo ne on th e te am to wo rk to ge th er an d co lle ct ive ly ow n ever y as pe ct of th e proje ct.

"These roles, each one complete and strong in itself, do not stand alone. It takes all three, operating well together, to give teams a chance at creating astonishing results and unleashing agile as a competitive advantage weapon for their company." -- Lyssa Adkins, Coaching Agile Teams

If you adopt XP incrementally, every new practice will disrupt the equilibrium you'll be fighting to achieve. You'll actually extend the period of chaos and uncertainty, making the transition all the more difficult. In my experience, teams that adopt XP incrementally make substantial improvements, but it's the teams that adopt it all at once that really excel." James Shore & Shane Warden, The Art of Agile Development "People are guided by their value systems, so creating an agile team depends on aligning with a value system-- which is why implementing APM will be nearly impossible for some teams and organizations. APM is value driven because people are are value driven . A team can employ agile practices but it won't achieve the potential benefit of agile development without embracing agile values and principles" Jim Highsmith Agile Project Management

The PMI-ACP certification gives us a framework for learning You and your team have a better chance of succeeding if you follow an existing methodology. But diving into agile from the top down can be overwhelming for a team. Even if you choose the right methodology, there are many different ways to approach it. If you’re exposed to schools of thought, you can assess for yourself the strengths and weaknesses of each methodology and approach. PMI-ACP helps you understand the entire field and the many different views of agile, so you can choose the right methodology and approach for your team. Employers know that someone with a PMI-ACP credential has a broad-based understanding of the agile principles, and how they apply to real-world projects.

How to apply for the PMI-ACP certification PMI Agile Certification Eligibility Requirements General Project Management Experience 2,000 hours working on project teams. These hours must be earned within the last 5 years. Agile Project Management Experience 1,500 hours working on agile project teams. These hours are in addition to the 2,000 hours required in general project management experience. These hours must be earned within the last 2 years. Agile Project Management Training 21 contact hours; hours must be earned in agile project management topics

PMI-ACP Certification Fees Computer based testing Computer based testing

member

$435 / €365

nonmember

$495 / €415

Paper based testing

member

$385 / €320

Paper based testing

nonmember

$445 / €370 er (PMI-ACP)SM Handbook

source: PMI Agile Certified Practition

source: http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.as px

You can download the examination handbook, get more information, and apply for the exam at the PMI website: http://www.pmi.org/agile

Questions?

Keep an eye out for our next book, a guide to agile development, project management, and the PMI-ACP certification. It’s due out in 3Q 2012 from O’Reilly! Contact us at our website: http://www.stellman-greene.com