The Team sucks, the Backlog sucks, the Done Done sucks! I know! Let’s scale that!

I just led a discussion with Agile Charleston on this topic.

The idea for this topic comes from a talk by Mike Cottmeyer at the Scrum Gathering in Orlando.

I agreed with Mike that these three are three of the most common problems with teams, and they are fundamental. (One might argue that X is even more important. Not going to go there…)

An additional conclusion: I think these (or fixing these) are prerequisites to scaling. More on this below.

So, very quickly, when are the team, the backlog and the done-done good enough?

Here are my answers expressed much too quickly.

• Team

It is a stable, dedicated, real team that knows Scrum, values Scrum and has achieved success with Scrum.  (One could replace the word Scrum with Agile.)

They have a common mission and they believe in it together. They are motivated (at least some) and see the value of being a team, and they have shown all this in a single-team context (in part, because it is easier to teach and learn this in a single team context).

• Product Backlog

The backlog is organized (mainly) by Business Value, fairly competently, and certainly in a way that can be explained and no one laughs. (Probably including the ROI concept per story as well.)

The stories are small enough, at the top. To me, 8+ stories are needed to fill a two-week Sprint, and all 8+ are about the same size.  They have learned how to break the larger stories into smaller pieces, so that they have at least 8 stories per two-week sprint.

The ‘details’ are delivered to the team competently. Jeff Sutherland calls it the Enabling Spec. At least we have a notion like the ready, ready criteria or the ‘definition of ready’ and ‘just enough, just in time’ information is given to the team so that they do not ‘spin’ during the Sprint trying to figure out ‘What is this story really?!’ Virtually always, the implementers feel they fully understand the stories before the stories go into the Sprint. (There is still some learning in the Sprint, but at the beginning, they think they understand them.)

• ‘Done, Done’

The team has a good, fairly detailed, Definition of Done. They follow it, it means that all the bugs are fixed and it means that virtually no technical debt is growing.

With a good Product Backlog and the good DOD, of course they reliably get all the work done that they ‘commit’ to each Sprint. Reliably means roughly 70% to 83% of the Sprints end with all eight+ stories done-done — some Sprints more, and a few Sprints (out of 10) fewer stories. They are fairly reliable.

_______________________________

To me, if a team can do those things, then at least in those areas they are now ‘good enough’ to think about starting to scale.

Now, if they suck in those areas, what will happen if you ask them to scale? Basically, I think you are setting them up for failure.

Just sayin’.

Scale down. You may have to scale, but scale down. Keep it as simple as possible (but not simpler). As Einstein said.

Enough for today. Comments welcome. Thanks to the people at Agile Charleston for their thoughts expressed above.

 

 

« « Scrum 101 || Stop Starting, Start Finishing » »