Nothing kills team productivity faster than trying to work on three or more backlog items at the same time. You end up with a team that’s really good at starting work, but really lousy at getting it finished. Agile pretty much started with comparisons to Rugby, so let’s go back to that proven metaphor to see what I mean.

Imagine a rugby game (though, truly, you could consider any team sport like baseball, ice hockey, football, cricket). The two teams on the field work hard to get possession of the ball and, once they have it, they work even harder to get the ball to the goal. Got it? Good! Now, throw five or six balls on the field. What happens? If what you’re seeing in your head looks completely unproductive — well, it should. With multiple balls on the field, conventional strategy breaks down into a free-for-all. The teams degenerate into individual players just trying to get a ball, any ball, into the goal. Both offense and defense become uncoordinated fiascos.

Now, back to your team. With multiple backlog items in progress at the same time, how coordinated is your team’s effort? Are we communicating like we should be? Are we avoiding common mistakes or even the not-so-common ones that someone on the team knows about but forgot to tell the right person at the right time? Are we building the product from the same, always changing definition of the solution? Are we getting all of the acceptance criteria built into the product? Are we testing it from the same understanding of the solution that we built it? Are we documenting everything correctly? Honestly, who knows? With a bunch of backlog items in progress at the same time and everybody working pretty much independently, how does what our dysfunctional team is doing differ from the stuff we put up with in waterfall managed projects?

In the Agile Manifesto, you will see that “we value…individuals and interactions over processes and tools.” That “individuals and interactions” part is REALLY the heart of agile. It’s not the tools or the processes or even the frameworks like Scrum or XP. Agile is about individuals interacting. In a truly agile team, has as been demonstrated for years (even long before the creation of Agile Development) by successful product development teams, a backlog item is attacked (swarmed on) by the team members. We work together to understand the desired functionality (often started in Sprint Planning and finished during the initial hour or two when the work on the backlog item begins). Then, we work together to identify a solution. Then we figure out how to organize ourselves around the work and we get it done. There are no handoffs — usually, no one has to wait for something else to be done before they can start. Once the solution is agreed-upon by the team, documentation can be updated, test scripts can be written, code can be written. Our belief that code must be completed before tests can be written is an artifact of waterfall. Likewise, our belief that coders and testers shouldn’t really work together seems to also have its roots in waterfall (phased) development.

If you really want to be Agile and improve your chances of creating a high performing team, you can’t just say you’re “doing Agile”, you’ve got to BE Agile. Get your team together and reduce your work in process to one or two backlog items. It’s not easy, but it will work for you. Try it!