Scrum Master Ant-Patterns — (Hands-on Agile Webinar #8)
•Als PPTX, PDF herunterladen•
1 gefällt mir•2,017 views
This Hands-on Agile mini-series addresses 12 familiar Scrum Master anti-patterns: from the agile manager to the team secretary to dogmatism. Let us start with a short refresher from the Scrum Guide. According to it, the “Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand the theory, practices, rules, and values of Scrum. The Scrum Master is a servant-leader for the Scrum Team.” Finally, the “Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.” (1) The first Scrum Master anti-pattern covers the agile manager. Self-organization does not mean the absence of management: why handle pay-role as a Scrum Team? Outsourcing of tasks to the management is hence common. However, Scrum is by all means not about exercising command & control; the Scrum master is not a supervisor. (2) The second Scrum Master anti-pattern covers the Scrum team secretary and Scrum parents. The Scrum parent is generally shielding the team from the cold and cruel world, creating a safe & happy agile bubble. (3) The third Scrum Master anti-pattern covers the imposter. Dolla, dolla, bill ya'll—the Scrum Master imposter believes that this agile/scrum thingy is a fad—how hard can it be, the Scrum Guide is just 17 pages. (4) The fourth Scrum Master anti-pattern covers Scrum dogmatism. The Scrum Master enjoys teaching (and never leaves the Shu-phase). (5) The fifth Scrum Master anti-pattern covers failing at the capacity game. The Scrum master does not address the necessity of slack time by fighting the push for 100% utilization. (6) The sixth Scrum Master anti-pattern covers the flow undermining Scrum Master. The Scrum Master allows stakeholders to disrupt the flow of the development team during the sprint. (7) The seventh Scrum Master anti-pattern covers the Scrum Master with a metrics fetish, pursuing flawed metrics. The Scrum Master keeps track of individual performance metrics such as story points per developer per sprint. (8) The eighth Scrum Master anti-pattern covers the Scrum Master ignoring Scrum values. (9) The ninth Scrum Master anti-pattern covers the skipped Retrospective. All Scrum events are essential for a team’s success—you cannot skip any event. (10) The tenth Scrum Master anti-pattern covers the Groundhog-Day retrospective. The retrospective never changes in composition, venue, or length. In this case that the team will likely revisit the same issues over and over again—it’s groundhog day without the happy ending, though. (SUMMARY) The last chapter summarizes my dirty dozen of Scrum Master anti-patterns: from ill-suited personal traits and the pursuit of individual agendas to frustration with the team itself.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Mehr von Stefan Wolpers
Mehr von Stefan Wolpers (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Scrum Master Ant-Patterns — (Hands-on Agile Webinar #8)
- 1. Hands-on AgileWebinar #8 Scrum Master Anti-Patterns October 16th, 2018, at 6 pm CEST (12 pm EDT or 9 am PDT)
- 2. Scrum Master According to the Scrum Guide stefan@age-of-product.com
- 4. stefan@age-of-product.com#1: The Agile Manager
- 5. #2: Team Secretary & Scrum Parent stefan@age-of-product.com
- 6. #3: Scrum Master Imposter stefan@age-of-product.com
- 7. #4: Scrum Dogmatism stefan@age-of-product.com
- 8. Scrum Master Anti-Patterns: Ignorance & Mediocrity stefan@age-of-product.com
- 9. #5: Failing at the Capacity Game stefan@age-of-product.com
- 12. #8: Ignoring Scrum Values stefan@age-of-product.com
- 14. #9: Skipping Scrum Events — No Retrospective stefan@age-of-product.com
- 16. #11: Line Manager Alert stefan@age-of-product.com
- 18. #12: The Frustrated Scrum Master stefan@age-of-product.com
- 19. Summary: Scrum Master Anti-Patterns stefan@age-of-product.com
- 20. Hands-on AgileWebinar #9 Sprint Review Anti-Patterns November 6th, 2018, at 6:15 pm CEST (12:15 pm EDT or 9:15 am PDT)
- 21. The Age of Product Youtube Channel
- 22. Contact Information StefanWolpers Email: stefan@age-of-product.com Blog: Age-of-Product.com Newsletter: https://age-of-product.com/subscribe (Join 19,000-plus peers) Slack: https://hands-onagile.slack.com/ (Join 4,000 peers) Twitter 1: @StefanW Twitter 2: @AgeOfProduct
- 23. About Stefan Wolpers Agile Coach, Scrum Master, and Product Owner since 2006: stefan@age-of-product.com
Hinweis der Redaktion
- Welcome 8th Hands-on Agile Webinar I am your host Stefan Wolpers Some housekeeping: Q & A — now with voting! Now, my dirty dozen of scrum master anti-patterns —
- According to the Scrum Guide: The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand the theory, practices, rules, and values of Scrum The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. The keystone of the definition of the scrum master role is the servant leadership aspect. In most cases of scrum master anti-patterns, it is often this part that the individual is not living up to.
- Agile management: Self-organization does not mean the absence of management: why handle pay-role? Outsourcing of tasks to the management is common (=> Delegation poker, Management 3.0) However, Scrum is by all means not about exercising command & control ; the scrum master is not a supervisor. (typical Signs of Taylorism: Providing working agreements to speed up the getting productive phase of a new or inexperienced team Turning the daily scrum into reporting session (“Who is next, Malcom?”) Pushing the team to take more on during sprint planning (“why are you only picking stories worth 12 story points?) Assigning sub-tasks to developers Defining technical solutions: The engineer turned SM and is now ‘suggesting’ how the scrum team implements tasks
- The Scrum parent is generally shielding the team from the cold and cruel world, creating a safe & happy agile bubble. Some manifestations are: Scrum parent deals with all impediments personally, although practically any other team member could act, too. Scrum parent filters feedback from stakeholders, particularly any negative feedback. Often, she does so by not merely restricting access to the team, but basically shutting it off. Scrum parent is pampering the team, for example by running errands, or being the team secretary, sometimes bordering on the helper syndrome. Scrum parent is also preventing the team from failure whenever possible. This even applies, if failing would be easily fixable and wouldn’t be really damaging. (Remember: If you’re not failing, you’re not pushing hard enough…) Empiricism is based on learning which is inevitably linked to failure. Scrum parent is not really challenging the team. She seems to be content, once a certain level of proficiency is achieved. (What about Kaizen?) Scrum parent maybe setting boundaries, but is rarely enforcing them. She tends to tolerate damaging behavior from team member in the (futile) hope, the culprit will be insightful and improve over time. (=> Scrum Guide; Shu-Ha-Ri) Scrum parent‘s motto: “Right or wrong, my team!”
- Dolla, dolla, bill ya'll—the scrum master imposter: agile/scrum thingy is a fad — how hard can it be, the Scrum Guide is just 17 pages. “I will weather the temporary decline in demand for project managers by getting a scrum master certificate.” Should have become obvious during the recruiting process Unless the HR department defies all learnings how to hire people with an agile mindset (=> Peer recruiting, trial days etc.) You cannot hide greed — this conviction will bring out his or her true colors over time inevitably.
- The SM enjoy teaching (and never leaves the Shu-phase): Shu-Ha-Ri model from martial arts (=> Lyssa Adkins: Coaching Agile Teams) Shu Ha Ri: Pattern of achieving mastery. Ultimately, the student shall surpass the master. Three stages: 1) Shu: Follow the rule (=> SM: teaching). 2) Ha: Break the rule (=> SM: coaching). 3) Ri: Be the rule. (=> SM: advising) Shu: The student copies the techniques as taught without modification and without attempting to understand the rationale. (Follow the rule’s way.) The problem: Teaching feels good: Team members come and ask for help (=> purpose) People follow the rules (=> influence or authority) The SM can easily attribute the team’s progress or success to his or her teaching. (=> mastery) However, to become self-organizing, the team needs to move beyond the Shu-phase. Shu anti-pattern: application is mechanistic. Problem: it results in the creation of an empty ritual. (=> Cargo cult Scrum.)
- the scrum master does not address the necessity of slack time by fighting the push for 100% utilization Technical excellence is the route to agility — see State of DevOps Report of Accelerate by Nicole Forsgren und Jez Humble scrum team’s effectiveness will be significantly impeded if the team does not address technical debt every sprint. The team will also suffer if there is no time for pairing, mobbing, training, and knowledge sharing 100% utilization always reduces the team’s long-term productivity — Note: it is not immediately visible, it is deteriorating over time! utilization rate of 100% is classic taylorist line management thinking. (People are lazy, try to rip us off)
- Flow disruption: The scrum master allows stakeholders to disrupt the flow of the development team during the sprint. For example: The SM has a laissez-faire policy as far as access to the development team is concerned. The SM does not object that the management invites engineers to random meetings as subject matter experts. The scrum master allows that either stakeholders or managers turn the daily scrum into a reporting session. Preserving the flow of work through the team during the sprint is the lynchpin of productivity: That’s why WIP limits are useful (=> thus avoid creating artificial queues) That’s why the reason why the PO needs to be available at all times Be cautious: If the Scrum team fails, no stakeholder will read this kind of “what happened during the sprint” fine-print afterward. All they see is “not delivered.”
- Pursuing flawed metrics: The scrum master keeps track of individual performance metrics such as story points per developer per sprint Worse: probably to report the metrics that person’s line manager. A supervisor hack to reintroduce command & control through the back door. (=> cargo-cult scrum) Burn-down chart hugger: The scrum master focuses his or her work on producing a daily update to the burn-down chart. If the team considers a burn-down chart useful to monitor progress toward the sprint goal — fine. However, if the burn-down chart is solely maintained to track the output for reporting purposes the team needs to challenge this attitude.
- Teambuilding Scrum Values => Transparency, Inspection, Adaptation => Trust Scrum Guide: When the scrum values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, => Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts. Successful use of Scrum depends on people becoming more proficient in living these five values.
- All Scrum events are essential for a team’s success — you cannot skip an event: Junior Scrum teams may be tempted to skip Retrospectives to buy some more time to meet the sprint goal. A Scrum Master accepting this “deal” provides a disservice to the team. Actually, the proposal is already a sign how urgent the team needs a retrospective. The scrum master postpones the retrospective into the next sprint. Beyond the ‘inspect & adapt’ aspect, the retrospective shall also serve as a moment of closure that resets everybody’s mind so that the team can focus on the new sprint. That is the reason why we have the retrospective before the planning of the next sprint: Postponing it into the next sprint will interrupt the flow of the team. (=> additional cognitive load, context switch.) Delays also tackling possible improvements.
- Groundhog day: The retrospective never changes in composition, venue, or length. in this case that the team will likely revisit the same issues over and over again – it’s groundhog day without the happy ending, though, an empty ritual What you can do: Repository of exercises for all five stages — never run the same retro twice. Need ideas? Use Retromat, Tasty cupcakes — or be creative with Liberating structures, Training from the back of the room Talk to your fellow SMs (HoA Slack) Change the venue Theme the retrospective — why not have a Halloween-spective?
- Stakeholder alert: The scrum master permits stakeholders and worse — line managers — to participate in the team retrospective. The team should refuse to participate… (=> Scrum values => transparency, inspection, adaptation => trust) Alternatives: Run a separate overall retrospective with stakeholders Other scrum ceremonies that address the communication needs of stakeholders: the sprint review, probably the product backlog refinement, the daily scrums Plenty of opportunities of having a conversation at water coolers, over coffee, or during lunchtime. Tricky situation: the line manager serves also on the team — avoid this at all costs: a promotion means that you probably need a new tea,
- What if your scrum master is frustrated? The scrum master has been working his or her butt off for months, but the team is not responding to the effort. (Pearls before swine?) Good SMs are in for a purpose, they want to have impact. Hence the level of frustration is growing. There are a lot of potential reasons for a failure at this level: the lack of sponsoring from the C-level of the organization, a wide-spread belief that ‘agile’ is just the latest management fad, and thus ignorable. The team composition is wrong. There is no psychological safety to address problems within the team, No failure culture — learning by failure is merely a lipservice the company culture does not value transparency. Or individual team members harbor personal agendas unaligned with the team’s objectives. (=> Incentives are based on individuals, not the team.) Note, that the scrum master cannot solve this issue by herself or himself. The cooperation of the team is required.
- Let’s summarize the dirty dozen of sprint anti-patterns.
- Some background on myself: I have spent 12-plus years in agile Mostly as a product owner in fast growing, vc-funded startups in Berlin (including a later Google subsidiary) At the moment, I am working as an agile coach/scrum master for a large European electricity and gas provider