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.
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.
Agile anti-patterns are typically the result of an elephant in the room not being dealt with. Tame the elephant.
After considerable effort and numerous late nights using limited spare time I have completed development of NZQuake and deployed a beta version of the application to production. NZQuake was built to satisfy an urge for learning a new full-stack application framework – Grails – and act as a technology proof of concept for future projects.
The application presents earthquake related information in a clear and concise manner by combining QuakeML with Google Maps. It is primarily informative and, as a resident of Christchurch, New Zealand, has provided me with a creative output for dealing with the stresses of living through a series of unprecedented earthquakes and aftershocks which began with the magnitude 7.1 earthquake on September 4th in 2010, shortly followed by the deadly magnitude 6.3 earthquake on February 22nd 2011.
The learnings taken from this project will be documented in a series of posts looking at the various technologies in the application stack.