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!
More About #Productivity
What is a Sprint Demo? #AskArtisan
What's a Sprint Demo? It's typically a sure sign that your organization has no idea how to do a Sprint Review! I'll explain in this edition of #AskArtisan.
Do Scrum Team Members have to be Full Time? #AskArtisan
Scrum Team members CAN be part-time, but this week’s #AskArtisan video shares insight on helping them maximize their time, and pitfalls to look out for.
How Many People Should be on One Scrum Team? #AskArtisan
I'm often asked about the ideal number of people on one Scrum Team, but maybe a better question is why and how any number becomes too many?
How do you Plan for Support Time in a Sprint? #AskArtisan
Many Scrum Teams ask how to plan for support work in a Sprint. Can you plan the unplanned? There's no simple answer, but there IS an answer!
Can One Sprint Have Multiple Goals? #AskArtisan
Can you have more than one Sprint Goal in a single Sprint? I actually recommend it! In this video, I'll explain how it can improve Scrum team productivity.
How Are Product Goals and Sprint Goals Related? #AskArtisan
I'm often asked about Scrum goals; specifically Sprint Goals, Product Goals, and how they relate to each other. In this video, I'll tie them together for you.
What’s a Sprint Goal? #AskArtisan
Ever been out shopping only to get home and realized you didn't actually get what you needed? This is what happens to Scrum teams without a Sprint Goal!
What’s a Product Goal? #AskArtisan
The 2020 Scrum Guide introduced a new concept called the Product Goal, and many are still confused about the purpose and function of Product Goals.
Can QAers be on a Scrum Team? #AskArtisan
When you set up a Scrum team, what do you do with your QAers? In this video, I'll explain why they should definitely be part of the team.
Leave A Comment