Agile is the industry-standard software development methodology, but there are lots of subtle pitfalls for businesses that aren’t constantly optimising themselves and settling for mediocrity. I’ve seen the same mistakes time and again across various industries. It’s time to fix these mistakes permanently.
Over my career in business analysis and product management, I’ve seen massive improvements in how we deliver software. When I started in the late 90s, we used to spend weeks, if not months, writing requirements specification documents. Inevitably the developers would deliver the finished product months later, often after the business had pivoted to other priorities. This led to constant arguments inside teams and with our stakeholders.
Agile was a breath of fresh air when it arrived in the industry and has massively increased productivity and quality. It means there are far fewer defensive behaviors within software development teams. People focus on doing the right thing. When you compare the software that we were delivering 15 years ago with what we’re delivering now, there’s really no comparison. Part of this is due to improvements like UX and DevOps and Test-Driven Development. But don’t underestimate how dysfunctional our ways of working were before Agile.
One thing I’m disappointed about though, is that I’m still seeing the same mistakes again and again in the industry 10+ years after Agile was adopted by nearly everyone.
Agile is an approach and mindset rather than a prescriptive set of steps.
When Agile was first introduced to waterfall teams, it had to be explained clearly to reluctant, skeptical old-timers. Scrum was the development methodology that everybody was taught. This was because Scrum came as a cookie-cutter set of practices and ceremonies. In retrospect, a lot of the things that Scrum recommends aren’t useful once a team is mature and experienced. 10+ years later nearly every development team is mature, yet we’re still adhering to the same dogmatic practices, simply because everybody expects them. Scrum is basically Agile on training wheels. Kanban was a deliberate attempt to dispense with a lot of the rigidity of Scrum, but bad habits die hard.
A couple of quick disclaimers:
- I’m not seeing these problems everywhere in the industry and I’m not aiming these general comments at any specific projects I have worked on.
- I expect a few of you will disagree vehemently with these “mistakes” and that’s fine. They may very well be appropriate for you and your projects. (Like the rule about not putting punctuation at the end of list bullets).
The following mistakes are far too common and aren’t obvious until you’ve learned the hard way:
1. Technical tasks are fine
The original Agile requirements books all laid down the law that teams must not work on anything that does not directly go towards developing user-facing requirements. This is fine as a general rule. The problem is that it is really hard to adhere to in practice for infrastructure set up work. If you try to stick to it too tightly, it becomes unclear when developers are working on technical infrastructure instead of a user-facing feature. One of the main points of a Kanban board is that you are making it clear what is being worked on and this defeats that.
Since I have started writing technical stories, my interactions with developers are much easier and more natural. SAFe has come to terms with this and uses the concept of “enabler stories”. I prefer plain language and call them technical tasks.
2. User stories do not replace requirements spec documents
It’s a temptation when reviewing a backlog to equate the length of a story with the quality of a story. I’ve seen bloated user story templates with all sorts of headings for all sorts of things that you might want to throw into a story occasionally. The problem is this leads to requirements gathering becoming a turgid checklist exercise, with confusing stories that take forever to write and review.
It’s much more important to think of stories as a conversation between developers and product owners. Provide a clear definition of what needs to be delivered inside a list of acceptance criteria. Then talk to the developers, updating the user story as everyone’s understanding improves.
Templates like As a, I want to, So that are a crutch and shouldn’t be mandatory. If the “As a” or “So that” statements are unclear or obvious, leave them out. This is far better than the typical “As a Developer” user stories that we commonly see.
Similarly, I’m a big fan of BDD acceptance criteria (Given, When, Then) but really only in conjunction with an automated testing framework like Cucumber or when you’re dealing with precise outputs. BDD acceptance criteria should never be mandatory.
3. Never ever use estimates to beat up developers
This one is obvious, but it still happens a lot.
Estimates are essential to producing timelines of when a feature will be ready, to prioritise features accordingly and set expectations with stakeholders.
The problem is that software estimates are notoriously difficult and very frequently wrong. All developers estimate differently and it’s very hard to get any kind of consistency at all. If you use them against developers afterward, they will start overestimating and it can poison your most valuable relationships, so treat old estimates sensitively.
I have seen developers so traumatised by this that they argue that all estimation is bad and refuse to supply them. I have had to drop estimation on projects, but we lost a valuable tool.
User story points are a powerful tool for defusing the politics of estimation, but it’s better to base them in reality, for example, one story point roughly equals one man day, otherwise you lose consistency. T-shirt sizing is OK, but it’s an unnecessary abstraction.
On a contract a few years ago, I used an Agile project management tool called Pivotal Tracker that estimated a team’s velocity automatically over time. It would only let you add stories to a sprint if they could be delivered. It was hard to keep velocity consistent as people left and joined the team, but over time it became a powerful way of seeing when we were going to finish features for the business. Some people hated the rigidity of Pivotal Tracker, but it was really useful overall.
4. Recurring meetings lead to poor-quality ceremonies
In order to get teams collaborating they need to get together to communicate and it’s important we have a set of regular, core ceremonies to facilitate this. The main mistake I’m encountering is that we have too many calls and quality gets low. This has always been a problem, but became worse post-COVID with remote working as it is harder to get everyone into a room on the spur of the moment. It’s too easy to drive calls based on the recurring appointments in your calendar, not from the need for a call.
Retrospectives are essential, but doing them every two weeks is too often in a mature team. It would be great to see Scrum masters hold more ad-hoc retrospectives, for example once a milestone is reached, or to delay them based on the quality of discussion of the last retrospective.
Requirements elaboration meetings are often scheduled every two weeks, but they are better done ad hoc. I would much rather sit down with a tech lead for an hour to plan. Then I can go back and write the requirements in detail myself and play them back to the team in a sprint planning meeting instead. The alternative of writing the requirements with the entire team gets boring for the developers and is inefficient. It’s unrealistic to expect all the analysis to be complete after one 2 hour call every sprint.
Sprint reviews are a useful way to get feedback from time-starved stakeholders, but it is too easy to do a poor job if there is nothing substantive to show yet. It’s much better to hold a review meeting once you have delivered something you can make a performance out of. Showing stakeholders bug fixes or technical infrastructure is not going to get useful feedback. It will ultimately lead to stakeholders skipping the calls to do their day jobs. Recording videos with tools like Loom, or even the screen recording in Slack, are a great way to get early feedback because you can prepare the performance beforehand – avoiding common pitfalls like bad static data that make an otherwise solid product look flakier than it really is.
Want to know more?
This list shows that there are lots of ways that experienced teams can cripple their velocity just by sticking with common industry practices. We can come up with many more examples. Our consultants have deep experience of Agile over many years across all sorts of industries. If you feel there’s room for improvement in your organisation’s software development, get in touch.
