Balancing the work in the Sprint (coding vs testing)

June 6, 2015

Dean asks:

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 light bulb hasn’t come on. I haven’t come across the right advice in a book or blog.

My conflict is keeping my full team ‘busy’ throughout 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 you are the ScrumMaster.

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

Next: Do not 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, have at least 13 stories.  And 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.  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. (Will not explain why here).

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

Then, when the code is ready, the tester tests it (automatically), and of course there will often be bugs.  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 sprint.”  Among other things, this means 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 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 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 figure out the details, exactly how to help each other, what to learn, etc, etc.

One push back:  Actually some ‘teams’ have many push-backs. First is 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 people do not (ever!?!) want to work in a Team.

A key push-back: 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.  They are not seeing the savings that accrue when doing work this way.  Mainly since the ‘bad news is not getting worse with age’.

Enough for today.
Comments? Questions?

« « Impediments: Orlando May 2015 || Short Scrum and Long Scrum » »

Posted in: Better Agile, lean
Tagged:

3 thoughts on “Balancing the work in the Sprint (coding vs testing)”

  1. Cash Coyne

    This is truly a vexing thing and unfortunately, this post doesn’t seem to provide much in the way of a solution to this common problem.

    We’re always encountering the situation where the developers finish their some of their user stories on the last day of the sprint (2 week sprints) and then there is no time for testing. But if we have fewer user stories/story points, then the developers are left with nothing to do for the last 2-3 days of the sprint.

    And then you have to deal with situations where something that takes a lot of effort to develop might take very little effort to test and then you have vice-versa.

    Our solution usually comes in one of two flavors:
    1. Preferred:
    Developers finish their work in time for testers to test the work. Then they work with the PO to determine what to work on next from the backlog, but this work is not pulled into the current sprint unless it is finished in time for a tester to test it.
    The downside is that this doesn’t give us a realistic velocity because if it’s not pulled into the sprint, then it goes in the next sprint. Then you have work getting done in the first sprint that wasn’t captured in terms of velocity and the work and all the story points being captured in the second sprint. Thus making the first sprint look like it has a poor velocity and the second sprint have an unrealistically good velocity.
    2. Not as preferred:
    Carry over unfinished user stories to the next sprint. Now we’re totally missing our velocity for the first sprint and that’s demoralizing to the team and this still doesn’t reflect the accurate velocity for either sprint.

    Let me also say this:
    We break our user stories down to the smallest testable increment. This helps with this situation.
    We’re not fans of cross functionality. Our testers are not developers and for them to attempt development tasks is extremely inefficient. Our developers don’t want to test and for us to push that model is a poor use of resources and for us to do that frequently would eventually have our developers looking for development opportunities elsewhere. In addition, they don’t feel comfortable testing, knowing they aren’t testers and want QA to go over it to be sure, so that is inefficient.

    For now, we use solution #1 I outlined above. Not ideal, but by having small user stories, it’s a minimal impact on the velocity.

    However, we’re definitely open to other, CONCRETE ideas of how to deal with this situation

    ↓
    1. Joe Little Post author

      Hi Cash,

      Thanks for your very thoughtful comment!

      Well, let’s be clear about a few things.
      First, the ideas we suggested did not originate with us (me), but rather with people like Jeff Sutherland and most of the Scrum community.
      Second, they are ‘concrete’, but you feel there are counter-arguments, hence you feel they are (not sure which word you would use…I’ll put this word in your mouth) ‘un-workable’, so you don’t want to agree with them. OK (you have not convinced me, but you are not the only one who sees things your way). And, of course, you do not have to do what I suggested.

      Next: Scrum was built for cross-functional teams (in part because they recognized this problem, in part for other reasons). So, if you don’t want to be cross-functional, do something else, and call it whatever you want, but it won’t be Scrum. Which is really minor and unimportant. The key issue is what is best in your situation.

      Next: I think we need to start by saying Business Value is most important. And we are trying to maximize BV from the Team to the Customer. And we are NOT trying to maximize the efficiency of the Team, and especially not trying to maximize the efficiency of members of the Team.

      Next: Scrum has only the Team role in part because it demands that team members help each other out whenever needed (eg, in your situations). And, yes it may take some time and (re)training before they are good at doing that, but we find that former ‘coders’ can help former ‘testers’. And vice versa. And, while it may appear inefficient (and people may complain for awhile) …in the end it gets the best stuff delivered faster to the customer with high(er) quality and cheaper.

      One of the reasons is that the bad news does not get better with age. That is, if you look at the research, a bug must be identified and tested immediately, or it gets a LOT more expensive to fix very very quickly.
      One of the outcomes of this way of thinking is that we must automate more of the testing…almost all of it. (I am not aware of any software where this could not be done, although perhaps I am wrong. I imagine that for non-SW products, automation of testing could be pretty tough some times. I assume you all do relatively normal SW products, but of course I could be wrong about that.)

      A very concrete answer to your question is delivered in Jeff Sutherland’s rule: “Write no code in a Sprint that cannot be tested.” I think you can find that rule (slightly re-worded…I did not check his wording) on his blog.

      Small user stories: As you suggest, this is key. How small are your user stories? As a rule of thumb, I say “At least 8 small stories per 2 week sprint for a team of 7” (7 includes PO and SM also…5 doers). Are yours that small? It would be typical if they are not, and typical also that the team thought that it would be ‘impossible’ to make them smaller than they are now. And typical again, that in fact the stories could easily become smaller once the Team learned (better) how to break them down. If one doesn’t know, ‘it’ always feels impossible. Once you know (and practice), everything is always easy (at least in some sense).

      Did I convince you? I doubt it. The problem is that we are starting from different starting points or assumptions. But maybe I said a few things…. if they do not influence you, maybe they influence someone else.

      Thanks! Joe

  2. Rob Hoover

    One other wrinkle- In my opinion the team should be cross functional, but that doesn’t necessarily mean each individual has to be cross functional. There should be enough analysts, programmers, and testers to get the work done on a normal day. But T-shaped skill sets will help out to balance the work and help with throughput, especially at the beginning and end of Sprints. And also doesn’t mean the programmers necessarily have to do QA testing (although I hope they are doing automated unit testing), but rather, what can the developer do to alleviate the testing crunch? Better automation of end to end processing? Code a tool that helps testers with their manual / tedious tasks? What else can programmers do to help testers ? If your team doesn’t have a whole-team quality ownership philosophy, you’ll have a tough time doing Scrum and getting better at it.

    ↓

Leave a Reply