Zombie Scrum - Symptoms, Causes and Treatment
- What is Zombie Scrum?
- seems to be normal Scrum. But it lacks a beating heart
- teams do all the Scrum events but a potential releasable increment is rarely the result of a Sprint
- team don't have any intention to improve
- nobody cares about this team
- is not a team-problem, is a manifestation of the disconnect between organizational values and Scrum values
- The Symptoms of Zombie Scrum
- Symptom #1: No beating heart
- may be going through the Scrum-motions
- hardly any working software
- Completed functionality is often treated as ‘nice-to-have’, and can be finished in other sprint
- very limited and unambitious definition of what ‘done’ means, and no drive to extend it
- Symptom #2: No (desire for) contact with the outside world
- prefer to hide away from people
- neither care what’s upstream nor what’s downstream in the value chain
- I’m only here to code
- unable and unwilling to change anything and have a real impact
- Symptom #3: No emotional response to success or failure
- no response to a failed or successful Sprint
- Team morale is very low
- Items from the Sprint Backlog get carried over to the next Sprint without question: why not? There’s always a next Sprint and the iterations are artificial anyway!
- Symptom #4: No drive to improve
- no joy, and certainly no drive/desire for improvement
- nobody really seems to care
- The Product Owner is hardly ever present during the Sprint Review or the Sprint Planning
- Teams are highly unstable, as members continuously get loaned out to other teams in need of their (specialized) skills
- no actual Scrum Master present to help the team grow
- lack of control a team experience over their own success
- boring retrospectives, a lot of complaining (moaning)
- The Causes of Zombie Scrum
- Cause #1: A bit too homegrown, or ‘Cargo Cult Scrum’
- teams and organizations that start working with Scrum without the help of (expensive) external trainers and coaches. NOTE: Some of the best Scrum Teams started out like this
- Scrum can be a bit too home-grown
- a team decides that they’re doing Scrum because they have a bi-weekly ‘Daily Scrum’
- a team adjusts the sprint length based on needs to be done (instead of the other way)
- This partial adoption of Scrum is often unintentional
- Cause #2: No Urgency
- usually caused by a lack of urgency in the rest of the organization
- One of the potential causes is no real understanding of value
- If working software is the beating heart of Scrum, then value is its lifeblood
- Due to the fogginess regarding value, often have a hard time coming up with clear goals: Without goals there’s simply no reason for urgency
- shared goals are the glue for any team and provide them with purpose and motivation
- Cause #3: Competing Values
- result of a systemic mismatch with Agile values
- people in the organization hold beliefs about software development that collide with what drives Agile software development. Examples
- considers the purpose of Scrum a process that must be followed (Instead of understanding that Scrum allows us to ‘fail fast’)
- considers working software a nice-to-have (In healthy Scrum working software is essential; even if we don’t go live at the end of a sprint, we learn most from it)
- sense of urgency (There’s always a next sprint. Sprints are artificial time-boxes. In healthy Scrum teams, a sprint is the longest allowed period between feedback opportunities)
- Cause #4: Scrum Cherry Picking
- might seem the same as "cargo cult Scrum". The difference however is that with Scrum cherry picking the partial adoption of Scrum is done on deliberately
- Scrum by the book too difficult. too much pain within the organization. changes were “necessary”
- Cause #5: Contracts Implying "We Don't Trust You!"
- value-driven organization also embraces value-driven contracts
- have a foundation build on transparency and trust
- stimulates effective partnerships and invites collaboration
- supports adapting new insights and processing gained knowledge
- encourages acting on necessary changes and lessons learned
- only contains the necessary agreements and constraints
- embraces the Agile mindset
- In reality however, agreeing upon an Agile, value-driven contract is difficult
- When the customer has a great idea, enthusiasm is high and possibilities are endless. We only have to agree upon the contract…
- The difficulty with contracts is that it’s all about trust
- If there’s enough mutual trust, setting up a contract won’t be too difficult
- often the customer and supplier haven’t worked together before
- The customer wants guarantees around budget, time, quality and scope
- A decent change control process is lacking
- After some tough negotiations the DT starts but doesn’t truly collaborate with the customer, just mechanically building what’s written in outdated requirements
- the result, a suboptimal product
- Cause #6: The Smell of the Place
- huge impact on the behavior of employees
- examples
- Constraint versus Stretch
- Compliance versus Discipline
- Control versus Support
- Contract versus Trust
- Project versus Product
- Planning versus Prognoses
- Commitment versus Forecast
- Resources versus People
- Treating Zombie Scrum
- Treatment #1: Become a Zombie-whisperer
- simply talking to them may work wonders. Zombie Scrum Teams are rarely happy with their predicament
- talk about their situation, and identify potential causes and solutions
- talk about values and beliefs, and educate on the purposes of Scrum and the underlying values
- Treatment #2: Introduce Healthy Scrum into the population
- introducing people into the population that can show and explain how Healthy Scrum works, and communicate the right values
- Take teams and management on a Scrum-safari
- bring in Agile coaches to help teams and management understand Scrum better
- Treatment #3: Shake things up (don’t continue the stumble)
- Treatment #4: Involve the broader Scrum Community
- Treatment #5: Dare to Embrace Agile Contracting Principles
- Treatment #6: Setup a Smell-o-Meter