I recently checked back in on a team I had started up a while back. Over the months since I had set them free they had made a few modifications to the process and in doing so had fallen into one of the most common traps I have seen teams fall into - they had made it all about the developers.

My first inkling that there was something amiss came when one of the testers on that team approached me for some advice on how she could be more efficient in her testing. She felt she was falling behind. When I dug a little further it turns out the team had delegated the job of unit testing to the testers to "free up the devs". This was in addition to the acceptance test automation the testers were doing as well. The devs had also resisted any attempts to assist with testing so "they could be more efficient".

Unfortunately, for cultural reasons, the testers felt unable to speak out at the retrospectives/planning meetings (another blog post on that coming up soon) so the situation had grown steadily worse. The devs were having a great time, churning out code at a fantastic rate. The testers though, were putting in long hours trying to keep up and falling back on the mortal sin of manual testing to get things across the line. The number of manual tests was building up, the number of automated tests was stagnating. In short, the team was no longer fulfilling its definition of done which stated that a story must have automated tests.

The team had lost sight of the real focus of scrum. Scrum is about the team. Not about the developers on a team. By optimizing the process for the developers and essentially having all other functions work to support maximum developer output, they had sub-optimized. They had lowered the overall efficiency of their process by optimizing one small part of it.

Scrum is about the team. The goal of scrum is to maximise the rate at which a team can turn stories from Ready to Done. It's not about how fast developers can crank out code. Working code may be the only acceptable indicator of progress in an agile project but the key word there is working. Sheer volume of code written is not progress. It's code that is written, tested, documented and otherwise completed that is the measure.

So, what did my team do? They went back to basics. They scheduled a "hardening" sprint to catch up on all the test automation they had missed and they changed their process. Developers now write unit tests. The testers write the acceptance criteria and work together with the developers to automate them as the code is written. The testers write some tests, the developers write others under the direction of the testers.

The team's apparent velocity has dropped but the previous velocity was a false value based on stories that weren't really finished. When you take those stories out, the team's true velocity has gone up.

They have maximised team efficiency. And that's what scrum is about.