“There is also camaraderie in the huddle. They regroup, they focus, they keep the momentum going” -- Everts, Gordon, & Schaupp. “Breaking the Huddle”.
Scrum provides numerous opportunities for teams to inspect and adapt their progress, including on a daily basis. A time-box of 15 minutes is taken -- out of what should be a busy day of collaboration and getting work done -- for the team to get together and refocus their full attention on the Sprint Goal. The “Daily Scrum”, as it is called, is an opportunity for each member to reflect upon:
-
What did I do yesterday to help achieve this goal -- agreed with the team -- and which I have personally committed to?
-
What will I do today to take us all closer to the goal, and which I intend to accomplish by the next Daily Scrum?
-
Are there any impediments which are likely to get in the way of our success?
The Sprint Goal often makes the selection of work in the Sprint Backlog coherent. It gives the team a joint focus and a reason to work together. Without collaboration there can be little teamwork, and it can become hard to prove that there really is a team in the first place. So if you were to use this daily “get-together” as a quick-and-dirty “health-check” to gauge the well-being of a Scrum Development Team, you might find certain problems to be in evidence. Remember that the essential criterion of a Daily Scrum is that attendees leave with a plan of what they will do over the next 24 hours, as a team, to take them closer to the Sprint Goal.
It may become evident, for example, that a Daily Scrum will be the only occasion that day when team members have anything to do with each other at all. You might see them using a gonzo approximation of the above “three questions” format to essentially report on the status of whatever work they have been sawing away at independently, and perhaps to hold court on minutiae which none of the others care about. Collaboration during the day, to accomplish the various tasks at hand, would seem to be absent. In fact the Sprint Goal might not receive even a passing reference in anyone’s monolog, and hence no plan for its achievement will be cultivated before the 15 minute time-box ends. Indeed, it could become apparent that team members do not commit to realizing team goals in any form, or understand anything about doing so. The values described in the Scrum Guide, meanwhile, clarify that everyone should commit personally to the goals of the team.
Very often commitment and goals, in so far as they are acknowledged by a team in the first place, are assumed by each member to be somebody else’s responsibility. If they are discussed in Sprint Planning at all, they might be swiftly forgotten about when the session ends. Commitment to a Sprint Goal then becomes notional and irrelevant. Any such ambition is very unlikely to be thought through, given that it has little meaning in practice. Whatever gets delivered gets delivered. The Sprint Goal is left on the doorstep of Sprint Planning like a drunken note to the milkman. With each Daily Scrum it is carried further away with the wind.
Kanban aficionados have developed a bit of a reputation for being rather smug about this problem. Since they work largely on the basis of continuous flow, they do not generally observe Sprints, and so have no Sprint Goals to contrive in Sprint Planning and to subsequently forget about. This means they can arrive at a very different understanding of commitment. They may, for example, choose to observe a commitment point...a juncture at which they admit items into their workflow and undertake to complete them so service level agreements can be met. The extent to which Kanban team members have to collaborate is more likely to be determined by any associated workflow policies, and the smooth management of flow, than by the need to meet a Sprint Goal within a given timebox.
This shapes the way in which Kanban teams typically conduct their “daily huddles”, a practice that has its origins in quality management. The equivalence between a “Daily Scrum” and a “daily huddle” is perhaps not quite as direct as it might appear to be. Unlike Scrum, the onus in Kanban is not on team members to account for what it is they have done, or hope to do, so that some sort of goal might be achieved. Instead, the team is likely to “walk the board” item by item. Reading the Kanban board from right to left, team members might collectively ask themselves:
-
What is currently blocked?
-
How can we remove impediments so the work does not continue to age and incur further flow debt?
-
What else is in progress, and how can we bring each item to completion?
-
Who among us can help to finish this work according to the workflow policies we have established?
-
What new items can we potentially start, having taken all steps to assure that work in progress will be finished?
As well as disparities in team behavior and the expected outcomes, there can be differences between a Daily Scrum and a “huddle” that are more immediately obvious. A Scrum Development Team, for example, is limited to between 3 and 9 members, all of whom ought to be peers and who are likely to value the generalizing-specialist. Any more than 9 people would increase networking overhead and might hobble the ability of those peers to collaborate with each other. A Kanban team, on the other hand, does not necessarily consist of peers at all. Rather, the skills and capabilities which each member brings should support the team’s workflow policies, whatever they may be. Each team member might only be expected to collaborate with those who are immediately adjacent to their position in the workstream, for example. That could be enough to smooth and actively manage the flow of production. With a correspondingly reduced networking overhead, Kanban teams are free to grow somewhat larger without necessarily incurring penalty. A daily huddle might sometimes have dozens of people in attendance, each one of whom is a disciplined team member with a particular area of focus. Of course, the famous “two-pizza rule” can be applied to any meeting, including a huddle. If the rule is being observed, then it should be borne in mind that those attending a huddle might not constitute the whole Kanban team. They might be representing others as well as themselves.
What does all this mean for a Scrum Development Team, should it try to implement Kanban as a strategy? What would their Daily Scrum look like?
Well, the first thing to acknowledge is that it must still be a Daily Scrum. Each of the Scrum roles, events, artifacts, and rules would still be in force, and so the team will continue to have between 3 and 9 members. Those team members might very well have specialist skills, but they’ll collaborate as a matter of policy, because they must demonstrate a shared focus on a clear and agreed Sprint Goal. In each Daily Scrum, they’ll still be replanning how they intend to get closer -- over the next 24 hours -- to achieving it.
The significant difference is that the nature of a Scrum Sprint Goal may change when a Kanban strategy is implemented. It might no longer be a feature that gives coherence to the selection of work in the Sprint Backlog. The team might instead commit to accomplishing improved flow. For example a team might commit towards reducing cycle times, or increasing the rate of throughput, or improving the service levels which stakeholders expect. Any of these can be valid Sprint Goals if they represent a coherent functional outcome and give the team cause to work together.
A Development Team implementing Kanban may, therefore, quite reasonably “walk the board” in a Kanban fashion. They could ask themselves: “Is anything currently blocked? How can we remove any impediments to our flow-based Sprint Goal? How can we bring our current work in progress to completion? Does anyone on the team require help, and if so who can provide it? Once these items are finished, what new work might we potentially start?”
A Kanban strategy requires a team to actively manage its workflow. The evaluation of metrics takes on a new significance. Work item aging, for example, should be of particular interest to a Development Team during a Daily Scrum, because it is a leading indicator and something over which members can exert immediate control. It is very often the case that the longer an item languishes in progress, the less likely it is to be completed in a Sprint at all. I once took the following measurements for use in a Sprint Retrospective which illustrate the phenomenon:
Item age at Sprint end (days): >2. Probability of not being completed: 23%
Item age at Sprint end (days): >7. Probability of not being completed: 67%
Critical point: An item which ages 7 days or more is unlikely to be completed at all.
Information of this nature is of critical importance in the active management of workflow, since a team can choose to focus on those valuable items which are evidently most at risk. Additionally, they may refer to a time and space diagram, or cumulative flow chart, in order to inspect flow. They can then adapt so it is managed more smoothly. Any disparity in the quantity of work entering and leaving their workflow will be of interest, since a build-up of work in progress will compromise predictability.
Remember that the Scrum Guide does not prescribe which techniques a team ought to use when holding their Daily Scrum. The classic “three questions” format is just a suggestion. If a team were to implement the Scrum Framework conscientiously, and put their focus squarely on improved flow, then their Daily Scrum might indeed take the form of the “huddle” associated with Kanban practice.