Smashing zombies, making the play real
A toolbox to detect, expose and address Agile dysfunctions known as “Agile Theater” and “Zombie Agile”
Delivered by Zombinators @ Scrum Coaching Retreat, Kiev 2017
Amir Peled, Andrey Kozyrenko, Yury Lytvynenko, Lina Shishkina, Yevhen Moroz, Illia Riabtsev
Setting the Stage
Meet Oleg. He’s an Agile Coach in his mid-thirties and his coaching career started 4 years ago. He’s been in the software industry for a while where he got some hands-on agile experience. He collaborated in healthy agile teams in addition to helping coaching struggling agile teams to health and increase their performance.
He signed up with a company Grave Solutions Inc. of 40-something people to help to address them their problem.
Half a year ago the company’s executives got excited about Agile and benefits it’s about to bring. So they ran an Agile Transformation Initiative. But as the time passed, it started to look like Agile does not deliver. At a first glance, everything is OK. All the rituals are in place, post-its are on the walls, backlogs are refined, retrospectives bring action items that are implemented. Well, kinda. Some teams bent some rules. Others go by the book to the letter.
Productivity went up a little bit, but it’s light years from “doing twice the work in half the time”. Employees engagement haven’t changed at all, and for some, it even went down.
They hope Oleg will be able to help them.
What’s the Problem?
From his experience, Oleg knows that when a company does not receive all the benefits promised by Agile transformation, there are two typical dysfunctions. One of them can be called “Agile Theater”, another one – “Zombie Agile”
Various reasons can lead to these dysfunctions. “Everyone’s doing agile, we must do it too”, top-down “you must be agile” message, enforced competition to be the most agile team within the company – it all sets the stage for the “Agile Theater” to emerge.
Lack of safe environment and understanding; using Agile as an excuse; teams feeling powerless to make a meaningful change – these factors produce Zombies.
Both Theater and Zombies can be caused by change initiatives that failed in the past. People don’t feel safe about yet another one, hence they’re either start playing the system or turn into brain-dead executors.
In the remainder of the article, we dive into a detailed definition of both dysfunctions and explore ways to detect, expose and address them.
Root Cause Analysis
People are doing the best job they can in alignment with their abilities and knowledge. Thus, rather than blaming and finger pointing people, we should challenge the way they work and they need to focus on defining the problems, identifying their main causes and fixing the processes instead, especially when situations are repeated such as in our case. You can do Root Cause Analysis (RCA) whenever a mistake or a problem pops-up and during retrospectives.
A popular technique is called the 5 Whys where people work in pairs or small groups. They first need to agree on what went wrong, rather a particular event than a generic one, followed by asking “Why did it happen?”. For each cause revealed, a short discussion will follow, the cause will be written down and the same question repeats for a total of five times. Asking “why” 5 times will help you to gain more valuable insights than asking why just once.
Another visual tool is a fishbone diagram, where the problem is written at its head and the contributing factors that are causing the problem, possibly grouped into categories (where applicable), are written as the bones. This tool often accompanies the aforementioned 5 whys.
Lastly, by understanding the whole system and finding opportunities for improvement, system thinking can be applied using Causal Loop Diagrams (CLD) with the aim to have a conversation. Variables, causal links as well as opposite effects should be sketched, followed by a discussion about beliefs and delays which should be captured as well. The output is meant for shared understanding.
Meet and Greet Zombies and Actors
You’ll see that they are keeping the status quo since they have nothing to improve.
They are convinced that Agile will not work for them and disguise in a rabbitfish. Consequently, they keep parts of their previous process unchanged. They have boring meetings and would like to continue with them. One of their favorite games is the blaming game: all you need to do is to find a victim and finger point. They utilize two sophisticated frameworks: KDD (KPI-Driven Development) and the latest RDD (Report Driven Development). They favor extreme timeboxing: either having none or exceeding the time limit.
Introducing Agile theater
Promising starring actors such as junior SM, Proxy PO, Chief SM, etc. tick all checkboxes, indicating that they are truly agile. They are into playing their roles without really caring about value. They suffer from cargo cult and will fake it till they make it.
Detecting a Zombie Outbreak
- Retrospectives have no action items at all or all action items are on the poor SM
- Action items are moving to the next retrospective and never being done
- Naturally, many conflicts and blaming arise during retrospectives
- Retrospectives will never be at the process level
- Sprint is a small waterfall dedicated per each SDLC phase
- Overcomplicated DoR which is being used as a contract
- Does not happen without the SM
- Daily is rather for status report
- Issues are not discovered
- None exist
- Not updated / outdated
- Updated by the same person, usually the SM
- Sprints for development, testing, staging
How Do You Know You’re in a Theater
- All action points are from left down square of impact/efforts diagram
So there are always actions with the least efforts and the least impact
- Retro points are always predefined by someone external or by scrum-master
Planning: The team plans just by velocity – “Velocity driven planning”
- They are not happening without SM
- Or the is no focus on the sprint goals – just on tasks
- 100% tasks are always “done” and closed. The team is focused not on delivering real value but on closing tasks. DoD is faked
- No feedback
- Only checklist
- Team is telling stories how they are awesome and nothing about what was really done
Visual artifacts: not up to date, or updated, but show nothing relevant, or vanity metrics.
Smash Zombies, Blow Up the Theater
The first thing you want to do is to expose the problem you’ve identified.
Then, there are two routes based on whether you are dealing with the Agile Theater or Zombie Agile. Both of them lead to addressing root causes though.
In addition, it makes sense to influence executives to achieve the most impact.
“Houston, we have a problem.” Does it sound familiar? Yet how do we know what the problem is and whether one actually exists? For more details on this topic, please consult “What’s the Problem” section.
Now that we have the problem statement clearly defined, it is time to expose it and make it readily available to anyone. Our preferred way is where the communication bandwidth reaches its maximum coverage, i.e., face-to-face, ideally with a flipchart or whiteboard available for illustration purposes with some visual cues. During the conversation, you need to reveal what the problem is, why is that a problem, and determine any positive signs for things that are working well, as you are hoping to capitalize on them and spread them further across the infected teams and the organization.
Next, you need to explain how do you expect the zombie to behave and act. This is crucial, as you embrace on a journey to model his/her behavior. Typically, you should run an experiment where the focus is on one critical behavior that you would like to change and provide feedback along the way. To do that, you must make it clear where is the zombie heading to, i.e., what is the right destination and why does it worth the effort to ride on that path. Rather than uninspiring metrics which may lead to poor destinations and eventually even to Agile Theatre, focus on the anticipated positive outcomes. There are many games available online to help you achieve that; try tastycupcakes.org, for instance.
Dealing With Zombies
Find The Least Dead One
Trust is essential and the foundation of self-organizing agile teams. Individuals on the team must learn to truly rely on each other for help and take joint responsibility for their work. Such statements as “His part was not finished, I did my part of the work” where you failed to deliver the anticipated outcomes together as a team and play the blame game just do not work. Trust helps to bond the team members and create a cohesive unit in addition to the sense of inclusiveness. No hidden agenda, no manipulation, no politics, no fear of admitting weaknesses. Instead, being open and honest about problems once they arise or partially done work, ask for help, provide timely and constructive feedback, and show empathy about your stakeholder’s goals.
A good starting point is to find the least dead zombie, openly accepting his/her particular expertise and personality as a foundation for building a trustful relationship. Try to connect at the personal level and determine what are the expectations from you, in addition to sharing what do you expect from him/her and the rest of the team. You need any help you can get and the least dead zombie is a great candidate to becoming an organizational change agent!
There are several exercises the least dead zombie could try are:
- Five Personal Questions – get to know each other on a personal level by answering 5 questions and sharing the most interesting points with the rest of the group
- 360 Stories – tell stories from a distant past, from the present or somewhere in between and go very deep by sharing emotional events
- Fast Pass – allows people to connect to each other by finding some commonalities based on questions indicated on flipcharts
- Scenario Cards – what would you do if…?
- Treasure Hunt – people introduce themselves to each other and discover one thing they have in common and one thing which they differ on
Build Communities of Practice
Learning is fundamental for accelerating professional development across the organization. In order to benefit from each other’s experience, shared practices and knowledge across various teams, build and improve capability in addition to reducing duplication of work and isolation, like-minded people come together and organise on voluntary basis, rather than management’s request, Communities of Practice (CoP) around technologies (e.g., Java) and common interests (e.g., ScrumMaster).
CoP will thrive through the organization if management creates an environment where it is highly encouraged to form communities and meet regularly, where communities are visible and everyone knows about them, how to join and is expected to join. Lastly, management should understand that some communities will fade away at one point or another when there is no more passion or there are some prevailing dysfunctionalities. Anyone can start a community – you do not need a mandate for that. The group of volunteers are passionate about specific topics and intend to address them via interaction with each other to deepen their knowledge on the subject of interest or functional practice. Ultimately, communities will produce something which the teams decide to adopt. Consequently, a broad participation from all the teams is strongly encouraged.
For further details on CoP, please refer to the CoP Cookbook.
Dealing with a Theater
Help Identify the Real Value for Agility
The Agile Manifesto might be a little bit outdated and two movements attempt to go back to basics and simplify. For example, getting back to the heart of agile (kokoro) which implies just mastering the basics, can be described in four simple actions:
These four words are truly simple and usually do not need much explanation or teaching as they are understood by most people. Basically, you know whether you are doing those actions or not! However, when we expand the heart to get to modern agile development, we realize that the Shu-Ha-Ri concept applies to all of them and we need to improve the following:
- Trust, motivation and the act of collaboration itself
- Delivery for learning and income in addition to delivering incrementally, early and often
- Gather sensible, subjective information about the team and the process vs. gathering objective information, using data analytics about the product and how well it is received by the users and buyers
- Change and run experiments
Some powerful questions you can try are:
- How will you increase collaboration?
- How will you increase trial and actual deliveries to consumers?
- How will you get people to pause and reflect on what is happening to and around them?
- What experiments will your people do at different levels in the organization to make a small improvement?
The main advantage of those questions is the focus on attitude and behavior to work on, which is what we want to address directly.
Another movement, the Modern Agile, provides with guiding principles which serve as an expansion to the Agile Manifesto and go beyond SW development:
- Make people awesome
- Make safety a prerequisite
- Experiment and learn rapidly
- Deliver value continuously
If you feel teaching is necessary, you can do it by facilitating some games which simulate a given situation. Many are available online.
Remove Competition for Agility
To make people awesome, stop evaluating individuals using a scoring system. Is a person who is evaluated as 5 stars inherently better than one with 3 stars „only”? Or perhaps a score of 1 is better than 2+? These numbers have no value. People get upset when they think they should have scored more and being perceived as average can really irritate and hurt. Even worst, the scoring system is frequently supported by a reward system, meaning, the higher your score, the greater your bonus in monetary terms is. Things can get even worse if you know that you should get a bonus for exceptional performance only to find out that there no more funds left or you receive just a small portion of the initially promised bonus. Lastly, based on your performance, it will determine whether you will be promoted or not in addition to other career development benefits.
Scoring systems also enforce rock stars within teams, who are often being perceived as superiors and tend to solve problems alone instead of collaborating together with the rest of the team. Sometimes, they think they know it all and create a huge mess, since they did not consult anybody. Lastly, creating a dependency on a rock star will hit the team back once that person will not be available for a while, for whatever reason (sickness, leaves to another organization, etc.). Balance the team’s skills and explore how team members can pull tasks outside of their expertise area to reach the team’s full potential. The Silos Game is a nice start.
We need to understand that people are not motivated by money alone. We do work for autonomy, mastery, and purpose. Also, our main focus should be on giving and receiving constructive feedback, one-on-one, as we are looking for opportunities to learning and improvement culture. People who are not doing well do so not because they are bad people; they are probably doing the wrong job. Talk to them and find out what activities do they enjoy and discover how can they do that. Try playing Moving Motivators, e.g., and the results might surprise you.
Lastly, is competition between teams a good idea? Competition between teams does not improve performance as each one have their unique environment and different challenges. The unwanted end result may be that team members will try to protect themselves, using CYA (Cover Your Ass) approach since they are not allowed to fail – they will suffer the consequences, no learning opportunities will be allowed and consequently, lack of collaboration will be present.
It is very common that executives try to lead when they should be following or getting out of the way instead. Such a scenario will hurt the agile adoption and trust is fundamental also when we would like to influence senior leadership team. You need to build a personal rapport with them, being credible based on past positive results and recommendations and ultimately you need to understand the goals of the organization and link how agile can serve as means of meeting their business challenges. Once trust is built, confidential information will be shared with you in addition to spending more time with you and asking for your ideas.
Executives should at a high level do the following:
- Set the vision of the agile adoption, with clear boundaries and constraints
- Obtain support and remove impediments
- Ensure openness through constructive, prompt and regular feedback loops as well as foster trust
- Hold teams accountable
To influence Leadership teams, drive the conversation on a particular challenge the organization is facing, and ultimately move them towards action, the Influencing Poker can be played with them. For further details on how to use the tool including some recommended applications, please refer to the link.