Eliminate dependencies, don’t document or accommodate them.

This morning at some ungodly hour, I got an email from Tereza Simunkova, responding to my guest blog on estimation on Mike Cohn’s site. Unless there are several women of that name in Scrum, my Google-fu tells me that she is in Prague. (Is it scary, or wonderful, or both, that we can connect across so many miles and talk about things that matter to us? I hope it’s wonderful.)

Tereza told me that she used to use story estimates in planning but that they have given it up. She went on to say that her teams sort out their dependencies using a kind of “scrum-of-scrums” meeting. They make a point of having the meetings even when they think everything is clear. She said “So we do not suppose, we explain and explain.”

What Tereza told me sounds effective and wise, and I encouraged her to write a blog or give a presentation, perhaps at the Scrum Gathering coming up in Prague late this year.

Tereza’s note reminded me of something that happened during our SAFe training.

No red yarn. Eliminate dependencies.

The Scaled Agile Framework (SAFe) uses an “all-hands meeting” to plan a “release train”, which is a series of Sprints leading to a software release. What’s not to like about this? Well, pretty much everything, but they say that it works. And, oddly enough, the pretend one that we did in our class worked, although perhaps not as intended.

Roughly speaking, the planning people in an organization using SAFe figure out a lot of what needs to be done and assign it to their many teams in some way that they think makes sense. Then there is a multi-day all hands meeting, where literally everyone on the project, as many as 250 people, get together and sort out the real plan. Sounds like fun, doesn’t it?

Red Yarn

In our class, we had five or six tables of people and they handed us a made-up project. Each table got a bunch of cards indicating what they had to do in the pretend project. Then we had a small all hands meeting. We were told to wind up with the project cards up on a whiteboard, showing the various teams and what they were doing, and with red yarn – yes, yarn – drawn between the cards showing dependencies. We did wind up with that but something else happened first.

At first, Chet and I had thought we’d just sit quietly and cooperatively, and let things happen. But we couldn’t resist. It quickly became obvious that every team had dependencies on every other and that the work was going to take many times longer than necessary as things were handed back and forth. We just couldn’t stand it.

So we began to go from team to team. If they had something we depended on, we either traded that card for one of ours, or often just convinced them to take our dependency card as well as their own. Essentially, we didn’t document the dependencies, we eliminated them by allocating the work in a sensible way. By the time we were done, there were very few remaining dependencies, and most of the teams had a nice linear flow of work to do.

Our team had a particularly light load, but I’m sure that was just a coincidence and was in no way due to Chet’s skill at convincing teams to help us out by taking our card that depended on theirs, somehow without giving anything back to us to do. Funny how statistical variation does things like that sometimes.

Does this always happen?

Our toy all hands meeting came out with a really good result: a much better plan than they gave us going in. Our instructors were all “Sure, that’s exactly what happens, the teams just figure it all out”. I’d say we were “cautiously optimistic” about that. With 250 people there, it would be really difficult to have everyone running around negotiating, and Chet and I think we are special. On the other hand, among 250 people there surely are some even more special people, so perhaps it could happen. I’d have to see one of those meetings to be sure, and even then I might remain concerned at how badly an all hands meeting could go.

That said, there’s no doubt in my mind that when the program-level people allocate plan components to teams, they’ll inject many more dependencies than are necessary, because they just can’t really know what the teams can do. In addition, many organizations have strange silos of specialization, and these cause dependencies that are often unnecessary.

One example of that is the Database Administrator (DBA) function that many organizations have. No changes can be made to the company’s databases unless the DBA people approve. This can take ages, and if your DBAs are anything like the ones I’ve dealt with, some of them are really uncooperative bullies. Others, of course, are a delight to work with.

But most teams are good enough at database to know the right thing to do and do it, most of the time. So instead of turning DBA into a bottleneck, with everything going through them, we can have the DBA group sit in with the working teams, while maintaining their own coordination in a kind of Guild approach like they use at Spotify.

Yes, it can almost always happen.

Based on all the organizations I’ve seen, a huge fraction of the dependencies between teams are artificial. They are due to poor allocation of work from above, and to the existence of unnecessary silos of responsibility.

Scrum says that a team should have all the skills necessary in order to complete an increment of work. Most of us realize now that that means we need to do design and testing as part of the team, but there’s more to be done. When we look at dependencies, we find that most of them can be readily removed, at least on our critical projects, by putting the right teams together and letting them self-organize around the work. Let me repeat that:

  • Put the right teams together.
  • Let them self-organize around the work.

Thanks, Tereza!