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

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

19th Feb, 2024
view count loader
Read it in
18 Mins
In this article
    How Not to be Agile – Daily Stand-Up/Scrum


    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.

    Importance of Daily Stand-Up Meetings in Scrum

    Daily Stand-Up Meetings in Scrum

    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:

    Daily Stand-Up Meetings in 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.

     Physical Team Board Example
                                                                         Figure 1 - Physical Team Board Example 

    Electronic Team Board Example
                                                                                                Figure 2 - Electronic Team Board Example 

    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!


    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.


    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.

    1. 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.


    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’.


    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.


    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.

    Steve Ash

    Blog Author

    Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’.  He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner.  He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.

    Share This Article
    Ready to Master the Skills that Drive Your Career?

    Avail your free 1:1 mentorship session.

    Your Message (Optional)

    Upcoming Agile Management Batches & Dates

    NameDateFeeKnow more
    Course advisor icon
    Whatsapp/Chat icon