3 common agile anti-patterns and how to avoid them
P Chandan Arun Prakash, Engineering manager, MiQ
The ideas presented in the agile manifesto are great but when it comes to real-world practices, we tend to create our own variations of agile to suit our needs. This creates a mini waterfall model which is the very model we were trying to part ways with.
Let’s explore three anti-patterns to be aware of while transitioning from waterfall to agile software development and what to do to keep these anti-patterns at bay.
- Breaking epics into frontend and backend development components
One of the main goals of agile methodology is to deliver working software every sprint so that our customers can start using it. A working software is one which has both frontend and backend working together and meets all acceptance criteria.
More often than not, breaking epics into front-end and back-end leads to development teams picking either front-end or back-end activities in a given sprint. Even if they manage to complete either of these in a sprint, it cannot be deployed in production and therefore cannot be called working software.
This causes us to break the first principle of agile: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
Our solution:
At MiQ, we’ve started breaking epics into multiple user stories. Each user story has a set of tasks — back-end and front-end — and associated non-functional requirements. In a given sprint, teams commit to delivering some user stories from the backlog. The number of user stories a team can take depends on its strengths, weaknesses, dynamics and size, as well as the size of the story.
We’ve also started using the INVEST model to assess the quality of user stories:
- Independent (of all others)
- Negotiable (not a specific contract for features)
- Valuable (or vertical)
- Estimable (to a good approximation)
- Small (so as to fit within an iteration)
- Testable (in principle, even if there isn’t a test for it yet)
Before incorporating INVEST, we did not follow any model. However, our stories were not always small enough for functionality to be completed, while keeping quality parameters intact. This led to bugs leaking to the production environment. INVEST ensures we evaluate each user story along these six parameters and hence has improved our estimation of stories and quality of deliverables.
2. Non-functional requirements as an afterthought
Non-functional requirements (NFRs) specify performance, stability, availability, security, software usage and more.
On occasion, we’ve seen that NFRs are ignored during initial conversations with clients or during requirement elicitation by product owners to teams. Or, clients will explicitly talk about functionality with no mention of NFRs, but an implied assumption that both will be present upon delivery.
This can be problematic. This behavior can turn habitual for PMs and development teams, suddenly becoming an issue when systems break down. Embarrassment aside, this can severely damage an organisation’s reputation. Also, by not working on NFRs during sprint development, we create technical debt which is costly to organisations.
Sprint output: a working software which includes functional use cases, performance, security, stability, availability and all other mutually agreed upon criteria.
Our solution:
Sometimes clients are unsure of the scalability, availability or performance they require. At MiQ, we reinforced that it is the responsibility of product owners and pre-sales teams to question clients appropriately to create the right set of NFRs. And that it’s on product owners and development teams to discuss and delegate NFRs during backlog grooming. Sharing a standard Definition of Ready with every team involved and making sure this was understood, has meant that we’ve been able to capture NFR requirements on more user stories than before.
3. Ignoring velocity and story point estimation
Team velocity is the average amount of work a team can complete in one development cycle. This is an essential metric for product owners and development teams to understand before agreeing delivery dates.
Over-committing leads to burn out under the pressure of delivery and under-committing prevents us from realizing our full potential.
During estimation, we sometimes (wrongly) start with no base story in mind. In story point estimation, each team member gives a number based on how complex they find the story. With no understanding of the base story, it can be difficult to associate a complexity number to a story.
Like velocity, understanding team dynamics is critical for accurate estimation. A new joiner, for instance, might find a given story extremely complex while a seasoned senior engineer might find the same feature of low complexity. The team is supposed to debate and arrive at a consensus on a practical story point number for a given story. Failure to do so invariably leads to spill over.
Our solution:
At MiQ, we’ve come up with a few ways to ensure velocity and estimation are never disregarded. First, if dev teams feel their current velocity is sub-par their potential, they can methodically run plans to bump it up to the extent it is practically feasible. Secondly, we capture three team-level reports per sprint: velocity graph, burndown chart and scope creep. During every retrospective, we review these reports to evaluate our performance and scope of improvement. Then we identify a concrete action plan intended to bring improvements in these areas such as reducing story points per person, grooming meetings at least four weeks prior etc.
It’s important to be aware of these anti-patterns and learn how to recognise and resolve them to make the most of agile methodologies. Even at MiQ, we’re constantly striving to recognise and reduce anti-patterns. We aim to be truly agile so we are always working to ensure agile principles become part of our culture.
Chandan is an engineering manager at MiQ, based in our Bangalore office. Passionate about cars, he enjoys hill walking in his spare time.
