Hello and welcome to this, the fifth article in the series ‘How Not to be Agile’
‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is. What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits when an organisation, or part of it, embark on an Agile Transformation.
In this article, I will cover some of the misunderstandings and malpractices that I have come across to do with the daily stand-up event; all the Agile frameworks use the term ‘daily stand-up’ for the event except Scrum which calls it a ‘daily Scrum’.
As I said before, it is the content and management of the daily stand-up that is important; call the event what you like.
I will start with a description of the daily stand-up and then give examples of what can go wrong.
The concept of a daily stand-up was first introduced to the Agile community by the Scrum framework and has since been adopted by all other Agile frameworks.
The idea behind a daily stand-up is to give the whole development team an opportunity to see what has been happening in the development timebox since the previous stand-up, what is planned to be done before the next stand-up and to state any problems that they may be having.
The development team uses the daily Scrum stand-up to inspect progress toward meeting the development timebox goal and the likelihood that the development timebox MVP will be met.
This is recommended to be done by each team member answering 3 questions:
Developments over time to the daily Scrum meeting process include:
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.
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.
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.
Figure 1 - Physical Team Board Example
Figure 2 - Electronic Team Board Example
So, here are the questions that a Kanban user answers:
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.
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.
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.
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 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.
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.
In several organisations that I have coached in, when I arrived, the daily stand-ups were taking upwards of 30 mins; this was because:
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!
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”
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.
There have been 3 occasions when time zones played an important part in choosing when the daily stand-up should be held:
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.
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.
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.
Although this Case Study does not demonstrate anti-Agile behaviour, it is worth noting the following lessons:
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’.
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:
Your email address will not be published. Required fields are marked *
Design thinking is no longer a practice monopolize... Read More