What if I’m Not the Constraint?
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.
Comments (9)
Mike Cottmeyer
There is a really interesting irony here. Just talked with a guy over lunch at the PMI PDD event, right after publishing this post, who has a manager doing exactly what we are talking about here. He is doing Scrum… he does not own the value stream… AND he is doing Scrum in a poor, undisciplined manner. It's not reflecting well on the manager… or on Scrum. Very unfortunate situation.
Bill Gaiennie
It is seen far too often, and worse yet, it is often these first trials of Scrum that then leave a bad taste in everyone's mouth, thus minimizing the likelihood that the organization will try it again.
Mr. Now
Mike,
Scrum is optimized for small teams and not enterprises. Teams are the easy target to shoot at. This explains the astonishing success of Scrum.
You want to figure out everything about enterprises. The quest of "figuring everything out" can lead to all kinds of drama.
http://www.psychologytoday.com/articles/200810/the-art-now-six-steps-living-in-the-moment?page=4
Mindfulness is the only intentional, systematic activity that is not about trying to improve Scrum, or get anywhere else with Scrum or Kanban. It is simply a matter of realizing where you already are. A cartoon from The New Yorker sums it up: Two monks are sitting side by side, meditating on Scrum and Kanban. The younger one is giving the older one a quizzical look, to which the older one responds, "Nothing happens next with Scrum or Kanban. This is it."
Mike Cottmeyer
Mr. Now… not sure if I should take your comment seriously. Are you suggesting we just leave things as they are and appreciate being in the moment? Are you suggesting we don't try to understand more or move things forward? It just is what it is?
Andrew Fuqua
Mike,
In the case of software development, I'd argue that there is value in a team's local self-optimization in spite of the inability of upstream and downstream processes to support the faster team. That value comes from the ability of management to reallocate people to other projects on other teams. Countless times I've seen developers on teams with excess capacity change to a PO, sales, support or test role. This can be particularly useful when those developers have seen a successfully run Scrum or Agile or Lean project and they spread that knowledge throughout the enterprise.
Mike Cottmeyer
I agree Andrew… IF that what happens. Quite often though, that's not what happens.
Andrew Fuqua
I'm taking exception to your statement that "If you are a team that wants to do Scrum… [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."
Are you saying that I should be mediocre because my upstream neighbor is mediocre? I shouldn't strive for continuous improvement if my downstream neighbor doesn't?
Often I see teams pick up the slack left by the other teams when they become more productive. Sure, that's not the best situation. The best situation is for senior management to optimize the whole system, as you point out. But even if that isn't happening, there is no reason for the team not to undertake self-improvement. Their job-enrichment can be good for the company, TOC overproduction issues notwithstanding.
Mike Cottmeyer
Andrew – I don't think you can blow off the TOC issues. What does it do to the overall system if you overproduce?
I'm going to try to address your concerns in a blog post, either today, or later in the week. I've got a morning meeting that might prevent me from blogging today ;-)
Stephen
I am coming to this late – what role if any do you see the Product Owner playing in the Scrum of Scrum?