An Agile Health Check: The Daily Standup in Practice

When you meet an agile team for the first time, it can be a good idea to do a quick assessment of their health. Sometimes you can tell quite quickly if there are underlying problems just by the way things look. And I'm not talking about the prison pallor that afflicts certain developers. I already know they don't get enough fresh vegetables or daylight, even if they aren't participating in Coding in the Clink. No, what I'm talking about is the agile process that the team has laid claim to, and the way that they have supposedly adopted it. What can a quick look at its shape and form reveal about the team and how it is doing?

There are two quick checks that can be done to get a rough indication of health. The first is to look at the team's Scrum board or Kanban board. I've talked a bit about this in my earlier post on Scrumban, where we examined the compromises teams often end up making in operational practice.

The second check is one I haven't covered yet. It is to examine the daily stand-up, or the daily scrum as this event is sometimes referred to.

The rules of a stand-up are simple. Every day the team should assemble for a maximum of 15 minutes so that they can assess progress towards the Sprint Goal - or the intended velocity in Lean Kanban - and self-organize in order to overcome any impediments. It's an inspect and adapt opportunity which allows problems to be addressed, and indicates to the team if any replanning is necessary. Hmmm...we've got a wealth of things to examine just from those last three sentences. So let's begin the health check. The stand-up has started!

• First, let's look at the people who are attending. If the whole development team has turned out, is it of an appropriate size, or is it too large or too small? A Scrum Development Team should number between three and seven people. Less than three and it may not be evident that there is a team at all. More than seven and it becomes too difficult for the members to maintain the lines of communication and collaboration that are needed to de-risk Sprint scope. Lean Kanban teams might be larger - their size depends on WIP (Work In Progress) limits and the number of people needed to expedite each ticket with minimal waste. So, does the team look as if it is of a healthy size?

• If the whole development team isn't present at the stand-up, why not? Let's make a note about this:

  • Are team members equally valued, or are some of them less equal than others?

  • Are some doing double duty working on other projects, and can't attend because of those other commitments? If so, what does that say about the pressures this team is under, or the priority that has been given to their work?

  • Are there issues about team commitment to the agile process?

    • Is it a case of certain developers not valuing the stand-up, and therefore not bothering to attend?

    • Are some team members rolling in late? What action does the team take about this?

• Neither the Scrum Master nor the Product Owner are required to attend the stand-up. However, it is a positive indicator if at least the Scrum Master is there, because it is a forum in which impediments might be raised that he or she can act on. And if the Product Owner isn't there keeping an eye on progress...why not? It might be the case that the PO trusts the team to deliver...or it might be the case that they don't actually have a PO or Scrum Master at all! That's another thing we need to find out.

• Now let's listen to what is being said. The information conveyed should be short and pithy. Daily stand-ups are not an opportunity for people to waffle, hold court, extemporise upon pet issues, or otherwise climb on a hobby horse. One approach, which is popular among Lean Kanban teams, is to consider each ticket on the Kanban board in turn. The team then decide as a group what action is required for each one. Scrum puts the focus more on people and their commitments. There are three things that each Scrum team member is expected to relate in turn:

  • What they have done since the last standup

  • What they are working on now

  • Any impediments that are getting in their way

• A healthy team is a focused team, so it's important to keep to the above points and to avoid digressions and side conversations. But is the team maintaining this discipline? Does every developer make a contribution? The Scrum Master should coach the team to conduct itself in a disciplined and collaborative manner. If they can't even do that in a fifteen minute timebox, what's going on?

• Is the timebox being exceeded? Stand-ups are constrained to 15 minutes for a reason - it keeps things focused. If the team aren't keeping to this, why not? Is it because there are too many people, or is it because some team members aren't keeping to the points described above?

• Is the team actually standing up? It's called a stand-up for a reason too. It should be over and done with quickly, and with no need for any able-bodied person to sit down. Yet it might also be the case that the team is trying to do too much planning in the stand-up itself. It's better to replan once the stand-up is over so others can get on with their work...or even better, to have collaborated and resolved these impediments before the stand-up even started.

• Is there a board? Although it isn't strictly essential, it's good practice for team members to refer to a Scrum or Kanban board during stand-up, and to point to the user stories or tickets that they are working on. This makes it obvious what work is being referred to and where it fits in with the team's plan. So if there is no board, what evidence is there that the rest of the team understand the context and value of what each other are saying, and claim to have been doing?

Now let's move the health check up a notch. A stand-up is an opportunity for the development team to self-organize and prepare the work for the day. Other people, such as the Scrum Master and Product Owner, may attend. Others may be excluded altogether. Which leads us to the "Pigs and Chickens" story.

A chicken and a pig are walking down the street. “Hey, I think we should open a restaurant”, says the chicken.

“Great idea”, says the pig. What should we call it?”.

“Ham and eggs”, replies the chicken.

“On second thoughts I’m not so keen”, the pig says. “I’d be committed, but you’d only be involved!”

On agile projects, the amount of say someone has depends on whether they are a "pig" or a "chicken". For example, as far as a Scrum stand-up goes, the Product Owner is a chicken. It's up to the team how they collaborate to meet the Sprint Goal. The Product Owner has no real say in that...all he or she should care about is whether the agreed goal is met once the Sprint ends. The team should however consult with the Product Owner during the Sprint so that scope and business value can be clarified. In Lean Kanban, there is no Sprint or Sprint goal, just a single backlog of prioritized work that a team actions. The Customer or Product Owner is very much a "pig" in defining Lean Kanban priorities and any associated quality of service. In fact the Product Owner is always a "pig" in the wider project sense, and has a great deal of say in what gets delivered and the quality that is provided.

This gives us some more things to check in the standup:

• If the Product Owner is in attendance, are they focused on outputs, or are they using the stand-up as a forum for micromanaging the team? If so, that's a problem, because an agile team needs to be self-organizing.

• What other people are in the stand-up? Are they pigs or chickens? If there are any non-team members, what effect does their presence have on the stand-up? Some teams impose a blanket ban on non-members from attending...they make it a "pigs only" event. Might such a policy be of benefit here?

So, these are some of the things to look for in a basic agile health check. It's amazing how much you can tell in 15 minutes!