5 Agile Problems Solved

I was involved with my first agile project in the early 2000s. A colleague persuaded me and my team to adopt Extreme Programming. I have subsequently been responsible for many agile teams, all with lots of enthusiasm and knowledge of agile methodologies, yet we still encountered difficulties.

In this post, I will go through the main problems these teams encountered, and what we did to address them. Without further ado, here are the top 5 problems we encountered:

1. User Stories Too Large To Fit Into a Sprint

Most of the teams that I led struggled with this issue. We would get a requirement that wouldn’t fit into a sprint, and break that down into features. And then we would run into a quandary; on the one hand, we could not fit the majority of these features into a single sprint; on the other hand, if we broke down the features further, we would not deliver something meaningful to the users. Eventually, we decided to break down features, even if the resulting story was a technical story.

Why did we decide this? The underlying reason why agile works is because each sprint reduces risk:

• Delivering functionality to users early reduces the risk of changing or incorrectly interpreted requirements
• Building, testing, and deploying code iteratively reduces the integration risk

Whilst we couldn’t do the former, we could do the latter by deploying code to production every sprint, disabling it via config if needed.

2. Team Is Too Large

Many sources recommend the maximum scrum size as being 7 people. Jeff Bezos has the 2 pizza rule: if a team cannot be fed with 2 pizzas, then it is too large. The problems with large scrum teams are:

• Everyone gets really bored at standups
• Bigger teams encourage less individual accountability – known as social loafing
• Team members begin to feel more isolated and less supported as team sizes grow – psyschologists call this relational loss
• Communication overhead. The number of lines of communication grows exponentially with team size

3. No Upfront Architecture or Roadmap

One of my teams was tasked with improving the performance of a system. We understood at a high level how we would do it, and we planned what we needed to do in a single meeting, created an epic, and broke it down into smaller stories. After a couple of sprints, we didn’t feel as if we were making progress, the stories in later sprints were now wrong, and we had started to run without any clear goal or plan. So we stopped, and the team spent a sprint writing a design document. After this, we were able to write stories with a lot more confidence, and we delivered all the stories and the overall epic on time.

Some time later, I was asked to help out another team. They were committed to agile, had a good grasp of the technology, but had unhappy customers. The customers explained that they didn’t understand how long their requests would take, and didn’t even know when they had been implemented. The problem was that the team broke a request down into sprint sized stories, and only reported on these lower level stories. We addressed this by creating a roadmap showing when requests would be delivered. Whilst the delivery dates were only accurate to within a month, the customers were happy.

If you are using Jira to manage your backlog, I highly recommend the Jira hierarchy plugin. The highest level we used is themes, followed by epics, then stories, features, and finally tasks. If this doesn’t work for you, the plugin lets you choose however many levels you want.

4. Not Obtaining User Feedback

Teams will do standups, poker planning sessions, work in sprints, and do burn down charts. But once the novelty of a new project or way of working has worn off, giving and getting feedback after a sprint often gets dropped. Without feedback, there is no de-risking, defeating the purpose of agile. I have found that getting key users and customers into a room with the entire team at the end of each sprint to see a demo works very well. It makes the customers feel that you care, and makes you feel that the customers care.

5. Not Updating Storyboard During Stand-up

One team I worked with managed user stories in Jira. Because our meeting room didn’t have a computer, updates to JIRA were done after the meeting, which resulted in the Storyboard having incorrect updates and the team feeling that standups were onerous. To address this, we decided to use cards and a physical Scrum board. The feeling of using something physical really energised us, it felt as if we were doing something fun.

And there you have it. None of this is earth-shattering, but if you do come across one of these problems, I hope that my suggestion can help you.