Need training, coaching, or help leading an agile transformation?
email: mike@cottmeyer.com or call: 404.312.1471

Sunday, April 25, 2010

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.

Subscribe to Leading Agile

Saturday, April 24, 2010

Will Vanilla Scrum Work for You?

In the midst of all the methodology wrangling... I've always felt that there is a time and a place for Vanilla Scrum. The problem is that most of the time, folks are giving vanilla Scrum a try when Vanilla Scrum just isn't a very good fit for their organization. So that begs the question... when is it safe to apply Vanilla Scrum in your environment?

Here is my take, borrowing a little language from the Lean/Kanban community... ask yourself, can your entire value stream be encapsulated within a single Scrum team? If there are steps in your process that happen either before your team starts, after your team starts, or you have dependencies on other teams during the development lifecycle, Vanilla Scrum probably isn't going to work.

Giving Vanilla Scrum a try without understanding your entire value stream, only results in the dev team being a local optimization in the larger enterprise. When I'm talking to clients that want to do Scrum, this is the first question I ask. If more than one team is at play... chances are I need more than Scrum to be successful.

Subscribe to Leading Agile