Many tech teams begin their day with a short meeting requiring everyone’s participation.
These daily meetings are called “stand-ups” as they historically required the team to stand-up and give a brief overview of what they have been working on, as well as their work priorities for the day ahead.
Although these are great opportunities to have the team to efficiently come together, some people may find the meetings:
Take too long
Include dialogue that is not relevant to them
Contribute to work anxiety due to the pressure to provide positive updates
This article will look into the value of daily stand-ups, how to do them right and will analyse the following:
A brief history of management
People’s pain-points with stand-ups
How we can manage regular check-ins
Different teams need different practices
A Brief History of Management
Before analysing today’s management philosophies, it is important we take a step back and look at where they have come from.
Waterfall
Before modern management practices, technology teams used to follow processes that were rigid, linear and “un-agile”.
These processes can be described as linear as they do not facilitate moving back to review original requirements and the framework is now known as the Waterfall model.
An example of how a software team can structure their waterfall model is shown in the following, taken from Rob Lineberger’s book Inheriting Agile.
System: What are the product and/or software requirements?
Analysis: How do we do it? Here we there would be models and schematics
Design: Outputs would include architecture
Coding: Developing software
Testing: Testing, debugging and fixing software
Operations: Installing, migrating, supporting and maintaining systems
Waterfall is criticised for having to commit to concrete requirements before building software.
Agile
A more flexible, less rigid system used widely in tech industries today is Agile.
In the 1990s several software and manufacturing principles began evolving in reaction to rigid management frameworks described as “heavyweight” and micromanaged.
In 2001 the Manifesto for Agile Software Development was developed by pioneers of these (at the time) novel management principles.
Key management philosophies and methods leading up to the Agile Manifesto are outlined below.
Lean Manufacturing (1940s-present)
Lean manufacturing is a philosophy aimed to minimise waste, maximise quality and continuously work towards improving processes and efficiency.
Many principles of lean manufacturing come from the Toyota Production System (TPS) developed between 1948 and 1975 by industrial engineers Taiichi Ohno and Eiji Toyoda, originally known as ‘just-in-time production’.
TPS aimed to reduce several types of time-waste, including overproduction, waiting transportation and several others in order to optimise production.
In the 1990s, lean management in manufacturing (lean manufacturing) became re-popularised at a time where other industries such as software development were developing new management techniques too.
Rapid Application Development (RAD), 1991
James Martin’s book “Rapid Application Development”, described software development approaches that put more emphasis on adaptive processes and less on planning.
Prototypes are preferred to design specifications.
Dynamic Systems Development Method (DSDM), 1994
In 1994 the DSDM consortium was founded to provide structure and discipline to the RAD method which became widely used in the IT industry but was criticised for not having a defined structure or process.
DSDM like other frameworks has a strong focus on communication.
In 2016 the DSDM consortium rebranded as the Agile Business Consortium.
Scrum, 1995
In 1995 a research paper called “Buisiness Object Design and Implementation” was one of the results of several company leads testing “scrum theory”.
Scrum is a framework used in software development and involves breaking down large tasks into smaller time-boxed tasks called “sprints”.
A sprint period is generally between one week and one month and is expected to result in a tangible deliverable.
Within a sprint there are meetings called daily scrums (a direct reference to rugby) intended to last a maximum of 15 minutes and requiring each team member to update everyone on:
The progress they have made
Any blockers they are facing
A scrum team is made up of:
Product owner: Someone responsible for liaising with steak-holders and users
Developers/Engineers: People involved in developing the technology
Scrum master: Different to traditional management roles, a scrum master educates the team on how scrums work
The advantage of having small sprints with product owners, is that the requirements and development paths can change iteratively.
Daily communications ensure the deliverables of the time-boxed sprints are produced as efficiently as possible.
Today’s Challenges
Fast forward to today and agile frameworks are widely used and daily stand-ups are a key part of regular checkins.
But as mentioned earlier, not everyone loves daily stand-ups.
People I’ve spoken to personally as well as online forums share several pain-points as well as management techniques to ensure the correct value is being extracted.
Not Everyone Pays Attention
The meeting immediately loses value when people don’t feel the need to listen to what people are sharing.
Although this might seem like a discipline issue, the drop-off in attention can be caused by:
Updates taking too long
People speaking in their own technical language (when the meeting includes people in different teams)
People going into too much detail
A Reddit thread on the data science subreddit discusses people’s pain points and solutions.
Remote Teams Interrupting Work Flow
To add to the complexity of debate around remote, hybrid and in-office work, scheduling a morning meeting for a global team is impossible.
Timing may seem trivial, but people who have worked in programming or engineering may feel as though meetings throughout the day can cause friction to pieces of work that require full focus.
The issues some remote team members may face include:
International teams catch-up at times that are not at the beginning of the day (for everyone)
When people are remote in the meeting, those not speaking are able to get away with not listening and continue working in the background
It is important to note however that there are strong arguments for regular check-ins for remote teams, such as:
A daily check-in can manage the reduced visibility on what people are working on that inevitably comes from not working in-person
With less exposure to social interaction some team members may enjoy daily conversation with their colleagues
A Reddit thread on the devops subreddit discusses the challenges of daily stand-ups in remote teams.
Work Anxiety
Daily updates on work puts pressure on delivering positive news everyday about how they are delivering a task.
There is a strong argument that in some cases, pressure is necessary to produce a high-quality of work, particularly on time-critical tasks in time-boxed sprints.
It can also be argued that feeling micro-managed is a reflection of company culture more so than stand-ups themselves.
A Reddit thread from the software development subreddit shares people's experiences with feeling stressed around delivering positive news in stand-ups.
Doing Stand-Ups Correctly
It’s easy to criticise a management tool, however if managers and team-leads are sure a daily check-in is necessary for them there are good practices to follow.
Be Strict on Time and Detail
Some people suggest having a timer during people’s updates to prompt them into giving their updates.
It is also far too common for some people to go into too much technical detail for what they are working on when it is not necessary.
Introducing small break-out discussions, or smaller team meetings can allow people to share relevant technical information, keeping stand-ups higher-level.
The risk with overspending on time, is that the whole team are present in a meeting - wasting valuable person-hours goes against the principles of lean management discussed earlier.
Consider Less Frequent Stand-Ups
Some teams work well with daily check-ins, while others do stand-ups 2-3 times per week.
Having stand-ups at the beginning, middle and towards the end of the week means updates can feel less granular and more of a weekly plan/review.
Focusing on Tasks Rather Than People
Although people can criticise people for saying they feel pressure to deliver updates in stand-ups, it is important to know everyone is driven differently.
Implementing changes that make your team less anxious will always pay itself back in the long-run by improving work culture and letting people work in an environment without unnecessary pressure.
We can make meetings more task centric by:
Structuring the meeting by going through lists of tasks (rather than people) still allows people still contribute and give updates when needed
Having smaller team meetings first, so that team-leads already know their team’s updates - team leads can even deliver their team members’ updates on their behalf so it remains high-level and time boxed
Ask Your Team
As different teams will require different communication practices finding out how much value it brings to different team members is a key indicator of how well they work.
A Reddit thread on the experienceddevs subreddit has a great discussion of how everyone does stand-ups differently.
Touching base with team members their thoughts may lead to similar ideas.
Different Teams Need Different Practices
Carrying out a ritual does not make it a valuable tool.
Every team I’ve worked in has done stand-ups differently
In a five-person multidisciplinary team we met twice a week, where most of us were in the office four to five days per week. Working in-person meant that two check-ins a week were perfect for us, as we already had good visibility on what everyone was working on.
I was also in a team which was more focused on software, more remote and had a daily meeting.
In teams that build hardware, development cycles are longer and sprints do not feel as time-boxed.
To maintain strong communication in high-urgency hardware teams the following is valuable:
Working and meeting in-person
Having smaller/technical team meetings before company-wide meetings
Having these meetings once at the beginning of the week
Although these practices do not resemble a scrum template a software team may follow, it works well for in-person hardware teams and can fulfil the principles of lean or agile development
Great overview Greg, I enjoyed it :)
I especially relate to asking the team what they prefer. I was surprised to learn that they prefer it daily, and they enjoy learning why others are up to 😅