A Reminder of Why we Estimate

Estimates are simply a tool that enable people to make decisions.  In a Lean-Agile environment we estimate so that we can predict how much something will cost, when we think it will be done, if we want to explore spending more money to complete it more quickly, and whether or not we should invest our money some where else.

In a Lean-Agile environment we do not use estimates as a goal.  We do not use accuracy of estimates as a carrot or stick.  We do not use it as a primary measure of job performance.  Using estimates in these ways encourages teams to manipulate the system and reduces transparency.  It creates push systems, where managers under-promise, and ensure their teams don’t over deliver to prevent having to live up to higher standards in the future.  It encourages pushing sub standard work to production to meet objectives.  And it ignores the fact that learning always takes place as the project progresses.

To use estimates in a Lean-Agile manner, look at where the estimates varied considerably from the actuals.  Encourage and applaud leaders  who have the courage to point out where estimates varied, and look at how to improve your estimates in the future.  And above all else do NOT use estimates as a tool to hold people accountable, because it may have short term gains in a team who puts in overtime, but those gains will have long lasting impacts on morale and the interest of the team to challenge themselves in the future.

As always, I enjoy a healthy discussion, and look forward to any arguments.

 

An Argument for SAFe

*Note: Scaled Agile Framework for enterprises (SAFe) is the most commonly used defined framework for scaling Agile**.  You can find more at: http://scaledagileframework.com/

Many of the Agilists who have been at it for a decade or more see SAFe as in-congruent with everything Agile is supposed to be.  As the manifesto was being written in 2001, Agilists were called lightweight methodologists, as their delivery approaches were lightweight in nature.  It was the manifesto that led them to take on the moniker Agile.  And it is no surprise that with Leffingwell’s background from IBM he initially created a heavyweight process initially.

When I first had the opportunity to join a SAFe project in 2012, I read up on SAFe and was not impressed.  SAFe was to prescriptive, to heavy, to rigid, and frankly the best part about it was that it used Scrum and XP as the building blocks.  (At the time Leffingwell didn’t approve of Kanban at the team level, but that is a story for another day).  And I’ll never forget, Ken France who was interviewing me said, “well if you don’t like SAFe, tell me what you think we should use to scale?”  I didn’t have an answer, so I figured joining Ken’s team would be a great learning experience.

To be sure many of the things I was worried about turned out to be true, but there were also great things in SAFe that were new to me.  A larger PDCA or OODA loop with the PI (at the time called PSI), Integrated Demo’s, clear delineation of product leadership, scaled planning meetings, scaled retros.  In addition there were basic things most people created when they scaled, but didn’t have guidance for such as the Release Train Engineer, Systems Architect, and a roadmap.

Over the last few years SAFe has come a long way.  The most important change is the attitude from Leffingwell and the SAFe leaders that all of the practices are customizable (the principles are immutable). Much to many people’s dismay, mine included, Leffingwell well chooses the word framework to illustrate the point that you can take from SAFe what makes sense for your particular situation.  Whereas Ken Schwaber uses the word framework to say Scrum and now Nexus*** provide you an exoskeleton, necessary but not sufficient building blocks to deliver solutions.  Regardless of the word selection, the approach is the right one.

Scrum and Nexus take the approach of providing some basics with which you add on to to create a methodology.  With a heavy suggestion that none of the basics are altered.  SAFe takes the approach of providing you an entire methodology, or everything you will likely need, then saying change or remove what doesn’t fit for your situation.

My suggestion is all Lean and Agile coaches should have a basic understanding of SAFe as it is the most commonly used defined approach to scaling Agile and Lean currently.  From there, if you have a functioning scaled agile organization take individual practices and concepts from SAFe a la carte and incrementally if and when it makes sense to help your organization deliver. If you are starting a new program, or have decided to make a major transformation, consider SAFe against all the other approaches, and choose the what makes most sense given the current situation

Looking forward to the hate mail…

Thanks,

Dan

 

**Taken from the Version 1 State of Agile report.  I do not consider “Scrum of Scrums” a defined framework.  http://info.versionone.com/state-of-agile-report-thank-you.html
***Nexus is Scrum.org’s approach to scaling Scrum.  https://www.scrum.org/Resources/The-Nexus-Guide