8 Agile antipatterns and how to deal with them

But there is a huge difference between “being Agile” (living and breathing the core values and principles) and “doing Agile” (following some formal prescriptions, but not having the right mindset). Quite often a team might look Agile on the surface, but be in fact very waterfall-isn and not efficient. In this article I would like to cover some common antipatterns and ways to identify and deal with them.

This is a common problem that occurs when new teams (especially in large organizations) switch to Agile. They start doing the sprints, but the scope of each sprint is decided in advance and is not flexible.

Why is it a problem?

With no wiggle room for the planning, the team looses its ability to test hypothesis, learn from experiments and adapt to the changing environment. You experience all the disadvantages of waterfall and add Agile ceremonies on top of it, which causes nothing but frustration.

What can you do?

Switch the approach to planning - it is important to have the big picture in mind, but you need to accept that you don’t know everything about your product and customers yet and your approach will have to change as you learn more and more. Do a roadmap planning, but focus on the big picture and product outcomes, rather than deliverables of every sprint.

I encountered this in one Japanese company and they were quite proud of what they claimed was their unique framework. In fact, it exists in many forms and variations, and is never a good thing to do.

The idea is that there are a few teams working on the same product in parallel, following a sprint cadence. One team does design, another does development (or you could have frontend, backend and QA teams for example). In sprint 5 Design team develops new designs, while Frontend builds on designs from sprint 4, Backend works with Frontend code from sprint 4 (which was designed in sprint 3) and QA checks the outputs of dev teams from sprint 4 (which were designed in sprint 2!)

Why is it a problem?

Everything here is wrong. I hope you can see from the example, that it takes at least 4 sprints to deliver a final product (given that each work item needs to go through Design, Frontend, Backend and QA). There is no room for experimentation - with so many teams involved who would be running experiments? None of the teams takes the ownership over the final product (designers can always say that their designs were misinterpreted, while engineers would argue their code was perfect but the product doesn’t work well because of the poor design. This is a very bad approach and it has nothing to do with Agile.

What can you do?

Set up cross-functional teams with end-to-end product ownership. You might need to split the product vertically - for example make one team responsible for product search, and another - for shopping cart, but you will need to make sure each team can deliver value on their own, experiment and move fast.

I sometimes meet Agile coaches and Scrum Master who would go on for hours about “the only right way” of doing something. Let me break the news to you - there is never only one right way of doing things in Agile. We need to be Agile about Agile - experiment, learn from failure, inspect and adjust.

Why is it a problem?

Sometimes even the best of the best practices in Agile don’t work in certain contexts. The product is unique, the team has a rare problem, the working style is unconventional - there are many possible reasons to that. If you are obsessed with Scrum and don’t accept anything else, you keep reinforcing the process that don’t work. The team becomes demotivated, the productivity goes down, business results get worse and worse and the whole organization suffers.

What can you do?

Retrospectives. Do retrospectives, have an open and frank discussion about things that work and that don’t and explore the ways to alter your existing processes. Of course, it is always good to follow best practices, but don’t get over-fixated on them - try new solutions and see what works best for your team

I hear it often: “We follow Kanban framework because we have a kanban board”. Nah, you don’t. You follow Kanban framework if you have a board AND you limit your work in progress items, measure cycle time, pull work instead of pushing it and apply continuous improvement best practices to your daily work.

Why is it a problem?

You can do waterfall with a kanban board, it doesn’t make you Agile. A properly implemented Kanban framework helps you to apply the essential principles and mindsets of Agile. You ensure the end-to end ownership (people care about the overall progress rather than only their own section of work), you ensure incremental product development by moving independent work items through the workflow. Finally, you achieve continuous improvement.

What can you do?

Learn about Kanban framework and remember that a board is not enough

A lot of organizations, especially during the transition period keep the “team manager” role or combine it with the role of Product Owner. Can teams with a team manager be Agile? I have seen a couple of okay-ish cases, but more often it is a recipe for disaster.

Why is it a problem?

If there is a formal authority figure present in team, everyone will be relying on them for making decisions and telling the team what do. Of course, a great manager knows when to step back and might be able to create psychological safety, but more commonly team members would be hesitant to share their opinions or questions the priorities.

What can you do?

This is a tricky one, because it requires organizational changes which are not always easy to implement. The ideal that we want to achieve is a cross-functional team with no managers (Product Owner is not a manager!) that makes decisions about goals and works together towards achieving those goals. If org change is impossible, training the formal managers on servant leadership approach might be helpful.

Coming from traditional project management, time-based estimates (man-hours, man-days etc) are still used quite often and in most cases prevent the teams from unleashing their full Agile potential

Why is it a problem?

Time based estimates require you to have all the work pre-assigned (which often causes silos) and take a lot of time while causing more problems than they deliver value. How do you evaluate uncertainty? Add 3 extra days to the estimate and pray for the best? How would you estimate a piece of work that requires someone to work for 1 hour per day for 15 days - is it 15 hours or 15 days? If you put 15 hours, you risk ending up with a wrong timeline, but if you put 15 days you will be overestimating resources needed.

What can you do?

Identify whether you need any kind of work estimation at all to begin with. Quite often you don’t - if your backlog items are more or less similar in size, just estimate your velocity with number of items team completes per week, then make future projections using this information. Otherwise explore t-shirt sizes and story points estimation; time-based estimation should be your last resort.

In a lot of cases that would happen because someone else (usually leadership) set the goals up for them. It also happens when teams follow inertia, doing what they have always done. In this case they might do planning (what we want to get done), but not the goal setting (where do we want to get and why)

Why is it a problem?

If the team doesn’t set the goals, it also means that they don’t own their product performance and are not committed to the product success. This is a big problem.

What can you do?

Start with a vision. Do a workshop where the team will identify target customers, their needs and problems and would decide what they want to do to address those problems, and what would make them unique. Then translate this vision into a roadmap and a set of objectives and key results. Finally, review the backlog to make sure the work items there are aligned with the vision and the OKRs.

This is my pet peeve and a very common thing in Japan. People get measured by how much they have worked (working hours, number of code lines written, number of powerpoint pages created etc), but not by the outcome. In a lot of Japanese companies it is hard to get promoted if you are in the office only 9-5 and don’t do overtime. At the same time, if you stroll through a typical Japanese office at 9pm, you would see people sleeping at their desks, chatting, scanning a faxed Excel spreadsheet to insert it into a Word document and send that by fax (true story) or realigning boxes on the same ppt page for the 15th time in the last 2 hours. Don’t get me wrong, there are of course people doing real work and normally all the employees are working hard. It’s just that the focus is not on solving the problems and achieving business outcomes, but on “working hard” and “working a lot”

Why is it a problem?

I hope I don’t need to explain this one. If you are judged based on the number of hours you worked, you will be incentivized to find the most inefficient and the most time consuming solutions. If your focus is on solving the problem, you would be incentivized to get it done efficiently (so that you get to spend time with your family and also get a nice bonus)

What can you do?

Never ever set output-based goals (e.g. launch x number of campaigns, complete x story points or write x lines of code). All your goals should be outcome-orientated (e.g. increase sales by x %, achieve NPS of x points or achieve SLA of 99%)