Let’s face it: agile conquered the world of software development. Often, though, I find people are dissatisfied with the results, and in this article, I want to point out a few common things that folks struggle with and what you can do to get some of the results that Agile or Scrum promised.
Estimation and Predictability
The biggest cause of heartburn I see is how teams plan, estimate, and then deliver work within an expected planning window. This isn’t a new problem, just that when folks move to Scrum, there’s an implied expectation that all the fuss around velocity will make things easier and predictable.
I hate to break it to you, but story points, estimation, and velocity are different ways of failing at the same problem.
So let’s stop beating that dead horse for a moment and talk about other ways to look at this problem that keep the spirit of agility intact while also helping answer that age-old question, “When will it be done?”
If we look at any team, and it doesn’t matter how they estimate and plan, we often see a few patterns emerge. We’re looking for the number of work items they complete each sprint cycle. This number tends to converge around a fairly tight range for teams. That’s the number we’ll begin to use going forward.
A fictional team tends to complete 3-5 things each sprint. Want to know when they will finish some work? Count down the backlog and divide that number by the amount they get done. The result is a better, though still imperfect, number of sprints it will take the team to get to that work.
There’s a better version of this, using Monte Carlo simulations, which any PMP should be able to set up for you, but I’m not explaining how to do that within this article.
Equipped with a different yet simple way to say how many sprints for work to finish does wonders for relieving stress and building up trust while also drastically cutting down on the number of conversations around velocity.
Improvement
Folks hate Scrum for how many meetings it has. I get it. I’d hate it if I had to sit through all those often poorly facilitated meetings.
The reason for those meetings is to create a series of feedback loops that the team can use to improve.
If you’re not seeing much improvement with your agile teams, your meetings suck.
Let me break it down this way. The Daily Scrum provides feedback on each day and can be an excellent 15 minutes. The Retrospective provides feedback on the process, team, and product. The Sprint Review provides feedback on the team and product.
All of that feedback, when gathered, can provide deep insight that leads to improvement. If the meetings suck, though, it all falls apart.
I recommend finding a skilled facilitator for these meetings to get teams to improve more rapidly. This facilitator probably isn’t the current coach or Scrum Master. Focus on the Sprint Review and Sprint Retrospective first. They provide the sharpest feedback and mechanism for improvements.
Agility
Okay, this is the obvious one here, but the big promise of agility is the ability to make more impactful decisions rapidly. This is possible by keeping feedback cycles short and having explicit decisions built in.
We improve processes during Retrospectives. We adjust the product in planning and review. We adjust development during planning and Daily Scrum, etc.
Now, while most of us love how adaptable we become if we go agile, we rarely take advantage of this new capability. We still think and work on large chunks of work instead of small ones. Those large chunks take so long the feedback and decisions are dampened.
So, what can we do? The idea is fairly simple, though it takes a fair bit of adjustment. We want to move away from looking at things as a single large chunk like an MVP or roadmap milestone and instead look to much smaller ones within it.
Let me give an example—a company focusing on an MVP. Everyone is looking at the chunk of the entire MVP. That’s one lens that would only provide feedback after months of work. So we make many smaller chunks out of that MVP now. Examples could be that we have some customer feedback on the onboarding process, that customers find the design intuitive, that we have an early commitment from customers to buy, or that we’ve been able to do a safe deployment to prod. Each of these smaller chunks is about getting feedback on the work we’ve done and not so much about how many items we completed.
Chunking for smaller feedback cycles on outcomes is what allows feedback and decisions. If you only look at chunks as scope, the only feedback is if it’s done or not. If you chunk along smaller outcomes like customer delight during onboarding, your feedback is touches scope, design, development, etc., and you have many more decisions available.
These smaller chunks may only sometimes be relevant to senior leadership who look at things on longer horizons. Still, they will appreciate the updates and see things moving well and risks managed. Also, if you’re going to miss a date, the conversation gets a lot easier when they trust that you’ve made many smaller bets very well instead of betting it all on the one big MVP at risk.
So there you go, three things that organizations everywhere struggle with after they adopt Scrum or some other agile framework. Agility isn’t broken, nor is Scrum. The hiccup is that many folks haven’t realized all of the advantages, and small shifts in existing behaviors and perceptions will help everyone realize those advantages instead of suffering buyer’s remorse.
Top comments (0)