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 147 posts at DZone. You can read more from them at their website. View Full User Profile
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?
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.