I was recently asked about anti-patterns that may damage a software development team that is using XP, Scrum, Kanban or any other Agile method. One of the best references I have found that summarizes this topic is the book “Quick Glance At: Agile Anti-Patterns” by David Tanzer, but I also have something to add. Keep reading.
Book Quick Glance at Agile Anti-patterns by David Tanzer
This book is a nice collection of antipatterns, i.e. what we should avoid, but the author uses a very useful structure for each of them. He begins listing some signs that you may observe in your environment, then an explanation of how it may cause trouble; the main usual causes; how it usually begins to happen, and finally some advice on how to avoid it. I’m not going to reproduce this structure because you already have the book, but I’ll go through the list of antipatterns to give you some examples along with my experience.
Antipattern #1: Agile Theater
When organizations pretend to be “agile”, but mostly still work as in a traditional company.
If you join a company when the Agile adoption is already in place, you may have some expectations (maybe someone created those expectations for you) and presume that everyone is practicing a 100%-pure Agile (if such a thing can exist). Of course we can anticipate that everyone receives good training, the right tools and the right context before starting with Agile. It would be great, but reality is not that easy. Don’t get frustrated. It’s perfectly normal because everyone needs to start with something that is not perfect and because not everyone in the company can develop at the same pace.
Please, don’t get me wrong. I’m not advocating to act with complacency, but with some indulgence. The lines can be fuzzy and depend a lot on the context. I’ll give you an example.
Some years ago I worked as an Agile consultant for one of the main banks in Spain. My team was in charge of designing and implementing a new process to manage the project portfolio. A portfolio is a collection of projects and programs that are managed as a group to achieve strategic objectives.
Projects dependencies graph
This is a graph that we created in order to help us understand the dependencies between all those projects (and the teams working on them). More than one hundred projects were involved, many of them were managed by people with very little or no experience in Agile, and the diversity of projects was very high. For example, we had to deal with software development projects with five or six teams doing a pretty decent Scrum, but they had to coordinate their backlogs with other teams that had zero knowledge of Scrum, Kanban or anything close to Agile. We also had projects that actually didn’t need Agile because they were just doing the follow-up of the renovation of some offices: something very predictable.
Our contribution was to help the portfolio managers to prioritize all those projects every quarter, assigning the budget according to those priorities and confirming the outcomes that they were bringing at the end of the quarter. You may think that there is no Agile in this particular scenario, but if you compare the previous process then you realize that the bank was way more Agile than before. Now they are able to adapt their priorities every 3 months, while they had to wait 1 year or longer with the old process.
Of course there was still a lot of work to be done, especially in organizing the teams so that they could be more autonomous and able to develop projects with fewer dependencies. But that’s a longer story. 
Antipattern #2: Feature Factory
When “Agile” is only seen as a way to increase efficiency.
In the previous antipattern, we had a good example of Feature Factory. Many teams were just developing what someone asked them to do —no ownership at all. They were managed pretending to be predictable as if they were a factory. However, knowledge at work is not easy to manage. We usually must deal with a lot of uncertainty and that’s where Agile comes into play.
I’ve worked in many different places where this mindset was set within most of the teams and it’s absurdly toxic. Everyone was so focused on measuring, in order to increase efficiency, that they were imposing policies that forced them to work in much harder and inefficient manner. “If you can’t measure it, you can’t improve it”, they said, but this is actually wrong because what we measure is only a partial representation of our reality. There are many important processes in an organization that we are aware of but we can’t measure, and also other important details that we are simply unaware of. Data-driven improvement is good, but don’t miss the forest for the trees and make sure you understand the impact of the changes you make.
The most productive change you can do to avoid this antipattern is providing the team with enough information and autonomy so that they can write user stories, i.e. work items focused on user needs. You can write them using this classical template “As [a user persona], I want [to perform this action] so that [I can accomplish this goal]”. User personas are archetypes representing our users so that we can empathize with their needs and ideate functionalities for realistic scenarios of usage. This practice is a game changer because everyone starts working on satisfying user needs that eventually can be checked with those personas… even measuring their effectiveness and the impact on our business.
Antipattern #3: Product Backlog Bankruptcy
When your backlog becomes so big that it is unmanageable, causing delays and other problems.
Imagine you are managing a small bakery. You store the ingredients and the half-baked products on your shelves. Everything that it’s not in the customer’s hands is an incomplete product, and potentially will expire, causing a loss. Even what is on the shop counter, ready for sale. Now, translate this metaphor into the reality of your daily work. Every PBI (product backlog item), feature, user story… that you have in your backlog is an incomplete product. The ones in progress are not finished either. Even those items that have already been tested and integrated may cause a loss while they are not delivered to the users.
To insist on doing more refinements and adding more items to our backlog is not a good idea if you are not delivering at least at the same rate. CFDs (Cumulative Flow Diagrams) are a good way to identify these situations.
Cumulative Flow Diagram demo
A great tip to avoid this antipattern is limiting the amount of work you have in each column of your Kanban board. This is what we call the WIP limit in the Kanban method. If you are really committed to do a good Kanban, you should also combine this with pulling work, i.e. moving work from one column to the next only when there is capacity so we don’t overcome the WIP limit.
These two techniques together will increase the amount of work finished for a given period. This is mathematically supported by Little’s law and is in the essence of the Kanban method. This law states that:
L = 𝜆⋅W
where L = average number of items in our system, 𝜆 = the rate of arrival of new items, and W = average time for an item in the system.
This means that, for the same arrival rate, the more items we allow in our system, the longer it will take to deliver them. In short, the more work in progress, the slower you’ll deliver. A good corollary for this is: stop starting, start finishing.
If you follow Scrum methodology, this also applies to you. The more work you have in your sprint, the more opportunities for being interrupted, losing focus, having to wait for another task that becomes more urgent, etc. The larger your backlog, the longer it takes for those items to be delivered, so that you will eventually need to manage the expectations of your stakeholders.
All these issues may be prevented by planning with an iterative and incremental approach, which allows you to work on small increments of the product. That also has the beneficial side effect of giving the opportunity to change priorities more easily as we always have a functional product, small but functional.
Having shorter sprints (1 week) will also help to speed up the feedback loop; induce everyone to work on smaller stories and learn that we can postpone many of our ideas until we have real feedback from our users, leading to a more efficient usage of our efforts.
There are 6 more antipatterns in David Tanzer’s book. If you want me to continue this series, please show your support by clicking on the “like” button and writing your comments below.
