Myth: During Daily Scrum, everyone needs to state what they have contributed.
It will quickly become obvious who is contributing and who is not.
Variations: During Daily Scrum, we observe how productive everyone has been.
Everyone talks about their activity plan and achievements so we can see who is busy and who is not.
Follow-up myths:
- Peer pressure will force these people to start contributing.
- Management can observe the Daily Scrum and draw their own conclusions.
Danger: High
The basis of the myth
The Scrum guide states:During the meeting, the Development Team members explain:This is then interpreted as: "Everyone states what activities they did, failed to do and will be doing." and from there stretched into a negative dimension with the afterthought: "When people didn't do enough, they need to do more."
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Why is it a myth?
The myth thrives on a large number of hidden assumptions, all of which are actually contradictions to the 5th agile principle: "Build teams around motivated individuals. Give them the environment and support they need, and trust them to get the job done".Hidden assumption #1: People must be put under scrutiny
The very idea that we need to expose people confines a lack of trust, a clear violation of Principle #5. Rather than figuring out how we can use the Daily Scrum to expose people who don't get their job done, we should start digging in the organization why we can not trust them to do that. As a Scrum Master, we should ask the question: "What damages trust and how can we establish trust?"Hidden assumption #2: Slackers
Theory Y: There's no such thing as "slackers"
The concept of "slackers" is derived from "Theory X". The Scrum Guide itself is neutral in the Theory X/Y debate. However, Theory Y is a premise of agility. The reason can be found in Agile Principle #5: Motivated individuals. Why would a motivated individual slack? Looking at cause and effect, we need to ask: "Why is that person not motivated?"
We set up management systems for the very purpose of reducing the impact of personal variation upon overall output. Our entire organizations, processes and structures are created to minimize dependency of individuals. Having created such a system, we look the fault for low performance with the individual - why? When our system has been created to provide a performance harness for individuals, we should look for the fault in the system, not with the person! "Why can't the person contribute?"
Hidden assumption #4: Fear is a solution
Based on Deming's 14 points (#8), we're not helping by setting an environment where developers need to be afraid that they won't have enough to show. We should therefore ask the question: "Is there a fear factor in our organization that permeates right into the Daily Standup?"
The concept of "slackers" is derived from "Theory X". The Scrum Guide itself is neutral in the Theory X/Y debate. However, Theory Y is a premise of agility. The reason can be found in Agile Principle #5: Motivated individuals. Why would a motivated individual slack? Looking at cause and effect, we need to ask: "Why is that person not motivated?"
Hidden assumption #3: It's a personal problem
Hidden assumption #4: Fear is a solution
Based on Deming's 14 points (#8), we're not helping by setting an environment where developers need to be afraid that they won't have enough to show. We should therefore ask the question: "Is there a fear factor in our organization that permeates right into the Daily Standup?"
Hidden assumption #5: Contribution is measurable
During Daily Scrum, the team should focus on inspecting and adapting the short-term plan, in order to maximze the probability to reach the goal. However, sometimes team members contribute in a way that can't be directly measured in terms of the Sprint goal.
Let's just take this example: Tim picks up Jill's kid from school, so that Jill can fully concentrate on squashing that elusive defect before shipping. Is Tim contributing? Obviously - but not by writing code. But now Tim has nothing to mention in the Daily. But Jill knows what he did.
Consequences
Looking at activity, productivity, busyness - and on the flip side, idleness, slack and spare time, will ensure that everyone finds ways to appear busy. However, the first Agile principle states, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.". When people have to appear busy every single day, we instill a mindset that being busy is a continuously observed top priority, and people will completely lose sight of the highest agile priority - satisfied customers.
In it's extremest form, developers will brush off customers with the statement "Go away, I'm busy?".
Driving the wrong culture
It is very easy to increase productivity by doing more work. However, the best way to obtain results is to minimize the work. Even the Agile Principle #10 states that we actually want to maximize the amount of work not done. We should never incentivize developers to find work to do, we should actually incentivize them to think of creative ways of being lazy - i.e., achieving a goal without doing work.
Distraction
One Scrum value is "Focus". However, when developers have to consider what activity they should mention during the Daily Scrum in order to look like they are contributing enough, they are definitely not focusing on the product, the customer and value - but on themselves and the work. As Scrum Master observing the Daily Scrum, we should actually move away from activity focus towards value and customer focus.
Breaking the team
When developers feel pressured to get some goal-based activity, they will do whatever they can to complete some goal-based activity. Depending on how strongly they perceive the need to do this, this may not only come at the price of brushing off requests for help from team mates who are stuck, but even incentivize behaviours ranging from being uncollaborative ("I need to get my stuff finished") all the way to sabotage ("Sorry Tim, I had to break your code to get my story done").
The team should focus on delivering the most value as a team, not as individuals.
Stating the obvious
In a team, everyone knows already who contributed what. That's somehow the definition of teamwork: You achieve something together. Therefore, my contribution from yesterday should already be obvious to everyone today. If my team mates don't know what I am doing, there is something wrong with the team, the plan or the approach: Now, that would make a good Retrospective topic.
However, when during the Daily Scrum, we spend time by telling people what they already know, developers will lose interest in the Daily Scrum. The Meeting will lose it's value to the only people whom it's for.
Congratulations - your Daily Scrum is dead.
Congratulations - your Daily Scrum is dead.
Remedies
Pro-actively, be very clear what it really means that the Daily Scrum is intended to "synchronize activities and create a plan for the next 24 hours" and not to "check on people".
When any of the above-mentioned dysfunctions become visible, first try to expose the assumptions leading to a behaviour which induces the need for justification, then resolve that problem.
If a developer actively states that they feel pressured by the Daily Scrum, think of "providing the environment, support and trust needed" and examine where the pressure comes from.
During Retrospectives, you can expose dysfunctions by asking questions, such as "Why are we having Daily Scrum?" or "How do you feel about our Daily Scrum?".
As Scrum Master, you need to work within the team and outside into the organization to ensure Daily Scrum is properly understood.
One temporary countermeasure might be to purposefully restrict attendance to the Daily Scrum until a specific issue has been resolved.
