What’s an Agile standup?

Written by Andrew Gibson

In this article, I provide a brief overview of the history and theory behind Agile “standup” meetings over the last twenty to thirty years. There are some remarkable similarities across all frameworks, despite the meeting having different names. The differences which stand out to me are the intent (or goal) of the meeting. As with many Agile practices, some of the initial rationale for stand-ups was reactionary/corrective/transformative rather than fulfilling an objective function on its own, which raises the question of whether it is still the best practice to use. At the end of the article I provide a brief comparison, an example of academic analysis regarding how well it works, and some anecdotal notes from my own experience.

Thanks to Ioannis Polyzos, Janine Magnin and Sarah-Jane Gibson for review and feedback.

Agile

Agile is not a methodology, and consequently doesn’t contain a definition of the term “stand-up”. Of the 12 Principles behind the Agile Manifesto (1), none speak directly to concrete details of any meetings. However, if we were starting from scratch and looking for inspiration for meetings, we might pick out a subset for further reflection:

Principles 4, 5 and 6 state:

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Principles 8 and 9 say:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

and principles 11 and 12 say:

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Alliance

The Agile Alliance, a non-profit organisation formed by the original authors of the Agile Manifesto, is an organisation which seeks to support practitioners and explorers of Agile “values, principles and practices.”(2) At the time of writing, none of the original manifesto founders appear to be on the board or staff, but it was started by them and so holds considerable sway.

In Agile 101(4) the Agile Alliance list some key concepts, one of which they call the “Daily Meeting”:

Each day at the same time, the team meets so as to bring everyone up to date on the information that is vital for coordination: each team members briefly describes any “completed” contributions and any obstacles that stand in their way.(3)

They also reference a variant of Scrum’s three questions:

The daily meeting is structured around some variant of the following three questions: What have you completed since the last meeting? What do you plan to complete by the next meeting? What is getting in your way? (5)

However, the Agile Alliance also give a potted history of the “Origins” of the Daily Meeting(3) which identifies early origins back in 1993 (7+ years before the coining of the Manifesto) in the “StandUpMeeting” pattern recorded by Jim Coplien.

Sadly the link to this codified pattern is broken and the site appears to be defunct (http://orgpatterns.wikispaces.com/StandUpMeeting). However, there is what appears to be a replacement site at http://orgpatterns.com/home which contains a page for “Stand-Up Meeting” (also aliased as “Daily Meeting” and “Scrum Meeting”8) where the pattern includes:

Hold short daily meetings with the entire team to exchange critical information, update status, and/or make assignments. The meetings should last no more than 15 minutes, and generally happen first thing in the morning.(7)

In another paper where Jim attempts to analyse the success of the Borland Quattro Pro team back in 1993, he describes a significantly heavier approach to meetings (perhaps reminiscent of recent “mobbing” practice(10):

The core architecture team met daily to hammer out C++ class interfaces, to discuss overall algorithms and approaches, and to develop the basic underlying mechanisms on which the system would be built. These daily meetings were several hours in duration; from what I heard, the project was made more of meetings than anything else.(9)

In the same paper he talks about “(almost daily) project meetings” so it’s possible that the Borland team were using both practices.

This short history already illustrates a direction of change away from focus on the traditional project towards something different.

The historical context for the agile manifesto comprised many different experiences which coalesced in the Agile Manifesto and then developed into different interpretations via the various Agile frameworks which emerged.

Scrum

Scrum has been around since OOPSLA in 1995(32). The official 2020 Scrum Guide devotes 170 words to the “Daily Scrum”(11) (about 4.5% of the overall guide).

Scrum doesn’t use the term “stand-up”. Instead, the current literature uses the term “Daily Scrum”. The emphasis is on what to do that day to contribute to achieving the Sprint Goal, for which the members of the development team are accountable.

Scrum.org makes a big deal out of distinguishing the Daily Scrum from a “status meeting” (reporting progress) by emphasising the focus on the plan for today’s work — optimised to achieving the Sprint Goal.

The traditional emphasis on status enshrined in the recommended format “What did you do yesterday?, What will you do today?, Are there any impediments in your way?” appears to have been purged from the “official” Scrum documentation and Sutherland blogged about the change, saying that

In 2017, Ken Schwaber and I made the three questions in the Daily Scrum optional because we saw too many “zombie” teams that were giving lip service to the questions(6)

In many instances, the three daily questions had degenerated into non-answers, or had been swamped by reporting status rather than functioning as a guide for optimising the day’s work to help complete the Sprint Goal.

The Scrum guide currently says:

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work” — Schwaber and Sutherland, 2020).

However the older formulation can still be found in the recommendations of notable Scrum gurus such as Mike Cohn.(12)

A potential pitfall for the Daily Scrum is the use of the meeting to carry out useful project work as a team (talk through decisions, report on client meetings etc.). Advice is to concentrate on only (just) what is necessary to decide how best to allocate effort for the day to advance the sprint goals.

Cohn puts it this way:

The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting.”(12)

All sources seem to concur that a Daily Scrum should not involve (or at least, should not focus on) people who were not actively part of the original commitment to the current Sprint Goal. The intent is for teams to be self-organising rather than directed by a manager or external authority figure on a daily basis.

Scrum affords special status to those who are committed, and many teams enforce a rule in which only those who are committed are allowed to talk during the daily scrum meeting.(12)

Despite the emphasis on team empowerment and self-organisation, Scrum is nevertheless quite prescriptive about the framework itself. The official 2020 Scrum Guide states that “The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum.”(11)

So, the Daily Scrum should not be considered in any sense optional for the Scrum framework.

Scaled Agile Framework (SAFe)

SAFe is interesting in that it attempts to be a meta-framework, allowing for the embedding of various other practices (Kanban, ScrumXP) within its much wider remit(13). As such, it can’t have a single definition for a stand-up.

That being said, if you browse the glossary, you will come across a page called “Iteration Execution”(14) where they define “The Daily Stand-Up (DSU)”. SAFe love their acronyms and recommend that you hold this meeting “in front of a BVIR”. Searching for this term will reveal that it means “big visible information radiators” (a mashup of “Big Visible Chart” (attr. Fowler) and Cockburn’s“information radiator”³³)

Interestingly, the recommended format is similar to the older Scrum formulation (though helpfully clarified): “What did I do yesterday to advance the iteration goals? What will I be able to complete today to advance the iteration goals? What’s preventing us from completing the iteration goals?”

Also similar, but now highly codified, is the emphasis on not fixing problems during the meeting:

The Scrum Master writes down topics that need further discussion on the ‘meet after’ board. During the meet after, only the involved parties stay to discuss these topics in more detail The Scrum Master writes down topics that need further discussion on the ‘meet after’ board © Scaled Agile, Inc.

The documentation also notes that this DSU is a Scrum event but says Kanban teams may also use it. The terms Scrum and ScrumXP appear to be interchangeable within their documentation.

Due to the nature of SAFe which intends to encapsulate many different disciplines, SAFe itself can’t be said to strictly enforce any sort of stand-up, but the larger enterprises targeted by SAFe are very likely to adhere to a consistent morning meeting of some sort, due to their tendency to follow traditional project management strategies.

The DSU seems designed as a drop-in concept drawing heavily on Scrum, for teams which don’t readily adhere to some other methodology. It could also be used to introduce some Agile values into a team looking to transition away from a traditional morning project meeting.

Crystal

Crystal is a family of methodologies — with different formulations for different sizes of team/organisation ranging from small teams (6–8) to large organisations (50,000+ people), and differing levels of “criticality” (soft/hard).

Alastair Cockburn is largely responsible for the overall framework/principles. In his book Crystal Clear; A Human-Powered Methodology for Small Teams(15), he identifies a few of the key Crystal principles, one of which is:

The team continually adjusts its working conventions to fit the particular personalities on the team, the current local working environment, and the peculiarities of the specific assignment. — Cockburn, 2004, xviii

Given this framing of the philosophy behind the book, it’s clear that the techniques discussed are not intended to be mandated, but are instead introduced as “sample techniques”. This includes a description of a technique called “Daily Stand-ups” (introduced alongside other sample techniques such as “Delphi Estimation”, “Blitz Planning” and “Side-by-Side Programming”.)

Crystal does not require any specific technique to be used by any of the people on the project, so these techniques are included only as a starter set. — Cockburn, 2004, xviii

Perhaps disappointingly, the technique basically defers to the Scrum methodology (although, interestingly, not as the “Daily Scrum”)

The term “daily stand-up” comes from the Scrum methodology (Schwaber 2002). The idea is to get rid of long so-called status meetings where programmers ramble on for five or ten minutes about a piece of code they are working on or where management people ramble about various project initiatives. — Cockburn, 2004, p78

It also cites the three traditional Scrum questions and claims that “It is simple, and it has been added into projects using every imaginable methodology with good effect.”

However, as an overall contribution to the referenced book’s material on Crystal, the Daily Stand-up Meeting is vanishingly small — half a page in a book of 312 pages.

One slight deviation from other methodologies which emphasise the importance of the stand-up coming first thing in the morning, is a passing reference to “Each morning, noon, or late afternoon, the team is likely to have its… stand-up meeting.” — Cockburn, 2004, p126

Extreme Programming (XP)

In one of the authoritative online XP references “Agile Software Development: A gentle introduction”(16), Don Wells states that:

The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.(17)

This, arguably esoteric, statement perhaps implies that the XP “rules” are intended less as a process which people must follow than as guard rails or training exercises to instil the desired values in XP practitioners.

Perhaps surprisingly, Don recasts the “daily stand up meeting” as something of particular value to managers as opposed to Scrum’s emphasis on non-manager benefits:

Developers receive feedback constantly by working in pairs and testing code as it is written. Managers get feedback on progress and obstacles at the daily stand up meeting.(18)

Also diverging from frameworks like Crystal, XP explicitly states a rule that “A stand up meeting starts each day”(19)

The section of Don Wells material on the Daily Stand Up Meeting is brief and focuses on values rather than detail. The “stand up” nature of the meeting is introduced as a technique to avoid long discussions. The fact that “most attendees do not contribute” is acknowledged, but, in contrast to Scrum, there is no explicit recommendation to avoid these people attending. Rather the emphasis in XP is to reduce the amount of time spent in meetings overall.

When you have daily stand up meetings any other meeting’s attendance can be based on who will actually be needed and will contribute. Now it is possible to avoid even scheduling most meetings.(20)

Here again, XP doesn’t attempt to turn the Stand Up Meeting into an exercise in self-organisation (though that is one of the XP values), and does list three things which every developer should “report” on: “what was accomplished yesterday, what will be attempted today, and what problems are causing delays” in a similar manner to Scrum’s traditional formation.

The daily stand up meeting is not another meeting to waste people’s time. It will replace many other meetings giving a net savings several times its own length.(20)

Generally speaking, XP mandates a Daily Stand Up Meeting in an attempt to mitigate the tendency for a “typical project meeting” to “waste people’s time”.

Kent Beck, speaking a few years ago puts it this way, re-emphasising XP’s take on this meeting as a more traditional status update meeting, again casting it as the price to be paid to avoid the need for that type of communication during the rest of the day.

It should be noted that, despite XP practitioners being well known for strongly wording their opinions, Don Wills also includes a section called “Fix XP When It Breaks”(21):

Fix the process when it breaks. I don’t say if because I already know you will need to make some changes for your specific project. Follow the XP Rules to start with, but do not hesitate to change what doesn’t work… Have retrospective meetings to talk about what is working and what is not and devise ways to improve XP. Make improving your process a normal part of your development.

So perhaps Daily Stand-Up Meetings in XP should be viewed as a necessary starting point, from which the team may choose to deviate if they find a more appropriate way to accomplish the stated goal of avoiding project/status meetings during the day while remaining aware of overall status.

Note that different authorities on XP have somewhat divergent opinions on some components of the practice with Martin Fowler, Don Wells and Kent Beck seen as the foremost authorities. However, opinions around the purpose and practice of daily stand-up seem to be shared.

Kanban (and Kanban Methodology)

Kanban is a Japanese word for which Google (mea culpa…) suggests translations such as sign, signboard, billboard and poster (among others).

In the software world, it’s often loosely associated with things like Theory of Constraints(22), WIP levels and kanban boards(23), flow and continuous (non-timeboxed) delivery of value(24).

But is Kanban Agile?

Answering this question is rather like looking at a Gorgon. If you address the subject, head on, you’re likely to end up petrified.

In Anderson and Carmichael’s Essential Kanban Condensed, they record that “According to surveys of Agile organizations, the Kanban Method is widely used, either as the main process or in conjunction with another, such as Scrum” but they stop short of stating that Kanban Method is Agile.

The Agile Alliance list Kanban and Kanban Board in their Agile Glossary(25) and include things like “Kanban board” and “Lead time” in their Agile Subway Map(26).

However, David J Anderson, inventor of Kanban Method — a formalised application of kanban practice to the software delivery world —tends to be rather less conciliatory:

So there have been 15 years of Agile and yet we still don’t have very many case studies showing tangible business benefits and real ROI. Meanwhile, Agile consulting firms thrive on supplying the large numbers of coaches required to “go Agile.” Perhaps, it is time to ask, “Is there an alternative approach to agility that costs a lot less?”(27)

This follows a general trend since 2010 whereby technology workers increasingly distinguish between agility (aka “Agile with a small ‘a’”) and Agile (sometimes implying established Agile Frameworks such as Scrum). This idea goes hand in hand with another popular critique that the idea of Agile itself has been watered down in common parlance — becoming synonymous with very general ideas such as “lightweight” or even “anything but waterfall”.

Many people consider Kanban to be “Agile” if only because, at least in Western culture, it is a recent alternative to traditional project management and waterfall process. However, Anderson argues against conflating the two philosophies by virtue of their means of transformation:

Kanban doesn’t require you to add people to your organization as coaches or product owners, instead it provides existing workers with a means to frame and make better quality decisions. Kanban is empowering and enabling. Workers become more effective at doing their existing jobs in the existing process and workflow — no need for coaching in a new role as part of a new process. It’s simply more effective to stick with what you do now and get better at it, than it is to make grand changes.(27)

This isn’t a debate which is likely to be settled. However, if you look at reports on the popularity of Agile methods, Kanban always appears within the top five, so it’s included here for completeness, with the caveat that it may or may not fit alongside the other processes mentioned in this article.

Note also that many organisations which claim to be practicing Kanban may fit the patterns described in the book “Scrumban — Essays on Kanban Systems for Lean Software Development” where Ladas suggests an amalgam.(30)

The Kanban Meeting

Kanban Method advocates for a series of progressively larger cadances for feedback, nested inside each other, in a similar way to XP. An outer cadence of “Strategy Review” is suggested might occur quarterly, “Risk Review” might happen monthly, “Replenishment Meeting” could happen weekly, and “Kanban Meeting” generally happens daily (Anderson and Carmichael, 2016, p24)

Anderson and Carmichael describe the Kanban Meeting as “the (usually) daily coordination, self-organization, and planning review for those collaborating to deliver the service. It often uses a “stand-up” format to encourage a short, energetic meeting with the focus on completing work items and unblocking issues.” (p25)

However they also note that

Implementing the seven cadences does not imply adding seven new meetings to an organization’s overhead, although the Replenishment and Kanban Meetings are considered a baseline in nearly all Kanban implementations. Initially, the agenda of each cadence should be part of existing meetings and adapted in context to fulfill their goals. On a smaller scale, a single meeting may cover more than one cadence. (p25–6)

It should be noted that, notwithstanding Anderson’s critique of Agile frameworks which require new roles to be introduced, Kanban Method has changed its stance on this principle(28) and has now introduced the concept of two new roles, one of which is the Service Delivery Manager which is pertinent to the Kanban Meeting:

The Service Delivery Manager is responsible for… facilitating the Kanban Meeting ... Alternative names for this role are Flow Manager, Delivery Manager, or even Flow Master.

Again, Anderson is eager to point out that Kanban isn’t Scrum and to distinguish a Kanban Meeting from a Daily Scrum:

Kanban has a (usually) daily Kanban meeting around the kanban board. It isn’t however a Scrum meeting. In a Kanban meeting you iterate over the tickets from right to left: Closest to completion to most recently started. There is a focus on the work and not on managing the workers or peer pressuring them to complete tasks.

. . .

So the elements of Scrum which are designed to create a sense of urgency using peer pressure are indeed missing.(29)

Official sources on Kanban seem wary of suggesting the traditional Scrum style three questions for a Kanban meeting. Although there are practitioners and product vendors who suggest these questions(31), generally speaking the advice stops short of this structure and merely suggests the use of the kanban board.

Wrap-up and Analysis

In considering the methodologies above, one way to analyse variations is to try and compare intent, implementation and evolution for the concept of daily stand-up, which I will attempt below.

Another way is to study the methodologies as a whole and attempt to discover ways to optimise the practice for Agile practitioners. For this I will defer to an academic study.

Intent

• Scrum
  A protected time for committed team members to enable active collaboration, (re-)planning, requests for impediment remediation and prioritisation necessary to optimise achieving the Sprint Goal(6)

• SAFe
  Constant communication, self-organisation, coordination of team activities and identifying (but not removing) issues blocking progress(14)

• Crystal

  An available (often default) technique which, in the context of a small team, is to quickly and efficiently pass information around the team(15)

• XP

  Reduce overall waste associated with the necessary task of discovering and disseminating status information to anyone who needs it. Per Don Wells, also helps communication “among the entire team.”(20)

• Kanban

  An optional meeting which can be the way to accomplish the necessary daily cadence of identifying work items which may be blocked or otherwise not flowing through the system, and who is working on resolving an issue(34)

Implementation

• Scrum

  15 minutes at the same time and place every working day of the Sprint. The Scrum Master is responsible for ensuring that the meeting is “positive, productive, and kept within the timebox”. However, the meeting is supposed to be for the Developers (in a spirit of self-management).(11)

• SAFe

  Happens at same time and place. Three standard questions to answer about achieving iteration goals: “What did I do yesterday? What will I be able to complete today? What’s preventing us from completing?” Leads into a “meet after” meeting, with topics noted by the Scrum Master identifying those who need to stay on for discussion.(14)

• Crystal

  Although not a mandated technique, in Crystal Clear, Cockburn describes the basic Scrum format for Daily Stand-Up Meetings, using the older “three questions” as a baseline (but without mention of a Scrum Master). Reasons for standing up during the meeting are discussed.(35) Also seen as part of wider continuous and “osmotic” communication.(36)

• XP

  In Extreme Programming Explained, Beck and Andres don’t mention a daily meeting in the list of primary practices. However, Don Wells does mention it and includes the three familiar focus questions about “what was accomplished yesterday, what will be attempted today, and what problems are causing delays”(20)

• Kanban
  First amongst the expected behaviours for teams using Kanban is a “Process uniquely tailored to each project/value stream”. Whether the Daily Standup is used as a technique, and the exact format should be a decision made in the context of the team. For many teams, a “facilitator, typically a project manager or a line manager, will ‘walk the board’… from right to left.” Emphasis will be placed on items that are blocked or delayed (indicated visually on the board). For larger teams (e.g. 50 people), the process might focus exclusively on such items. After Meetings (or “huddles”), which often function more like Scrum Meetings are expected to emerge naturally from the Daily Standup meeting (which often has a higher-level focus.)(34)

Evolution

• Scrum

  The original formulation of the Daily Scrum and the “three questions” can be found in a post by Schwaber from 1997(38). An interesting discrepancy from later formulations is the larger timebox of 30 minutes. The original “pigs and chickens” story is also cited. Another formulation the same year(37) appears on Sutherland’s site where the Scrum Master is optional, 15 minutes is stated as the timebox, and team members are helped to choose appropriate tasks “with the help of the Architect.” In contrast, these days, the mandate to exactly follow the three questions has been scrapped (see above), but Scrum Masters are now core to the process.

• SAFe

  Although SAFe was not released as version 1.0 until 2011(39), Dean Leffingwell was discussing how to best scale agile for “Large Enterprises” as far back as 2007 in his book “Scaling Software Agility”(40). The book recommends Scrum practices for the Daily Stand-up such as using the same time and location, limit to 15 minutes (1–2 minutes per report) and the three Scrum questions. The questions don’t specifically reference a Sprint commit, but there is a recommendation that “deviation” from “what was committed to for the iteration… should raise a red flag”. There is no mention of a Scrum Master, although the “team lead” is identified as the person who is supposed to do things a Scrum Master typically would in a Daily Scrum. In contrast, SAFe 5.0 specifically mentions “iteration goals” in each of the three questions, and uses the term “Scrum Master” instead of “team lead”. Furthermore, SAFe 5.0 states that “the DSU is a Scrum event”, although in theory SAFe attempts to embrace not only Scrum but also XP (or ScrumXP) and Kanban practices. Documentation of the DSU in its current form appears to have been added around the start of 2016(41).

• Crystal
  Crystal is the crystallisation of work started by Cockburn back in 1991 at IBM(42). In his book “Surviving Object-Oriented Projects” which he wrote in 1997, the practice of “Daily Standup Meetings” is documented including familiar rules such as 15 minute time box, standing up, and the three Scrum questions. There’s no mention of a Scrum Master, although he does state that “it makes sense to have someone in charge of the meeting”. In the 2004 book on Crystal, Cockburn keeps advice on Daily Stand-Up Meetings concise and delegates details to Scrum(35). By 2016, Cockburn’s recent work “Heart of Agile” explicitly states that “Agile has become overly decorated. The remedy is simple: collaborate, deliver, reflect, improve.” While he is not suggesting that such practices are not needed, he feels that people need to focus more on the core values inherent to Agile, and on how to preserve these as Agile processes scale up.

• XP
  The fêted origins of XP in the Chrysler C3 project don’t seem to include detail of day-to-day practices (or at least, not a daily standup). Don Wills’ documentation(22) includes a picture of a “Stand up meeting at C3” which indicates the existence of such meetings — although perhaps they were less (or more) than daily. The original list of “Core Practices” of XP as described by Ron Jeffries in 2011 don’t mention a Daily Standup, and Extreme Programming Explained mentions a weekly cadence for meeting and planning work, rather than a daily standup. Nevertheless, as cited above, casual references to a daily stand-up continue to crop-up. In 2018, Ron Jeffries (an XP founder) made a post where he suggests that “software developers of all stripes should have no adherence to any “Agile” method of any kind”(46). Anecdotally, it would appear that XP practitioners are less and less inclined to endorse any formal framework, and prefer to be guided by principles and ethos.

• Kanban
  In the earliest case study which David Anderson cites from 2004(49), the use of Kanban fits “around” other development practices PSP(48) and TSP(47), neither of which are prescriptive of a daily meeting. Initial Kanban applications seem to focus on system-level delivery pipeline concerns, rather than on methodology affecting individual developers. However, David Anderson’s book (2010 edition) does talk about a Kanban Meeting(32), and the current literature includes the addition of the role of Service Delivery Manager mentioned above, which has a responsibility for facilitating the meeting.

An Empirical Investigation of the Daily Stand-Up Meeting in Agile Software Development Projects

In her PhD thesis(50), Viktoria Stray attempts to investigate the Daily Stand-Up Meeting (DSM) to answer the following questions:

RQ1: What are the characteristics of DSMs in present agile software development projects?

RQ2: What are the key positive and negative aspects of using DSMs in agile software development projects?

Her study, which used four different companies as a basis for the research, finds that:

the average DSM for all four companies lasted exactly 15 minutes. Participants tended to stop paying attention when the time limit was reached. The average number of participants was 9.6. Around ten participants are appropriate for a DSM since a meeting of seven to fifteen participants is ideal for decision-making and problem solving (Doyle and Straus, 1993). At this size the meeting is large enough to allow for a facilitator and small enough to be informal and enable all participants to be involved. The procedural communication in the DSMs differed from what is described in the agile literature. Specifically, the DSM was not only a place for answering the three questions but also an opportunity for other types of interactions; discussing and solving problems accounted for the largest portion of the meetings. (p30-1)

Furthermore, she finds that

The three most prominent positive aspects that were identified were obtaining an overview of what other team members are doing, discussing and solving problems and having a short meeting. (p31)

and that

The three most prominent negative factors identified were reporting progress, spending too much time (due to both high frequency and long duration) and wasting time because people do not pay attention, often due to a low degree of knowledge redundancy or low self-management. (p31)

A “low degree of knowledge redundancy” is explained as “participants are uninterested in what others are doing because it does not concern them” and a “low level of self-management makes it easy for authoritative managers to use the meeting to obtain status information, mainly useful to themselves.” (p33)

She notes that

teams have a hard time finding a suitable time of the day for the meeting, and many teams use the meeting as the start of the day, which means that they do not work on development tasks until afterward. (p31)

And suggests that moving the meeting away from the start of the day may, in some scenarios, prove beneficial. She also notes that typical attitudes toward the meetings were very neutral on average:

Considering the popularity of the DSM, it was unexpected that the attitudes towards the meeting were not more positive. In contrast, many Scrum Masters were very positive towards the DSM. This is consistent with what Cohen et al. (2011)(52) found: Individuals who considered themselves as meeting facilitators considered the quality of the meetings that they led to be significantly higher than the other meeting participants.

Anecdotal Notes

In wrapping up this overview of the daily stand-up meeting, I should note that I have been an Engineering Manager for much of the past 2 years (2020–2021) during which the purpose of daily meetings was very heavily affected by the presence of the COVID-19 pandemic.

Often, people have just needed to talk and socialise, and to remember that they are not alone. At times, adherence to any strict formula for a stand-up meeting would have been ineffective due to the widespread need for people to use the occasion for more basic human interactions.

Reflecting on the past year has made me wonder whether focusing a morning meeting on work, rather than each other, is really the most effective way to accomplish our team goals for the day. I’m now interested in Cockburn’s work on Crystal (and Heart of Agile) due to the slight bias toward humanising elements of process.

1 Beck et al., “Principles behind the Agile Manifesto”. 2001, https://agilemanifesto.org/principles.html, Accessed 31 August 2021.

2 “About Agile Alliance”. https://www.agilealliance.org/the-alliance/, Accessed 31 August 2021.

3 “Daily Meeting”. https://www.agilealliance.org/glossary/daily-meeting, Accessed 31 August 2021.

4 “Agile 101”. https://www.agilealliance.org/agile101/, Accessed 1 September 2021.

5 “Three Questions”. https://www.agilealliance.org/glossary/three-qs, Accessed 1 September 2021.

6 Sutherland, Jake, “Why the Three Questions in the Daily Scrum Meeting?”. 3rd June 2006. https://www.scruminc.com/why-three-questions-in-daily-scrum/, Accessed 1 September 2021.

7 “Stand-Up Meeting”. http://www.orgpatterns.com/Organizational-Patterns-of-Agile-Software-Developm/bookoutline/thepatternlanguages/organizationconstructionpatterns/peopleandcodepatternlanguage/standupmeeting, Accessed 31 August 2021.

8 “Daily Meeting”. http://web.archive.org/web/20070104062142/http://www.easycomp.org/cgi-bin/OrgPatterns?DailyMeeting, Accessed 1 September 2021.

9 James, Coplien. “Borland Software Craftsmanship: A New Look at Process, Quality and Productivity.” Proceedings of the 5th Annual Borland International Conference, 5 June 1994, www.researchgate.net/publication/2816856_Borland_Software_Craftsmanship_A_New_Look_at_Process_Quality_and_Productivity, Accessed 1 September 2021.

10 “Mob Programming”. https://www.agilealliance.org/glossary/mob-programming, Accessed 1 September 2021.

11 Schwaber and Sutherland, “The 2020 Scrum GuideTM”. “Daily Scrum”, 2020, https://scrumguides.org/scrum-guide.html#daily-scrum, Accessed 31 August 2021.

12 Cohn, Mike. “Daily Scrum Meeting”, 1998–2021, https://www.mountaingoatsoftware.com/agile/scrum/meetings/daily-scrum, Accessed 31 August 2021.

13 SAFe 5 for Lean Enterprises, © Scaled Agile Inc., https://www.scaledagileframework.com/, Accessed 31 August 2021.

14 © Scaled Agile Inc., https://www.scaledagileframework.com/iteration-execution/, Accessed 31 August 2021.

15 Cockburn, Alistair. By Alistair Cockburn — Crystal Clear: A Human Powered Methodology for Small Teams (Agile Software Development Series): 1st (First) Edition. Addison-Wesley, 2005.

16 Wells, Don, “Agile Software Development: A gentle introduction”. 2009, http://www.extremeprogramming.org/, Accessed 2 September 2021.

17 Wells, Don, “Agile Software Development: A gentle introduction”. 2009, http://www.agile-process.org/, Accessed 2 September 2021.

18 Wells, Don, “Introducing Extreme Programming”. 2009, http://www.extremeprogramming.org/introduction.html, Accessed 2 September 2021.

19 Wells, Don, “The Rules of Extreme Programming”. 2009, http://www.extremeprogramming.org/rules.html, Accessed 2 September 2021.

20 Wells, Don, “Daily Stand Up Meeting”. 2009, http://www.extremeprogramming.org/rules/standupmeeting.html, Accessed 2 September 2021.

21 Wells, Don, “Fix XP when It Breaks”. 1999, http://www.extremeprogramming.org/rules/fixit.html, Accessed 2 September 2021.

22 Goldratt, Eliyahu M, and Jeff Cox. The Goal. Gower, 1993.

23 Radigan, Dan, “Working with WIP limits for kanban”. https://www.atlassian.com/agile/kanban/wip-limits. Accessed 2 September 2021.

24 Anderson, David J. and Carmichael, Andy. Essential Kanban Condensed, Lean Kanban University Press, 2016.

25 “Agile Glossary and Terminology”. https://www.agilealliance.org/agile101/agile-glossary/, Accessed 2 September 2021.

26 “Subway Map to Agile Practices”. https://www.agilealliance.org/agile101/subway-map-to-agile-practices/, Accessed 2 September 2021.

27 Anderson, David J., “Is Agile Costing You Too Much?”. https://djaa.com/is-agile-costing-you-too-much/, Accessed 2 September 2021.

28 Anderson, David J., “Emerging Roles in Kanban”. https://djaa.com/emerging-roles-in-kanban/, Accessed 2 September 2021.

29 Anderson, David J., “Scrumsplaining #2: There Is No Sense Of Urgency With Kanban”. https://djaa.com/scrumsplaining-2-there-is-no-sense-of-urgency-with-kanban/, Accessed 2 September 2021.

30 Ladas, Corey. Scrumban. Modus Cooperandi Press, 2009.

31 Siderova, Sonya. “The Rhythm of Success: Kanban Meetings”. https://getnave.com/blog/kanban-meetings/, Accessed 2 September 2021.

32 Schwaber and Sutherland, “The 2020 Scrum GuideTM”. “Acknowledgements”, 2020. https://scrumguides.org/scrum-guide.html#acknowledgements, Accessed 3 September 2021.

33 Cockburn, Alistair. Agile Software Development. “Agile Software Development: Forming Teams that Communicate and Cooperate”, https://www.informit.com/articles/article.aspx?p=24486, Accessed 3 September 2021.

34 Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010, p82–83.

35 Cockburn, Alistair. Crystal Clear: A Human-Powered Methodology for Small Teams. United Kingdom, Pearson Education, 2004, p78

36 Cockburn, Alistair. Crystal Clear: A Human-Powered Methodology for Small Teams. United Kingdom, Pearson Education, 2004, p247

37 Beedle, Michael A. “SCRUM is an Organization Pattern”. 3 December 1997. http://www.jeffsutherland.org/objwld98/scrum_pattern.html, Accessed 3 September 2021.

38 “Daily Scrums”. http://web.archive.org/web/19991103134019/http://www.controlchaos.com/scrumday.htm, Accessed 3 September 2021.

39 “About Scaled Agile Framework — A Brief History of SAFe”. Scaled Agile Inc. Retrieved 12 August 2020.

40 Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. ISBN 978–0321458193.

41 “Iteration Execution Abstract”. https://web.archive.org/web/20160113230801/http://www.scaledagileframework.com/iteration-execution/, Accessed 3 September 2021.

42 Cockburn, Alistair. Crystal Clear: A Human-Powered Methodology for Small Teams. United Kingdom, Pearson Education, 2004, pxv

42 Cockburn, Alistair. Surviving Object-Oriented Projects, p140–141

43 Cockburn, Alistair, “The Heart of Agile”. https://heartofagile.com/wp-content/uploads/2019/04/201611-Cockburn.pdf, Accessed 6 September 2021.

44 Fowler, Martin, “C3”. https://martinfowler.com/bliki/C3.html, Accessed 6 September 2021.

45 Beck, K and Andres, C. Extreme Programming Explained, 2nd edition. Addison-Wesley 2005, p46–47

46 Jeffries, Ron, “Developers Should Abandon Agile”. https://ronjeffries.com/articles/018-01ff/abandon-1/, Accessed 6 September 2021.

47 Humphrey, Watts. 2000. The Team Software Process (TSP) (Technical Report CMU/SEI-2000-TR-023). Pittsburgh: Software Engineering Institute, Carnegie Mellon University. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5287

48 Humphrey, Watts. 2000. The Personal Software Process (PSP) (Technical Report CMU/SEI-2000-TR-022). Pittsburgh: Software Engineering Institute, Carnegie Mellon University. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5283

49 Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010, ch4

50 Stray, Viktoria. “An Empirical Investigation Of The Daily Stand-Up Meeting In Agile Software Development Projects”. University Of Oslo, 2014. https://www.researchgate.net/publication/266850154_An_Empirical_Investigation_of_the_Daily_Stand-Up_Meeting_in_Agile_Software_Development_Projects

51 Viktoria Gulliksen Stray, Nils Brede Moe and Aybüke Aurum, “Investigating Daily Team Meetings in Agile Software Projects”, Proceedings of the 38th Euromicro Conference on Software Engineering and Advanced Applications, pp. 274–281, 2012

52 Cohen, M.A., Rogelberg, S.G., Allen, J.A., Luong, A.. Meeting design characteristics and attendee perceptions of staff/team meeting quality. 2011, Group, Dynamics: Theory, Research, and Practice 15, 90–104. doi:10.1037/a0021549