Why an Iteration is Not A Mini Waterfall
From the Drunken PM Blog
by Dave Prior
Drunken Boxing for Project Managers
“The main feature of the drunkard boxing is to hide combative hits in drunkard-like, unsteady movements and actions so as to confuse the opponent. The secret of this style of boxing is maintaining a clear mind while giving a drunken appearance.”
Yeah... just like that… but with network diagrams and burndown charts… and a wee bit less vodka.
Recent Posts
Certified Agile Leadership Training with Olaf
Don Kim - I Think, Therefore I Plan
Agile Coach to Agile Gamer - Peter Saddington
Scrum in School - A Case Study of Grandview Prep's Transformation
Forecasting Tools Based on Team Performance with Troy Magennis
Categories
20 Hour,
211,
4-Hour Body,
4-Hour Chef,
4-Hour Work Week,
Aakash Srinivasan,
Aaron Smith,
Adam Weisbart,
Adrian Howard,
Agile,
agile digitalpm,
Agile 2010,
agile 2015,
Agile Alliance,
Agile Classroom,
Agile Enterprise,
Agile Mindset,
agile reporting,
agile transformation,
Agile Tribes,
agile2015,
AgileClassroom,
AgileCraft,
AgileScout,
AgileThinking,
Ainsley Nies,
Al Goernor,
Al Shalloway,
Alistair Cockburn,
Angela Harms,
Anna Beatrice Scott,
Ansley Nies,
AOW4PM,
apocalypse now,
apple,
art of war,
Bas De Baar,
Bas Vodde,
Beyond Legacy Code,
Big Visible,
BigVIsible,
bimodal,
Blackie,
Bob Sarni,
body language,
book review,
braintrust,
branding,
breaking gantt,
Brent Beer,
Brett Pohlman,
Brian Bozzuto,
brian flatow,
brian rabon,
business agility,
Business Model Canvas,
CAL,
Canvas,
capacity,
carson pierce,
Catherine Louis,
Center for Non-Violent Communication,
Certification,
Certified Agile Leadership,
certified scrum trainer,
Charter,
Chet Hendrickson,
Chris Li,
Chris Spagnuolo,
Christine Neidhardt,
cloud,
cloud worker,
co-working,
Coach's Clinic,
Coaching,
cochlear,
commitment,
conteneo,
Corkulous,
coworking,
Craig Larman,
Crystal,
CSM for PMP,
cst,
DAD,
Dan Brown,
Dan Greening,
dan markovitz,
data,
Dave Prior,
David Anderson,
David Bernstein,
David Bland,
David J Anderson,
Dean Leffingwell,
Dean Stevens,
Declan Whelan,
Denise Jacobs,
Dennis Stevens,
Designing Together Design,
Dhaval Panchal,
diana larsen,
Digital Pm Summit,
Digital Project Management,
digitalpm,
Disciplined Agile Delivery,
Distributed Teams,
Docs to Go,
Don Kim,
dpm,
dpm2013,
drunkenpm,
drunkenpm radio,
eduscrum,
Eight Shapes,
Elizabeth Harrin,
Elizabeth Hendrickson,
Elizabeth McClellan,
EMEA,
emotional intelligence,
Enterprise Scrum,
Essential Scrum,
esther derby,
EVEF,
Evernote,
Every Voice Engaged,
Experience,
Explore It!,
facebook,
field guide,
FIRM REPORT,
First 20 Hours,
Flight Levels,
Flipboard,
FocusedObjective,
forecast,
Forecasting,
Frank Illenberger,
Fred George,
fred kluth,
funny garbage,
Gil Broza,
Github,
Global Economics,
Grandview Prep,
Greg Balestrero,
GTD,
Happy Cog,
Heartline,
Howard Sublett,
hybrid,
I Think Therefore I Plan,
Iain Frasier,
ICAgile,
Idea Wallets,
improvisation,
InfoQ,
InspireMe!,
International Consortium for Agi,
IOS4,
iPad,
iPad 2,
iPad2,
iPhone,
IT&T SIG,
J.B. Rainsberger,
James Tamm,
Jason LIttle,
Jean Tabaka,
Jeff Patton,
Jesse Fewell,
Jessica Kerr,
Jessie Shternshus,
jim benson,
Jim Tamm,
johanna rothman,
John D Cook,
john miller,
Judith Lasater,
Jutta Eckstein,
kamal manglani,
kanban,
kanbanfor1,
kanbanpad,
Kate Sullivan,
Kathy Compton,
Ken Rubin,
Ken Schwaber,
Kenny Rubin,
Keynote,
Kuala Lumpur,
lacey,
Large Scale Scrum,
Larman,
Larry Maccherone,
Larsen,
Lasater,
Leadership Meeting,
LeadingAgile,
lean,
Lean Kanban University,
Lean Systems Engineering,
LeanKit,
Leffingwell,
LESS,
Liftoff,
Linda Rising,
Lithespeed,
Livescribe,
Livescribe Pulse,
LSE,
Luis Garcia,
luke hohmann,
lyssa adkins,
Mac,
MacWorld,
Macworld 2011,
Magennis,
Malaysia,
Malaysia Scrum User Group,
Management,
Managing the Unmanagable,
Manny Gonzalez,
Marc Johnson,
Marshall Rosenberg,
Martin Rosenqvist,
mashup,
matt barcomb,
MDEC,
Merlin,
metrics,
Michael Sahota,
Michele Sliger,
Mickey W. Mantle,
Mike Cohn,
Mike Cottmeyer,
Mike Sutton,
Mike Vizdos,
mitch lacey,
MITPM,
Mode 1,
Mode 2,
modus cooperandi,
Modus Institute,
Nanette Brown,
Natalie Warnert,
Nic Sementa,
NLP,
Non Violent Communication,
Non-violent communication,
Notes Plus,
NVC,
off shore,
Offshore,
Olaf Lewitz,
Open Space,
Oredev,
Øredev,
oredev 2013,
organizational agility,
Organizational Change,
overcommitment,
pag,
Panda Transport,
Panel Picker,
Papershow,
Paul Hammond,
personal agility canvas,
personal branding,
personal kanban,
personal productivity,
personal project management,
personal projectmanagement,
Peter Saddington First15,
Petra Goltz,
Philamade,
pk,
Planning,
PM4Girls,
PMI,
PMI Portugal,
PMP,
podcast,
Product Owner,
Product Ownership,
productivity,
Project,
project management,
project manaqement,
project planning,
Project Potion,
Projects At Work,
projectshrink,
ProjectWizards,
Projet Chartering,
pulse,
rachel howard,
Radical Collaboration,
reach the peak,
Rebecca Wirfs-Brock,
review,
riaan rottier,
Ricardo Vargas,
Robyn Meredith,
Ron Jeffries,
Ron Lichty,
Rosenberg,
SAFE,
Safety,
Sam Barnes,
Sanjiv Augustine,
Scaled Agile Framework,
Schneider and Associates,
School of Rock,
Scott Ambler,
Scrum,
Scrum Alliance,
scrum but,
scrum field guide,
Scrum Gathering,
Scrum in Education,
Scrum in Schools,
scrum in waterfall,
ScrumFest,
Shane Hastie,
Showing Up,
SK Khor,
social media,
SolutionsIQ,
sprint planning,
Steffan Surdek,
stephen denning,
Steve Elliott,
Stewart Copeland,
Story Mapping,
Sun Tzu,
Swarming,
SXSW,
SXSW2012,
Tabaka,
Team Performance,
Teams,
Telecommunications,
Telepresence,
Temenos,
Test Obsessed,
the adstore,
The Ron,
theStrayMuse Louder than Ten,
Thierry Holoweck,
Things,
Thushara,
Tim Ferriss,
Tim Ferriss Experiment,
To Be Agile,
Tobias Mayer,
Tom Kealey,
Tom Mellor,
Tom Perry,
Tom Smallwood,
Tribes,
Tricia Broderick,
troy magennis,
TrustTemenos,
twitter,
Unicat,
User Stories,
value,
VCP,
video conferencing,
Virgin Digital,
Vivek Angiras,
VLC,
vocal technique,
waste,
Weisbart,
What We Say Matters,
Wijewardena,
WIzewerks,
Woody Zuill,
WWDC,
yellowpencil,
Zeldman
Date
When I am working with Project Managers who are in the throws of trying to learn Agile, there are certain discussions (debates), which can indicate that the person is going to have more of a struggle with making the change. These are usually the PMs who quickly grasp the flow of the process, but immediately begin second-guessing the system, and all of this usually happens without the PM even realizing it. After all, if you have been around a bit, and you are a halfway decent PM, you look at everything that enters your path as a potential threat to your project and start working out how you are going to get around it. This is what we are taught to do – find a workaround.
I think the bigger issue though, usually stems from the fact that the PM often does not recognize how their own expertise can be the obstacle. One of the ways this often manifests itself is through a question or declarative statement/argument about how the PMBOK is clearly, already Agile and these iterations or sprints we are talking about are nothing more than mini-waterfall projects.
Just in case any of the mini-waterfall people happen upon this… I mean you no harm. I spent about 8 years inside that argument. Please bear with me a few minutes and this will make more sense.
I have learned my lesson about trying to engage in an argument against the perception that a sprint (or iteration) is just a mini-waterfall. I don’t agree with it, but it is perception, and my experience has been that getting pulled into this one kind of like trying to debate whether Sammy Hagar was a better front man than David Lee Roth.
To me, the real issue comes down to something completely outside the steps of the process itself. A traditional PM can make all the arguments they need to in order to maintain their death grip on the belief that everything in the world can be broken down into a traditional (waterfall) project. But, no matter how much Kool-Aid they’ve consumed, there is one thing which cannot be avoided, and which they cannot deny…
A waterfall project schedule is nothing more than a guess.
“…But little Mouse, you are not alone,?
In proving foresight may be vain:?
The best laid schemes of mice and men
?Go often askew,?
And leave us nothing but grief and pain,?
For promised joy!”
(from To A Mouse by Robert Burns http://en.wikipedia.org/wiki/To_a_Mouse)
Yes, it is an educated guess and yes, there is usually math involved and we all know that if there is math, it must be true. Math aside, a traditional project schedule is just a guess based on what we think we know will happen, made at a point where we think we know enough to predict the future. (And I think we all know how good we project managers) are at predicting the future.
So, in managing a project, a significant part of the PMs gig is to come up with this educated guess and then do his/her very best to make sure to bend the very fabric of reality to match the guess. The idea is to manage to the plan.
In Agile, we focus more on the team and what we can do in order to better support and enable them, because it goes (Theory Y Alert!) that if you’ve got a bunch of smart, motivated people, you give them what they need, a clear objective and the power to make smart decisions, that the rest will take care of itself. (Remember – it says Theory Y above, not Theory X).
So, regardless of the steps in the process, the whole value system is completely different. A PM who is looking at the world through a waterfall will see the steps in the process as the thing that exists to make sure everyone stays on schedule as planned. An Agile PM is one who looks at the process as something their to support the team’s ability to perform. At the end of the day, both sides need to get stuff done, but a traditional PM uses the schedule to do this, an Agile PM enables the team to do this.
To me, if a PM is locked into the vice-grip of trying to prove that Agile is something that is already covered in the PMBOK, working their way out of that Gordian knot is usually something they will have to work through on their own, but if they can see the variance in the structure of the value system, and how that vantage point impacts their actions on the project, it is definitely a step in the right direction.
(And yeah, I’m willing to throw down on for Hagar any time, anywhere.)
Posted on: June 20, 2010 09:05 AM |
Permalink
Comments (2)
Please login or join to subscribe to this item
Dave,
Not sure what camp I should join. If I follow your discussion I can go with the waterfall folks and make increasingly accurate guesses as to how late I will be delivering something that was specified before the market changed. I''m not sure why you think I''m not getting my schedule estimates from the team or why you think the team is not responding to self-generated challenges to meet or beat their own estimates. Nonetheless, the waterfall model does not allow guesses as to what should be delivered.
On the other hand, I can go with Agile and make ever-changing guesses as to what the team will decide it should deliver, however efficient and happy they are at doing it, secure in the knowledge that they''re satisfying the stakeholders who are intimately involved in the well-defined Agile process. Hey, if it works for your client(s) who cares whether it is in the PMBOK or not - as long as you are making a profit. Follow the book that describes the work you do and how you do it.
My PM problem is that most often I have to deliver things like working chips that perform as designed, with design/manufacturing cycles measured in many, many months (and millions of dollars). Unlike "software", where you can change your mind by the day and still create a working instance, "hardware" (think of construction) needs a good part of the rigidity of the waterfall model''s specificity. [However, you''ll still likely receive a set of documents marked "as built'' at the end of the process, a well-known weakness of the waterfall model.]
Maybe the communication difficulty you find is that the two processes begin with an agreement on the definition of start, take different paths to get to the end, only to find that they disagree upon the definition of end. Alternatively, the communication problem may be that some folks are required to have letters like PMP after their name and thus have to reconcile the dichotomy between Agile knowledge and practices and the models recognized in the PMBOK Certainly, my dfficulty with your disdain for managing to an imposed schedule with rigid requirements, is that I can''t make a profit following the Agile course of delivering incremental functionality. Not all the world''s projects are software.
Norm
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Great post, this is timely for me. My team is doing a mash-up which seems to be working well thus far.
We are doing many of the standard waterfall-ish processes with major releases, traditional requirements, using a work breakdown structure and basis of estimates, etc. But our day-to-day process includes many Scrum-ish (not Scrum-but, there's a difference. I don't know what, but there has to be) processes like sprint planning/retrospectives, daily stand-ups, product/sprint logs, burndown, etc. We are doing 2-week sprints and although we defer to major releases and have thrown away the idea of releases with each sprint, this works well for the type of work we are doing (heavily database-driven development).
The combination has given the team and I a fantastic grasp of our scope and an accurate way to assess our velocity while continuously improving estimates as we move forward.
-Josh
pmStudent e-Learning
Please Login/Register to leave a comment.
|
"Man, if you gotta ask, you'll never know."
- Louis Armstrong...when asked what Jazz is.
|
