Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 138 posts at DZone. You can read more from them at their website. View Full User Profile

What if I'm Not the Constraint?

05.05.2010
| 975 views |
  • submit to reddit
What if you are a manager that wants to do Scrum? You ask yourself if it's possible to encapsulate the entire value stream into a single Scrum team? What if you learn that the answer is no? What if you think this through even further, and discover that your team is not the constraint? Does it makes sense to even give Scrum a try?

What if give Scrum a try and are wildly successful? Your team becomes hyper-productive and potentially disrupts the overall balance of the system. Is that a good thing or a bad thing? It might be great for your team and their morale... but what about everyone else? Will everyone else benefit from your hyperproductivity... or will it actually slow them down. What did Goldratt teach us about what happens when one part of the system overproduces?

Consider this for a minute... if you are a senior leader looking to transform your organization to Scrum... where should you start? Start by figuring out how you create value, and what teams are constraining value... and pilot Scrum there. That way Scrum will be tied to something that actually helps the overall system get better at creating actual value. It's not overnight transformation, but it is a way to help deliver real value.

If you are a team that wants to do Scrum, understand your upstream processes and downstream processes. Don't produce software any faster than you can receive quality inputs from the upstream groups, or faster than your downstream customers can consume quality outputs. Building software faster than you have requirements, or faster than your software can be consumed is waste. It's might not be hyperproductive, but it is respectful of the overall system.

Ideally you want a blend of both... you want to see bottom up adoption with top down intent. What does this mean? Understand your system... understand how the system creates value... identify the constraints in your value stream... build Scrum teams around the constraints... build on your success at the single-team level to systematically spread Scrum to new teams that are focused on the newfound, value oriented constraint.
With this approach, hyperproductivity can be encouraged while we simultaneously focus on actual end-to-end value being delivered back to the business. I'm all for teams owning the entire value stream... I am all for overnight top-down, bottom-up transformations. I'm also for doing things that make sense and managing risk along the way. I'm not so big on pretending, or hoping for things to be different, without a well designed strategy for getting there.
References
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: