How Not to be Agile – Daily Stand-Up/Scrum

1. What have I been doing since the last stand-up?
2. What do I plan to do before the next stand-up?
3. What blocks/impediments/issues/problems am I having?

Developments over time to the daily Scrum meeting process include:

• Carrying out the stand-up in front of the Team Board and updating it as necessary
• Using video-conferencing and a shared, electronic Team Board for distributed teams
• Adding questions such as:
  • Has anyone given me a requirement change request?
  • Have I learned anything about this product development that I think everyone should know about?
  • Do I have any worries about how the team is progressing?

The Scrum Guide states that the daily stand-up should take no more than 15 minutes; the Agile Project Framework suggests that normally the daily Scrum stand-up should not last more than 15 minutes but also suggests that 2 minutes per participant + 2 minutes is a good guide; for a team of 9 members this would equate to 20 minutes.

If there are any ‘matters arising’ from the daily stand-up, most teams will delay discussion until after the stand-up is finished and then only those that are needed for the discussion stay behind; the rest go back to work.

What the Daily Scrum Meeting is Not?

During early Agile transitions it is ‘tempting’ for the management to ‘watch’ the development team closely and the daily stand-up turns into a ‘reporting progress to management’ session.

This is NOT what the daily stand-up is for and all attempts to turn it into one must be resisted.

An Alternative to Daily Stand-Up process

The Kanban framework and other lean process practitioners realised that the ‘standard’ 3 questions above are not really relevant because people just need to take a look at the Scrum Board (kanban) to see what they did recently and what they will do the next; remember the use of a Team Board is not ‘mandatory’ in most of the Agile frameworks but it would be unusual for a team not to use one, whether a physical board or an electronic one.

So, here are the questions that a Kanban user answers:

• What is impeding us?

Assuming, that the meetings take place in front of the board, there isn't even a need to discuss what items are impeded (since this will be visible on the board).  Therefore, all there is to focus on, is the possible and the best solutions to the problematic items.

• What's the flow like?

Because Kanban is all about the workflow, what should be discussed at this point are any possible changes that the team can make in order to make the flow even smoother and efficient.  Also, should there be any bottlenecks, the daily stand-up is the right time to work on their best resolution.

• What can we improve? (how to achieve Kaizen?)

This is a question is the means by which the entire team is empowered to strive for constant improvement; by allowing for the change suggestions to come from anyone in the team, there is a big chance of success.

Effectively, the Kanban Framework incorporates every day what other frameworks do in the Retrospective.

Whatever Agile framework that you use, if you adopt a Kanban style Team Board, you may want to use the Kanban questions during your daily stand-ups.

Who Should Attend the Daily Stand-Up?

It is important that all of the development team, both full and part-time, and the Agile Project Manager/Scrum Master attend the daily stand-up:

• The whole development team needs to be there because all team members need to be aware of what is happening in the development timebox, state any problems that they may be having and potentially offer help to other team members who may have problems.
• The Agile Project Manager/Scrum Master needs to be there as the Risk and Issue Manager to listen to the problems that any team members may have.

The daily stand-up should be run by the development team although, in some organisations, the Agile Project Manager/Scrum Master runs the event.

Other people outside of the Development Team are ‘welcome’ to attend daily Scrum meeting but are not allowed to speak; they are only there to observe the process.

Unleash your potential with PRINCE2 certifications - the ultimate solution for project management success!

When Should the Daily Stand-Up Take Place?

One of the tenets of all Agile frameworks is to have a cadence or ‘heartbeat’; events should be scheduled on the same day, time, and place for the whole product development time.

It is strongly recommended that the daily stand-up should be scheduled to take place in the same place at the same time every working day.

Case Study 1:

In several organisations that I have coached in, when I arrived, the daily stand-ups were taking upwards of 30 mins; this was because:

• There was a detailed discussion between 1 or 2 team members about some topic or other
• One or two members were overly verbose in their explanation of what they had done and what they were going to do

In all cases, the majority of other team members were not interested in the details of the conversations or another’s work; some used the ‘wasting my time’ reason to avoid attending the daily-stand-ups.

In one organisation, I was teaching an Agile class and on day 2, 3 delegates turned up 1 hour late for a 9am start.  I asked, politely, if they had a problem attending on time and was told that they had to attend their team’s daily stand-up; a laudable reason.  When I asked what time their team’s daily stand-up started I was told 9am; the event had taken 50 minutes!

What was worse was that one of the delegates was supposed to be the Scrum Master for the development!

Lessons:

1. Don’t start Agile product Development without the Agile PM/Scrum Master having had at least 2 days of training on the Agile framework that they should be using
2. Whoever is running the daily stand-up, do not allow:

• Detailed explanations of work done or planned to be done
• Detailed discussions of points between 1 or 2 team members

1. Matters will arise during the daily stand-up but discussion of these must be held over until the daily stand-up has finished

If a team member says they have an impediment and it can be solved in about 15 seconds, then that is OK; for example, a team member may say:

“ I cannot get hold of person XYZ to get the information I need”

Another team member may have had the same problem in the past and may say something like:

“He/she never answers the phone during the morning; call him/her after 2 pm”

Case Study 2:

For one engagement that I was working on, the Development Team was dispersed in 5 locations in 3 different time zones.  I noticed that one team member in another location never attended the daily stand-up; the Scrum Master obtained the answer to the 3 questions later in the day over the phone.

I asked the Scrum Master why this was so and he told me that the person was in a time zone 1 hour behind the main team and had travelling difficulties getting into work for the daily stand-up time.

I asked when the team member could ‘guarantee’ getting into work and would there be any problem moving the daily stand-up time.  It transpired that the time of the daily stand-up could be moved to suit the team member without inconveniencing any of the other team members.

Lessons

1. The time for the daily stand-up should be set when all development team members have a good chance of attending; this is important for geographically dispersed teams.
2. The Scrum Master gathering daily stand-up information after the event wastes his/her time and the rest of the team miss the opportunity to have all the information that they need

Case Study 3: 

There have been 3 occasions when time zones  played an important part in choosing when the daily stand-up should be held:

1. The main team was in Tokyo, there was a sub-team in Beijing, the ‘customer’ was in San Diego and management was in Helsinki; this was the first Agile product development for this team although other teams in the organization had transitioned.

Although it is not normal for the customer or management to attend the daily stand-up, in this case, both the customer and management wanted to attend to make sure that the team were ‘on the right track’; the fact that I had trained the main team hadn’t given the management sufficient confidence!

But the time zone differences made it difficult to choose an appropriate team for all attendees.

Because there were only 1 customer and 1 manager who wanted to join the stand-up, it was decided to hold the stand-up at 1pm Tokyo time to inconvenience the main and sub-teams the least; for the customer in San Diego it was 11pm and for the manager in Helsinki it was 5am.

We ran like this for 1 week after which both the customer and manager decided that they were happy with the way the main team and sub-team were operating.

1. The Development Team were in Cebu, Philippines, and the Product Owner was in Duluth, USA; the Product Owner wanted a daily update on how the requirements were being implemented.

There was no overlap in the work times of the different time zones so it was decided that the Scrum Master would start work at 1pm Cebu time, the daily stand-up would be run at 2pm Cebu time and the Scrum Master would update the Product Owner at 9pm Cebu time, 8am Duluth time.

2. The majority of the team were in Dundee, Scotland with a few team members in Hyderabad, India.

In this case, there was a 3.5 hour overlap in the work times of the different time zones so it was decided to run the daily stand-up at 10am Dundee time and 3:30pm Hyderabad time.

Lessons:

Although this Case Study does not demonstrate anti-Agile behaviour, it is worth noting the following lessons:

1. When deciding a time to run the daily stand-up, the time should be set to inconvenience the development team members as little as possible; other people must choose whether their attendance during ‘unsocial hours’ is worth it to themselves.
2. The Agile PM/Scrum Master does not have to work the same hours as the rest of the development team in the same time zone; it does depend on whether the Agile PM/Scrum Master is prepared to work ‘unsocial hours’.
3. Where work times overlap across time zones, ensure that the time to run the daily stand-up is within the work times of all time zones. 

Case Study 4:

I was coaching a team that was in the early stages of an Agile transformation and the team members had picked up the basics well; the daily stand-ups were running well with some good banter and team member help being offered freely.

During one stand-up, I noticed a marked lack of relaxation amongst the team members when speaking and their heads were down most of the time.

I asked the Scrum Master if he knew the reason for the change of atmosphere and she said that she had expected something like it but not quite so marked.

There had been a manager attending for the first time; this manager had a reputation for being a bit ‘old school’; “do as I say and no arguments”.

After confirming with the team members that they had felt intimidated, I researched the manager and discovered that he headed a department that was just starting to try Agile; the manager had attended the stand-up just to see how it worked and had had no intention of ‘interfering’ or making any opinions about the team members.

I asked if he would like me to coach ‘his’ team through their early Agile events; he accepted and I invited him to attend all the events as an observer.

After each event, I mentored the manager about his opinion of what went on.  He had a few questions about ‘why this’ and ‘why that’ and I was able to answer his questions to his satisfaction.

I asked ‘his’ team members what they thought of having the manager at their events and they said that they had had some trepidation at first but after they could see that he had been there to learn and had not lived up to his previous reputation, they became quite comfortable with the manager’s presence.

I told the members of the original team of this apparent change to the manager’s ‘personality and asked if he could attend the next daily stand-up; they agreed and the next stand-up with the manager present went as ‘normal’.

Lessons:

1. If there is a change of demeanour of any individual or several team members, investigate the reason; it is most probably an impediment to smooth team running.
2. The Scrum Master could have just asked the manager not to attend anymore but given the manager’s perceived reputation, that would have taxed the Scrum Master’s diplomacy skills.
3. By engaging with the manager, it was possible to shift his ‘old school’ manner to one that understood Agile and could cooperatively support it.

Conclusion

The ‘mechanics’ of the daily stand-up are relatively straightforward if the rules of the Daily Scrum are followed strictly in a daily routine. Collated below are the best practices while implementing daily Scrum:

• All development team members must attend, both full and part-time members.
• The time and place for the daily stand-up should be chosen to give the least inconvenience to the development team members.
• Geographically dispersed teams can run daily stand-ups using video-conferencing and shared desktop facilities.
• The questions to be answered by development team members should be adjusted to suit the type of Team Board being used.
• Non-development team members are welcome to attend daily stand-ups but are not allowed to speak.
• If the attendance at a daily stand-up of a non-development team member is considered to ‘intimidate’ one or more team members, this is an impediment and the resolution must be sought.