Vanilla Scrum and Multi-Team Value Streams

Okay… so what if my value stream isn’t encapsulated within a single Scrum team? What do I do then? To some degree, I think it depends on how much of the value stream is outside the team. If external dependencies are the exception rather than the norm… or they can be easily managed and tracked… and they don’t really impact the teams ability to establish a stable velocity… I might go with Vanilla Scrum and just work really hard to make sure that the dependencies were very well managed.

If external dependencies are the norm… if they can’t be easily managed or tracked… if they tempt you to want to build Gantt charts or dependency spreadsheets… and they seem to impact your team’s ability to establish a stable velocity or deliver value… this is where you need some serious transformation work. You really need to redesign your entire organization in such a way that the external dependencies become the exception to the rule.

I think this is where most Scrum evangelists find themselves. When they talk about cross-functional feature teams that deliver value to their customers every sprint… they are really saying that we want an environment where the entire value stream is owned by the team. Product owner has unilateral decision making authority on what… the teams owns the how… and the delighted customer gets working software every sprint.

Like Glen Alleman says over on Herding Cats… that is great work if you can get it.

Most organizations aren’t there… and unless you have the ability to retool the entire organization in a way where the teams can own the entire value stream… I think unmodified Scrum is going to fail. Even if the team is successful, they become that sub-obtimatization I talked about in my last post. The good news is, we have options at our disposal that go beyond just doing Vanilla Scrum and fail trying.

I find myself, more often than not, advocating for Scrum or Kanban at the team level… and almost always Kanban at the product or enterprise value stream level. Now we can start talking about managing the organization end-to-end using a flow of value metaphor… we can identify our constraints… we can choose not to start work we can’t finish… and we can apply our limited resources where they are most likely to help get value out the door faster.

Like I said… I think there is a time and a place for Vanilla Scrum. I just want us to think through the problem and really look at why so many aren’t getting the value they expect from Scrum. If we need to augment what we know works in Scrum with what we are learning works in Kanban… and maybe even a little about what we already know from AUP and DSDM… why not? Maybe if we can find reliable transition patterns, maybe someday we can get to our single Scrum team utopia.

For now… I think we need to be somewhat pragmatic… meet teams and organizations where they are… and help them get to where they need to be. Most of our teams need tools beyond what Vanilla Scrum is prepared to offer.