Common Practices of Agile Teams
The following is an excerpt from Stephen Denning’s excellent book, Age of Agile. (A book we HIGHLY recommend!)
- Work in small batches. To cope with complexity and unpredictability, work is (to the extent possible) broken down and disaggregated into batches in which something potentially of value to a customer or end-user can be completed in a short cycle. By having teams working in short cycles, it is easy to see, even in large complex projects, whether progress is being made—or not. In some cases, the firm prescribes a common cadence, usually one, two, or three weeks, while in other cases each team is free to select the appropriate periodicity. These firms had all seen big and complex plans fail because there were too many unknowns and change was happening too quickly for adjustments to be made. The response has been to think differently: small batches of work, small teams, short cycles, and quick feedback—in effect, “small everything.”
- Small cross-functional teams. Work is typically done by small, autonomous, cross-functional teams that can complete something potentially of value to a customer. The size of the teams varies. One rule of thumb is “seven plus or minus two.” In some firms, the teams have ten to twelve people. In other cases, the teams are smaller. Sometimes the teams have different names, like “pods” or “squads,” and the word “team” is applied to the larger project that the small groups are working on.
- Limited work in process. In Agile management, teams learn to focus on an amount of work that can be brought to completion in each short cycle. By limiting the amount of work in process at any one time, the risk of work waiting in queues is reduced. Excessive work-in-progress is a pervasive feature in teams getting started in Agile and in back-office functions where work tends to accumulate in queues.
- Autonomous teams. Once it is decided at the beginning of each short cycle what to do, teams themselves decide how to get work done. In each case, the firm decides some basic “rules of the road,” but after that, the team has autonomy on how to proceed. The “rules of the road” vary from firm to firm. Some firms implement arrangements akin to Scrum, in sprints, with a common cadence to enhance the capability of managing dependencies between teams. In other firms, those choices are left to the team. In all firms, we saw provisions as to how the team is led and the accountabilities of the team. But how the work is actually done is, in each case, up to the team.
- Getting to “done.” A common litmus test of successful Agile implementations is whether the teams are routinely producing fully finished work at the end of each cycle. Keeping batch sizes small helps teams get work fully “done,” not just “almost finished.” The idea of getting to “done” sounds absurdly simple, but it turns out to be transformative. One reason big bureaucracies are so slow is that that they have vast amounts of partly finished tasks, often with hidden unresolved problems, all of which creates additional work when tasks are resumed: Context switching is an expensive cognitive function. In software development, a common definition of “done” includes completed code, unit tests completed, integration tests completed, and performance tested and approved by the customer. This is very difficult to accomplish if the team is working on a large task. By keeping the task small, transparency is facilitated. By achieving problem-free work at the end of each short work cycle that can potentially be tested on a customer, snags and snafus are identified early and technical debt doesn’t accumulate.
- Work without interruption. Within each short cycle, teams pursue their work without interruption. Once it is established at the start of the short cycle what is high priority, the presumption is that managers and the team stick with that decision for the duration of the cycle.
- Daily standups. Daily standups were observed as a universal ritual of all the site visits, whatever the particular Agile practices in use. In the daily standup, teams hold brief daily meetings to share progress and identify impediments for removal. The topics vary somewhat but typically concern what work has been done, what will be done next, and what impediments are being experienced. Standups help the members of the team “swarm” to solve a problem rather than have individuals struggle on their own. The communications are intended for the team members themselves, not for managers to inspect and control the progress of the team.
- Radical transparency. The use of “paper-based information radiators” was striking during all the site visits. In effect, anyone can walk into a team space and see at a glance what the status of the work is and where any problems may lie.
- Customer feedback each cycle. Teams receive feedback from the customer at the end of each short cycle. In collaboration with managers, teams evaluate what has been accomplished in the light of feedback from customers and incorporate the feedback into the planning of next steps.
- Retrospective reviews. Retrospective reviews of what has been learned occur at the end of each short cycle and provide a basis for planning the next cycle of work. As in the daily standups, the conversation is intended for the team members themselves, not for managers to inspect and control the progress of the team.