Balancing the work in the Sprint (coding vs testing)

Dean asks:

Greetings Joe,

 

Your Lean Agile Training website content has provided some great insight in helping me improve my agile principles and practices.  There is one thing I haven’t been able to clear out of my mind.  Perhaps there is a principle I’m not applying or a lightbulb that hasn’t come on.  Maybe I haven’t come across the right advice in a book or blog.  My conflict is keeping my full team ‘busy’ through out a sprint.  We typically apply a 3 week iteration and there seems to be a pendulum from coding to testing.  Those strong on testing don’t have full capacity during coding and coders aren’t at full capacity during testing.  Coders doing work at the end of the sprint won’t have their code tested and therefore don’t meet the DOD.

 

Is this a common mistake or have I missed the boat on something?

 

Joe replies:

 

This is a common concern.

 

Let me assume that you are the ScrumMaster.

First, it should not be your concern particularly that the Team is occupied all Sprint.  The Team should care about that.  Because the Team should have a mission that they feel they must accomplish promptly.  Or they are not really a real Team.  They are a Team INO (in name only).

Next: We do not want to think of the Sprint as being in two parts: (1) coding and (2) testing.  Rather, for a 3 week sprint (I prefer 2 week sprints) with a Team of 7 people, we have at least 13 stories.  And we think of each story in 2 parts (coding and testing, in very simplistic terms).

For each story, the coding and the testing work can begin at the same time.  First, decide how much info will be know beforehand (Ready Ready Criteria).  Then the coder starts to figure out the code (he thinks) while the tester figures out the tests (he thinks).    They work in parallel.  The tester should be building automated tests (of course….won’t explain why here).

The key concept from Lean is ‘single piece continuous flow’.

Then, when the code is ready, the tester tests it (automatically mostly), and of course there will often be bugs.  And then those are resolved quickly.

The simple rule that Jeff Sutherland uses is “No code can be written in the sprint that will not be tested in the spring.”  Among other things, this means that if the testers get behind, the coders must help them (if only by fetching the iced tea).  And vice versa.

Again, they win as a Team and they fail as a Team.  This is a key idea that they really must believe if they will do Scrum professionally.  (It is a sport for real Teams.)

Now, if they will help each other, they may have to learn new things to be able to help each other effectively.  This is a good thing.  And what knowledge workers naturally want to do.

Talk through these ideas with the Team.  They will help figure out the details, such as exactly how to help each other, what to learn, etc, etc.

One push back:  Well, actually some ‘teams’ have many push-backs. First is often some variation on ‘we don’t want to work as a team’.  Understandable in the sense that they have not ever been asked (for 5-10 years) to really work as a Team.  And some (few) people do not (ever!?!) want to work in a Team.

But a key push-back is: This seems like a lot of extra work for us. It would be more efficient if we did the work in big batches (usually, as they are doing today).

The penny game is one big way to convince them about this.  (I have written about this on the blog.)  In a certain sense, what they feel is somewhat correct.  What they are not seeing is all the savings that accrue when doing the work this way.  Mainly since the ‘bad news is not getting worse with age’.

Enough for today?  Comments? Questions?