Agile Failures: 3 Common Missteps That Kill Transformations – Part 1
Remember when you were in school and you were taught something – math, say – and you learned a way of solving problems. Then, for the homework, you had to do things weren’t part of what you learned? Remember how frustrating that was? How we struggled to understand how to take what we’d learned and apply it to a different problem? That’s pretty much what I see with common agile failures. We learn the “book” way of doing things and then suddenly we’re asked to do something that’s not as straightforward as we learned it. And that’s what I want to tackle in this post.
Misstep #1: The Process
I’ve been reading a lot recently about people complaining that “Scrum failed them”.
- “We were more focused on sprints than on our product”.
- “I’m too busy writing stories to communicate what we’re building.”
- “The team is more focused on story points than on value.”
These are just a sample of the complaints I see on a regular basis about Scrum in particular and agile in general. If these are your part of your agile failures, your problem really isn’t your process. Some of the issues here are the “book learned” behaviors I mentioned above. When we start doing something new, we start with what we know. How much flexibility we have to improvise is based on our culture and our confidence in our abilities.
I mentioned this elsewhere, but we (the agile community) do a huge disservice to our newly-minted Scrum Masters. They attend a two-day class to understand the basics of the Scrum process and then we expect that they can become change agents and coaches in their organizations. That’s setting them up to fail.
These Scrum Masters are those students who just learned the basic way to solve the problem. They don’t have the experience and the deeper understanding to really be able to effect change. As a result, they tend to overemphasize the book way of doing things. “No stories over 8 points.” “All sprints are two weeks long.” “Stories need to be in this format.” Those are indicative of an inexperienced Scrum Master.
How Do We Solve This?
Instead, the issue here is that agile is designed to focus the team’s efforts on delivering small chunks of customer value in short time frames (about two weeks). If your process isn’t supporting that, you’re doing it wrong. The focus is on value, not on points. It’s on the customer, not user stories. Points and stories are the mechanisms by which we plan the work, but they aren’t the goal.
Bringing in a coach or someone who has some deeper experience and some authority (either inherent in their role or delegated from management) can help get these group back on track. It helps when someone has an understanding of the common challenges and has experienced some of these agile failures on their own. They can provide guidance on how to navigate the uncertain waters your organization is traversing. The big caveat I’d offer here is not to focus on just those people who have a specific industry experience. If you’re in finance, it would be nice to have a coach with financial experience, but these kinds of challenges are across all industries, highly-regulated and not, large or small. Some problems are easier to solve with fewer restrictions, but you’re working to deliver value. That’s the ultimate goal of the process.
Closing Thoughts
This is one of the most common agile failures I see because it sours people to how to work. They see agile or Scrum as having a huge amount of overhead that they need to manage. That’s not true. We need to change our behaviors and how we work. It can be a radical shift, but the goal is to get working software into customers’ hands faster. If your process isn’t doing that, you’re doing your process wrong. And if you need help with that, let us know and we’ll get you on the right track.
Happy coaching, my friends!