'Teams That Finish Early Accelerate Faster'

This is an excellent article: Teams That Finish Early Accelerate Faster.  It is by Jeff Sutherland and others.

It addresses a key issue:  How do we get Scrum teams to be more successful?

One answer is that ‘scrum’ teams are not always doing Scrum. More likely, they are not doing all of Scrum.  And we know from experience that not doing all of Scrum (which is a bare framework) is often the key reason for the reduced success.

But there are also things to ‘add’ to the bare framework of Scrum.  And here are the key ideas mentioned in Dr. Sutherland’s article.

• Stable Teams

We need the Scrum Team to be stable.  It is hard to improve if the people are changing.  Key to success.

• Yesterday’s Weather

This is a well-known agile/scrum pattern.  Knowing your velocity, only ‘commit’ in the sprint to the same velocity that you succeed in finishing last Sprint.

Note that you can get better, increase your velocity, by removing impediments and then by completing additional (small) stories at the end of the Sprint.

• Swarming

This is a less well known pattern, one where there is less understanding about how to do it well. There is also general discussion in the community about ‘swarming’ but it is not about this pattern…at least not directly about this pattern.

The idea is that each story in the Sprint has a Captain. If a story is in trouble, then everyone in the Team should offer to help the Captain, and in general the Captain must be open to help. The Captain can decide how much help is needed, will be useful…although he/she may get feedback from the Team on his/her decisions.

This is similar to ‘single piece continuous flow’ in Lean.

• Interrupt Pattern

Implement a simple process to minimize and handle urgent, high-priority interrupt work during the Sprint.

• Daily Clean Code

Fix all bugs in less than a day. Aim to have a completely clean base of code at the end of every day.

• Emergency Procedure

If the Team gets behind in a Sprint, have an identified ’emergency procedure’ to execute to get back into a good position quickly.  (Specific steps are proposed.)

• Scrumming the Scrum

Identify the single most important impediment in the Sprint Retrospective and remove it before the end of the next sprint.

• Happiness Metric

Ask 2 questions on a 1-5 scale.  If the Team average drops, gather the Team to identify the root cause and address it.

• Teams that Finish Early Accelerate Faster

The Team should only ‘commit’ to what they know they can accomplish ‘reliably’ (70+% of the time).  Once they become reliable, then they can use the other patterns to accelerate more (increase the Velocity).

Apparently we must repeat: We are accelerating without working any harder (any more hours).  And only working reasonable hours.  How? By working more cleverly and with greater automation, via fixing impediments.

***

I summarized some of the key points of paper, sometimes loosely, with some of my ideas.

There are many other great ideas and further explanation in the paper itself.

Enjoy!  And help you Team get better, and help your customers have a better life!

***

Comments welcome!

Teams that Finish Early Accelerate Fasters

Jeff Sutherland has recommended this recent article: “Teams that Finish Early Accelerate Faster.”

Here it is: teamsthatfinishearlyacceleratefaster

What’s the deal?

Well, many of us are seeing ‘scrum’ that is not … not achieving the results we would like to see.  I say it this way: we want everyone to achieve very significantly better results.  Jeff Sutherland talks of it as hyper-productivity.  We want a better life for you, for your Team, and for your customers.

And, ‘scrum’ as people are doing it is not getting us there often enough.  Are they really doing Scrum?  Well, I think often not, and we do think if they did real Scrum, that alone would make a significant difference.  In addition to that, Jeff Sutherland is recommending these 9 additional patterns.  This makes sense to me.

Please try them!

Here’s to much better Scrum.

Enabling Specifications

We recommend using the ‘Enabling Specification’ practice. This is NOT part of the bare framework of Scrum. But it is a frequently recommended practice. Typically recommended.

This is: Just-enough, just-in-time documentation. Meaning that the implementers in the Scrum Team have enough information to build the user story correctly the first time. Or at least they think they do before the Sprint Planning Meeting.

We are NOT recommending eliminating conversations. In fact, we always want more conversations.  The PO should be available during the Sprint to answer questions ‘immediately’. (Of course, he/she is not always able to answer them immediately, but that is what we want.)

Jeff Sutherland says this is like a patent. An enabling specification.  See the Scrum PLOP, and this blog post. Some call it an Enabling Specification.

When is each Enabling Spec built?  Just-in-time. Just before the sprint in which that user story is built.

Who creates the Enabling Spec?  Well, it is built by the right people, of course. Typically the PO will help, if there is a BA-type person in the Team helps, a BA or two outside the Team might help, a business stakeholder might help, etc. It depends on the situation.

The PO is ultimately responsible for the quality of the Enabling Specs. And the implementers in the Team are the final authority of what should be in them.

So, the Enabling Specs are ‘owned’ by the Product Owner. And then the PO must find the right people to build them. (I think it best to usually think of the Enabling Specs as one-to-one with the user stories.)

What does an Enabling Spec contain?  Well, just what the implementers want and need.  And this varies a lot from situation to situation. It depends on the nature of the story, it depends on the memories of the implementers, it depends on what they already know well (please do NOT repeat what they already know well), it depends on their skills and experience, …it depends on many things.

Here are some things that people have wanted an Enabling Spec to include:

a use case (picture)
business rules
mock-up
wire frames (I won’t bother to give a fine definition to distinguish a mock-up from a wire frame.  Although we can distinguish a picture of the main ‘screen’ we are working on, versus a picture that gives us a sense of the ‘flow’ from one ‘screen’ to another.)
business flow (often quite similar to a use case)
date elements (or columns or however you think of the data)
questions answered (the implementers can ask almost any question and we write down the answer(s))
technical issues – decisions or description of some key technical issues. One simple example: ‘The scope is only iOS.’
data flow diagram
design issues – Example: if this story will break old design patterns or create new design patterns, talk about it a bit.
acceptance criteria
other information, assumptions, or notes
If you can have a conversation and the specific implementers take good notes, and will remember correctly, the information does NOT have to be documented (again) in the Enabling Spec.

And you do not have to cover all the above sections in every Enabling Spec.  You should NOT cover all these things. Pick and choose amongst them, what is most important, most useful to your team and your situation.

And exactly what to include (or exclude) from the Enabling Spec for your Team will evolve.  The PO is always asking the Team two questions:

What did this Enabling Spec include that you found useless? (Remove that stuff on the future.)
What did we leave out in this Enabling Spec? (Start adding that stuff, where appropriate.)
Couple of things to note:

It is more important that the implementers get the information they need quickly than that the Team (PO) has an Enabling Spec.

We do not build all the Enabling Specs up-front.  This would be a big waste and a big delay.  We only build Enabling Specs for the stories just about to go into the Sprint.  Are we always correct (in guessing ahead of time which stories will go in the next sprint)?  No. But it is usually a very good guess.

Is everything defined in the Enabling Spec?  No. Only the essential stuff.  We fully expect some questions to be raised during the Sprint and answered quickly.  If the PO is less available or cannot answer quickly, then probably the Enabling Specs are fuller.  If the PO is available and can answer quickly, then the Enabling Specs are probably smaller.

Am I ‘successful’ if I just ‘complete’ the Enabling Spec?  No!  The software (product) must be truly useful. An implementer does not have ‘CYA’ simply by ‘doing’ the Enabling Spec. The real test is real progress in satisfying the customer.  The Enabling Spec is only a means to that end.

How big are they?  That varies of course.  How big do you draw? (They are largely pictures.)  Probably slightly smaller than they should be. (smile)  Half a page. 1 page. 2 pages.  Something like that.  And that is based in part on the assumption of about 8 stories in a 2 week Sprint.

Can this help you?  We of course think ‘yes’.  How much it will help will partly be based on how much the Team is ‘spinning’ on the requirements.  Sometimes the spinning is clear and obvious, and sometimes the spinning is hidden.

Does this help you?

Store Points rather than Hours

Jeff Sutherland has a great post about this, here.  A must read.

Agile Principles and Values

Jeff Sutherland recently wrote, apropos the Agile Manifesto, a bunch of things about some key Agile values and principles.  Excellent stuff.

As some of you know, I think it is essential for people doing agile or scrum to know and be in sync with the values and principles. What I call "the music."  Otherwise, the dance steps of agile or scrum, without the music....they just always dance them ugly.  Well, anyone would, without the music.

See here for Jeff's thoughts.

And here is one quote:

• Commitment to work together happens only when people agree on common goals and then struggle to improve both personally and as a team.

 Enjoy.

Hyperproductive Distributed Scrum

Back on July 21, 2008, Jeff Sutherland gave a talk on Hyperproductive Distributed Scrum at the Googleplex in NYC.

Here is the video.

Self-Organization in Scrum

Last Thursday, Sept 4, 2008, Jeff Sutherland gave a talk on Self Organization in Scrum at Google in NYC. The talk also covered some of the associated contradictions (or perhaps, seeming contradictions).

Here are the slides from the talk. Google video to come soon.

Jeff Sutherland in Charlotte July 11-12

Jeff Sutherland will teach a Certified ScrumMaster course in Charlotte on July 11-12.

See Jeff's blog for some information. See here for specific information. And see here to register.

Jeff includes a lot of ideas associated with XP and Lean in his practice of Scrum. (And equally, Kent Beck and the Poppendiecks have been influenced by Jeff Sutherland, in my opinion.)