Mastering Agility: Steering Clear of the Gluttony Trap in Agile and Scrum 🌟
In the Agile realm, ‘gluttony’ extends beyond mere overconsumption. It’s a metaphor for the excessive accumulation of backlogs and products, often paralysing the agility of teams.
Introduction: The Perils of Gluttony in Agile Teams 🚫
This blog delves into how Agile teams can avoid falling into this common pitfall.
The Pitfall of an Overloaded Product Backlog 📚✨
Consequences of a Bloated Backlog: A crowded product backlog can lead to confusion, decreased focus, and hindered agility. The presence of too many items can obscure the team’s vision of what’s truly important.
The Art of Prioritisation: Regularly grooming the backlog is more than a mere task; it’s an essential strategy. It involves evaluating and prioritising tasks to ensure that the team’s efforts align with the organisation’s most pressing goals.
The Clear Path Forward: By maintaining a carefully curated backlog, teams can navigate their work with clarity and purpose, boosting both productivity and morale.
Sprint Planning: Balancing Ambition with Realism 🏃♂️🎯
The Trap of Overcommitment: Overloading a Sprint with tasks beyond the team’s capacity is a common error. This often leads to unfinished work spilling over into subsequent Sprints, creating a domino effect of inefficiency.
Striking the Right Balance: Successful Sprint planning lies in setting attainable goals. A well-planned Sprint with realistic targets can lead to consistent, high-quality outputs, fostering a sense of achievement and motivation within the team.
Streamlining the Product: A Lean Approach 🛠️💡
The Weight of Unused Features: An overcrowded product with seldom-used features can significantly impede a team’s progress. It’s not just about the quantity of features but their impact and usage.
Embracing a Lean Mindset: Conducting frequent reviews of the product features to assess their usage and impact is crucial. Discarding what’s unnecessary simplifies the product, making it more agile and responsive.
Benefits of a Streamlined Product: A product free from superfluous features is more than just efficient. It becomes a focused tool that aligns closely with the users’ needs and enhances the overall value delivered.
Opting for Value Over Volume in Agile 🔑🚀
The key to avoiding gluttony in Agile and Scrum is recognising that more isn’t always better. It’s about choosing tasks and features that offer real value. A lean approach to backlogs, realistic Sprint planning, and a streamlined product set the stage for a more agile, effective team. Remember, success in Agile is measured not by the quantity but by the quality and relevance of what you deliver.
Takeaways: Agile Practices for Avoiding Overindulgence 📝
Regular Backlog Grooming: Keep it focused and prioritised for clarity and direction.
Realistic Sprint Goals: Ensure goals are achievable to maintain quality and team morale.
Feature Audits: Regularly assess and remove features that don’t add value.
Embrace Value Delivery: Ensure every feature and task adds real value.
Leverage Feedback: Use insights from customers and team members to guide decisions.
One of the seven deadly sins of Agile is gluttony, and I see this a lot in teams where their backlogs and their products become bloated. Bloated and full of basically just full of crap that needs to go. One common entry is the product backlog. If you go into a team, you’re working with a team, and you go to look at their product backlog and there’s, let’s say, six or seven people working on this team and they have 5,000 things in their product backlog, they’re doing it wrong. Right there, that’s greedy. They’ve eaten all those backlog items; they’re sitting in their belly and they can’t walk around, they can’t move. They’re not going to be nimble, right? They’re not going to be Agile because it’s almost impossible to understand what is our value, what value is in our product backlog. Diving into that thing is just not a good idea. You’ve got too much stuff in your product backlog.
Another way gluttony manifests is during Sprint planning, right? Shoving more stuff into the Sprint backlog than the team can possibly deliver in a single Sprint, and that continually results in the team having to vomit backlog items into the next Sprint. If you think of it that way, perhaps teams will stop doing it. Taking on too much and then it spews into the next Sprint. If it’s one or two things that move into the next Sprint, maybe not every Sprint is probably okay, right? You’re not going to be successful in everything you do, but if you’re constantly got tons of things from a Sprint flowing into the next Sprint, flowing into the next Sprint, perhaps there’s a need to consider, are we taking on too much work? Are we doing too much? Are we taking on too much work?
So that’s the second form of gluttony that I see in teams. The third form is leaving stuff that nobody uses in your product. This Standish Group in Boston used to create the Chaos Report every year, and they analysed about 70,000 projects worldwide, and they found that only 35% of the features that we build are used by our customers. Sixty-five percent, I think the phrase was “used little if ever.” So hopefully, we can stop building them in the first place, right? That would be great. Let’s stop building them in the first place. But if we have built them, why are you keeping them in your product? Why are you continuing to spend maintenance hours on support? How long does your build take? How long would your build take if you removed 65% of the code that’s in your product? Because you’ve got rid of those features, your build would be faster. Your teams would be able to work faster. There’s a less complicated body of content. You’ll just get better and faster at doing things.
So the way to… ah, man, loads of teams just need a gastric bypass for that, right? How do you restrict the amount of stuff that’s in a product? That’s really hard because that’s much harder than backlog or Sprint backlog, right? It’s to figure out what percentage of the features of your product are actually used. The worst is continuing to invest in features that are of no use, right? Features that aren’t used by your customer because I guarantee you loads of teams do that. Years ago, I worked with a bank in Boston, and they were absolutely adamant that this 65% was crap and that they knew their customers way, way better than anybody else, and there’s no way they were wasting 65%. It was a lot less, that’s what they said.
So we said to them, “What’s your flagship product that you build? What’s the product that you think you know your customers best and are building all the awesome features?” Like, “This one, this one’s the best.” So we got in amongst the code, we added application insights. Application insights is an Azure feature that can be plugged into any application anywhere, which basically collects data. It supports all the programming languages, all the setups, and out of the box, it does a bunch of stuff. But then if you add this as a feature, you can say, “How many times do users click that button of our body of users? How many of them have clicked that button?” You can get all of that data.
We analysed their product end to end. We collected data for three months, and then we went back to them and said, “Here’s the 7.5% of features that your customers use. All the rest was waste.” Over 90% of the money they invested in their product was waste. What was really interesting was that more than 80% of the items in their backlog at the moment were going towards additional capabilities for features that weren’t used by their customers.
So, no, don’t eat the whole thing, right? You’ve got to figure out how do I pick and choose what I’m going to eat? Don’t eat the whole feature at once, right? You don’t know if you like haggis yet, so don’t order a whole plate full. Get like a starter that’s got a little bit of haggis and try that first. Then, obviously, when you realise you do like it and your customers like it, then you can make more, right? But don’t overeat on your product backlog. Don’t overeat in your Sprint backlog, and don’t overeat in the features in your product.
Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.
