The Daily Standup - A Case Study about Agile Values
How to navigate through uncertainty using agile values.
When it comes to process management in tech companies agile is the status quo. In a world where every company is a software company, time to market of products decrease and markets get disrupted rather frequently it became the only way to keep up, innovate and embrace the change (of requirements).
Agile theories come in various flavors, while the values are alike. Transparency, trust, and ownership to name a few. Even though most companies pretend to be on an agile journey some might forget that it's less about whether you choose one framework or method over the other. It's fairly easy to understand the theory of Scrum or Kanban, but it's much harder to put them into practice. Why is that?
You guessed it - the values.
While choosing one theory over the other will have quite some operational impact initially, the real and hard change is related to the mindset of the people and is indeed a long journey. Once the theory is mastered and the values come to life through the day to day interactions an organization will start breaking the rules anyway(see the three stages of learning: Shu Ha Ri) and develop its very own flavor of agile. An example that still stands out to me is the engineering culture at Spotify.
The Case Study
All this talk about value and culture is very abstract. Let's focus on a small, very concrete example to see how the pieces fit together. I choose the daily standup meeting, also referred to as daily scrum or just daily for my case study here. If you are part of an agile engineering team, you will be familiar with the concept. For those who are not, follows a brief summary:
The daily is an internal team meeting in which attendees participate while standing and usually time boxed to 15 minutes. The discomfort of standing helps to keep the meeting short. The meeting allows a team to self-organize by inspecting their progress. Being aware of the work of others helps to uncover impediments, take actions to overcome them and fosters collaboration. The daily creates a common sense of responsibility and ownership while enabling the team to self-drive their progress towards the common goal. When conducted properly it reduces the necessity of other meetings.
That's the theory. Not so hard right? Let's discuss four anti-patterns that do occur in practice and how they correlate to values:
📈 Status Meeting for Manager
This is probably the most common misinterpretation of the meeting. The daily is not a status or reporting meeting for a manager. Various tools exist to visualize and understand progress towards a goal and managers should make use of it. Let's see what the Scrum guide has to say:
Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Aha! An inspection should not get in the way of work, should not be too frequent or even overtake the daily. If progress is not visible to others the agile coach must collaborate with the team to increase transparency and make work artifacts inspectable. However, it is also the responsibility of the agile coach to protect the team from unhealthy and distracting interactions and teach managers and stakeholders about the purpose of the meeting. Ideally, only development team members(someone who executes the work being discussed) should inspect and participate in the daily.
values: transparency, trust
⬇️ Top-Down Decisions
On the one hand, a product owner or manager decides what is being done, but on the other hand the team decides how something is done. Team members respect each other to be capable and independent people. They have the courage to make the right decisions at the right time allowing them to overcome impediments quickly. This bottom-up intelligence may be accompanied by guiding principles though. Decisions are escalated to managers only if contrary to agreed guiding principles. The daily is not an opportunity for managers to delegate work packages or tell employees how to do their work. Instead agile promotes the delegation of responsibilities.
values: trust, ownership, openness, respect, courage
🎯 No Common Short-Term Goal
When attendees do not work on the same product or project then naturally they have different or even competing goals. This can also apply for attendees working on the same product or project. Great focus and commitment are enabled when motivations are aligned with common goals. As agile theories are built upon empiricism and iterative development a team can craft a common short-term goal for each iteration to increase efficiency. The common goal will guide the discussion during the daily and help to understand progress towards it. Note that a short-term goal does not replace a clear product vision and strategy, which is out of scope here.
values: focus, commitment
🕸️ Team Not Decoupled
A team that requires the work of others will face an increased communication overhead. When the number of dependencies between teams increases the lead time of an issue being resolved will likely increase exponentially. This, in turn, results in decreased ownership. A team will feel less responsible when they are frequently blocked and need to wait for someone else. Being held responsible but not owning a process is highly demotivating. Agile promotes self-organized and cross-functional teams to enable local and quick decision making. It is important that a team has all the required knowledge and resources to get an issue done. Having members with different backgrounds and roles like developers, operations, and QA is essential for that. During the daily, cross-functional team members can learn from each other and identify impediments early as the progress is inspected from different perspectives.
Values: ownership
TL;DR
We have seen that the daily can be a great tool for a micromanager to track performance and delegate work( see anti-pattern 1-3). In this scenario, team members will feel that the meeting, or even agile in general, is useless. Some companies might say they do agile just because they have a daily. I hope this case study helps to clarify. While choosing an agile framework or method like the daily is indeed relevant, it is more important HOW a tool is used and HOW values are accepted and lived, especially by leaders. When a team finds that a tool is not working for them they should be empowered to try out another.
On the other end of the scale are highly aligned and decoupled teams, as those at Spotify. Agile teams are trusted to be capable and justify it via transparency, fast through local decision making and bottom-up intelligence, committed and focused through a common goal, autonomous as cross-functional and supported by their servant leaders. Those are the teams that have the courage, skill, and pace to navigate into uncertain waters and will innovate in new digital markets.
Over to you: What are your strategies to handle uncertainty professionally or personally?