Agile anti-patterns seen in the field

Introduction

Over the years I have lead and worked in numerous teams that have successfully delivered projects using Agile software development methodologies because the critical success factors were present. Most of us know what is required for Agile software development to succeed but on the other hand, when things don’t work out we typically need a scapegoat reason in the form of an anti-pattern.

From Wikipedia: In software engineering, an anti-pattern (or antipattern) is a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice.

Some convenient Agile anti-patterns are listed below.

The invisible Product Owner

They seek him here, they seek him there. If your product owner or product owner proxy isn’t present at the daily standup, sprint planning meetings or the showcase then chances are you not going to meet their expectations and will end up delivering the wrong thing. Demand that your product owner is present, and if they won’t commit, find someone who can stand in for them and make decisions on their behalf.

Field of Dreams (no core value proposition)

Build it and they will come. What point is there in creating a product that nobody wants? If your customers are external, find a market looking for a product rather than creating a product looking for a market. A product owner with intimate knowledge of your business domain and an eye for emerging trends is essential.

ScrumBut

How many times have you heard, “we’re using scrum but…”? If your team is only using parts of the Scrum process then you’re probably doing so because there is an issue that your team is trying to work around. If you are the ScrumMaster, then expose the dysfunction and work at addressing it with the support of the team and product owner.

Customer Driven Development (CDD)

We’ve all heard of BDD, TDD, and FDD but what about CDD? If you are enslaved to CDD whereby the customer is completely in the driving seat then you risk building a product that contains trivial features which compromise the architectural integrity and maintainability of your product. Don’t throw common sense out the window by blindly saying yes to everything that your customer asks for. Push back when the need arises.

Everything including the Kitchen Sink

This is a variation of CDD and the Field of Dreams that results in a product that contains every conceivable feature imaginable of which only 20% of functionality is actually used (think: MS Word). Such products are difficult to refactor, mediocre across a number of areas, and impossible for customers to comprehend. If you have a list of eighty features on your product backlog, focus on a minimum viable product by choosing thirty of them and take your product to market. If you don’t, you will end up like your competitors who are bogged down in a five-year death march on a dead-end technology platform.

Conclusion

Agile anti-patterns are typically the result of an elephant in the room not being dealt with. Tame the elephant.