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.

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.

Subscribe to Leading Agile

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

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

My Open Space De-brief at Agilepalooza Charlotte

You guys might get a kick out of seeing me in action. This video is me debriefing an open space session at Agilepalooza Charlotte a few weeks back. The topic is on scaling scrum in the enterprise. Our group discussed the four scrum of scrum patterns we've talked about here over the past few months.

It is totally weird watching yourself on video...

Subscribe to Leading Agile

Scrum of Scrums

Well... we got Agilepalooza in the bag. It was a great day. We had David Hussman, Guy Beaver, Jeff Sutherland, and Joe Little do talks. I did my Agile PMP talk... and FINALLY feel like I've got the slide deck telling the story I want to tell.

Good timing too.. I am doing that talk at Agile 2009, the PMI Global Congress, and Agile Dev Practices. About time I got it right ;-)

The day before the 'palooza... I got to do a talk on Agile Project Management with VersionOne for a local client. Jeff Sutherland was in the audience... and I've got to say... it was a little disconcerting talking about Scrum with Jeff in the crowd. He is a good guy and had nice things to say... but still.

Getting to spend some time with Jeff was pretty cool. One of the questions that came up had to do with handling a Scrum of Scrums. Jeff had an interesting take on the Scrum of Scrums concept that I had not heard before. He described the Scrum of Scrums as an abstraction mechanism. The Scrum of Scrum 'hides' the Scrum teams from the rest of the organization.

So often I hear people talking about the Scrum of Scrums as a place where the ScrumMasters get together to coordinate and share information. I don't think that definition is wrong... but it is incomplete. Jeff's description was big enough to accomodate some of the coordination teams I talk about here on Leading Agile.

The amount of coordination required is dependent on the number of dependencies between the teams:

No dependencies? Use a basic Scrum of Scrums. A basic Scrum of Scrums is where the ScrumMasters get together daily to go over impediments and coordinate activities between teams. This team is the abstraction layer between the Scrum teams and the rest of the organization.

Requirements dependencies? Use a Product Owner team. In addition to the normal coordination activities... the product owner team is reponsible for managing requirements across the Scrum teams. Any decisions that cannot... or should not... be made at the individual team level get made by the Product Owner team.

Technology dependencies? Use a Product Owner team with Architects. Adding the architect allows the Product Owner team to take into consideration the critical technology decisions that are going to span teams. In real life, this coordination can be as simple as lightweight design notes on the user story.. or as heavy as a simple architectural representations that the team uses as a baseline.

Integration dependencies? Use an Integration team. Integration teams are like feature teams that consume components or features generated by other Scrum teams. If you are in this place... you are almost guaranteed to have requirements and technology dependencies. The integration team has an actual staff of developers and testers that pull everything together.

While I have no idea if Jeff would agree with these four Scrum of Scrum models... I think they are consistent with his vision of the Scrum of Scrums as an abstraction mechanism between the teams and the rest of the organzation. For a little more on the whole Product Owner team idea... take a look at the post I did earlier this year on that very topic.

Photo source: flickr.com/photos/32286042@N00/3292030662/

Subscribe to Leading Agile