This is the last post out of the series of these three articles on agile antipatterns based on David Tanzer’s book “Quick Glance At: Agile Anti-Patterns”. You may want to read the first and second article first, before you deep dive into this third one.
Unfortunately, it’s very common to see Agile implementations made of a very strict schedule of meetings and a rigid formulation of roles and responsibilities. This leads to a misunderstanding of what Agile methods can bring to a team or even to the whole organization, eventually becoming a worsened relationship between individuals and teams. Let’s go through it bit by bit, said Jack the Ripper.
First, let’s focus on the team level, where interactions between members of the same team happen. These are, usually, long-term relationships and that’s why empathy and trust are so important. The easiest way to have both is working together with explicit agreements and common goals, priorities and incentives (not only economic rewards). This is easy to say but not that easy to implement because organizations sometimes are very difficult to change, and inertia is everywhere: “we have always done it this way”.
Retrospectives are a good moment to improve these agreements and to identify those impediments that need to be escalated. It’s a good practice to run retrospectives frequently so that you can avoid those situations that can become entrenched or rotten.
Usually, good starting points for those agreements are an artefact (a taskboard) to show all the tasks that the team has agreed to work on, and your team’s Definition of Ready (DoR) and Definition of Done (DoD), i.e. the checklists that every task needs to fill before and after you work on them.
Another common source of conflicts at the team level is manual tasks that eventually lead to mistakes, delays, misunderstandings… Consider automating as many tasks as you can.
And always pursue a healthy culture of feedback and collaboration between individuals. We usually avoid conflicts because we are afraid of facing them, because of a lack of skills. This is a good investment because we can transform conflicts into something beneficial for the whole company.
Second, let’s focus on a coordination level, where interactions happen between teams. Actually, interactions always happen between individuals, but at this level, they act as proxies of their teams and it requires a clear definition of their roles and responsibilities.
Frameworks like Scrum work well at the team level, and many solutions to escalating it have been proposed.
You can have a look at Less, SAFe, Nexus, etc, but I have found the most productive by reading this short book by Klaus Leopold titled “Rethinking Agile” which introduces the concept of “Three Flight Levels”.
I’m not going to explain the Three flight levels concept here, but this coordination level is made of processes and roles connecting the operational level (the teams) with the strategic level (the goals). This is where the confusion occurs usually.
Combining urgencies, capacities, business value, etc is pretty difficult, but it’s almost the same problem that every team has. This is why one of the first recommendation is to create work agreements (i.e. a clear workflow, DoD, DoR, etc) and have an artefact (a board) to show the status of all the work you need to coordinate, with a special focus on the impediments that the teams can’t solve by themselves.
Agile proposes to decentralize these decisions as much as you can, having autonomous and cross-functional teams, and reducing the dependencies that are causing most of the blocks and delays. I like how the Agile manifesto states:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Third, at a strategy level, we can set goals that give focus to everyone in the company, to avoid having a coordinator. Think about a flock of birds. They don’t need a leader to do their emigration journey to the south every year. They have easy rules to follow and a clear goal. Of course, in a human structure, this is way more difficult because we also have politics. But this is another story.
A whale in the sky (Starling roost at Otmoor UK ) photo by James Wainstcoat
I would suggest exploring OKR as a framework to set goals and cascade them to the rest of your organization and create an environment that fosters autonomy and collaboration, without creating silos. This will reduce many conflicts, but you must reinforce that autonomy comes with responsibility. If you are a manager, you should delegate as much as your teams may accept. I like this delegation poker practice from Management 3.0. And don’t forget that you can also reorganize differently. In a previous post, I mentioned the book “Team Topologies”. It’s a short read but well worth it.
Nevertheless, remember that conflicts are not necessarily bad. They are good sources to learn if we make an effort to use them and extend our threshold of knowledge.
A short story on how many Agile transformation cases begin:
«You attend a conference, read a book, chat with a friend, etc, who explains all those benefits of being Agile. Then you convince your manager to start this journey. You both talk to some top manager who accepts taking part of the budget to run a pilot with a scout team, maybe two. You attend some training and even have a coach to guide your steps. The experiment, run in laboratory conditions, gives excellent feedback.
Everyone’s so happy with the results that top managers decide to expand the pilot to the whole company and communicate that “Agile is the way”. You feel very supported. But now you are out of the lab and have to deal with dependencies, impediments, delays, bad practices, changing priorities… You feel tempted to go back to your laboratory, but you know that’s not the solution because then you would be creating a silo.
You look for help to spread your new Agile practices everywhere. Eventually, you find a consultant that comes with something. “Hey! This is what we need!”, and you start applying that medicine to the whole company, regardless of their peculiarities. New roles, new meetings, new tools to report the progress… Everyone’s excited and confused. After a while, you find pitfalls in the way everyone’s trying to do Agile. You trained them and gave a clear framework, but they are doing something very different. I know, it’s frustrating. You ask for feedback and they explain that the framework is not what they need, and request some changes.
You think “Well, Agile means that I must adapt to the feedback” so you accept their requests. Some weeks later you receive more feedback and, again, you modify the original framework. This loop happens recurrently and one day you find yourself asking “How the hell did we end up here?”.»
Don’t feel guilty if you have experienced this. Many of us have been there too. The friction of practicing Agile out of the laboratory is a signal to change the environment, not to change your Agile framework, which was designed as a proven set of practices for some ideal conditions. Of course, we must adapt to the real conditions of our environment, but if we want the benefits of Agile we must change our organization so that doing Agile is possible, not the other way around.
It’s also very common to find organizations that change the frameworks before receiving any feedback. Deciding upfront which are the actual changes that we need to make is also a mistake. Same as trying to use a framework that worked for another company. My reco here is to stick to the principles. You can change the practices, but not the principles. Read the Agile manifesto for those.
In the previous antipattern, I described a very common situation: companies using a framework because someone else said it worked for them. This is also an antipattern by itself. Let me explain this idea further.
It’s very common to find companies replicating the so-called “Spotify model”: tribes, squads, etc. Many of these companies force their organigram to fit in this model, naming squads teams like “the front-end team” or tribes departments like “the Sales tribe”.
I don’t recommend this practice, and the problem is not the “Spotify model”. These companies didn’t fully understand why Spotify arrived at that model at one point in its life, which actually it’s not its current model now. This same example applies to those who use Scrum, Kanban, SAFe, OKR, Jira, TDD, Kubernetes, or whatever tool or practice, like a silver bullet.
We shouldn’t blindly repeat practices just because they worked somewhere or because their context seems similar to ours. Every group of people is a social system, which is a kind of complex adaptive system, and one of their most relevant properties is unpredictability.
This antipattern exposes that we require a more experimental mode of management, being open to running experiments and letting emerge the right practices for our organization, which necessarily involves tolerating failures. (Remember what we just said about conflicts).
Instead of forcing the use of a tool, a framework, or even a technical practice, you can run small experiments, ask for everyone’s feedback, and change accordingly, respecting the Agile principles. I’ll give one more example.
Not everyone needs Scrum to be Agile. Usually, Kanban works better for support teams that are closer to giving a service than to create a product. Scrum is much better for teams that work in increments of a product, based on the received feedback from users. If some of your teams interact with the others like a service, i.e. they give answers to their received requests. They are not working in increments, their work is kind of standardized and looks like their requesters expect some sort of SLA (service level agreement). It would be a good idea to explore the use of the Kanban method for those teams.
I’m pretty sure that you have your own examples of practices that have been copied-and-pasted into your organization. Please, give a comment below.
A corollary for this series of antipatterns could be that learning must be a deliberate practice: a discipline like Peter Senge explains in “The Fifth Discipline”. Understanding that your organization can’t be changed from one day to the next, you can make small experiments, maybe some “nudges” to the organization, share the learnings and run another experiment in a continuous learning loop.
I’m sure you can find more situations that correspond to these antipatterns. Please, share in the comments so we can learn from each other in this community. Thanks for reading.