By Jimmie Butler
Jimmie Butler is a Program Director at IntelliBridge.
Scrum is 30 years old. The Agile Manifesto is 22 years old. One might think by now we’d have this Agile stuff figured out. Some do but, the reality is, most organizations are still struggling with Agile whether they know it or not. It’s understandable. There are many reasons why we struggle. Let’s unpack it.
In this article, we’ll highlight a few of the bigger struggles we see – the big rocks. The smaller the detail, the more specific we get into process, the more divisive and unproductive the conversation can be. Without a doubt, there’s more than one way to live out Agile day-to-day and we can miss the forest for the trees in those discussions. Here, we’ll shed some light on some common challenges your organization may still be struggling with.
1. Over-Reliance on Frameworks
Frameworks have a purpose. Some support Agile values and principles better than others. Frameworks, however, are not the answer to all your organizational problems. Some frameworks may not even be fit for purpose for the type of work you do.
Your goal should be to continuously get better at discovering and delivering the next right thing, sooner. Any way you find to achieve that is good. Organizations that prescribe frameworks and get stuck on following ceremonies miss the point. What you do matters, but why you do it matters more.
Be flexible and do what works in context for your circumstances, which will change over time – a change your framework may not support well. A strong Agile coach is usually needed to help guide the organization in practical ways. Frameworks can help. Mixing and matching frameworks can sometimes help more. In the end, be pragmatic about what you do, and most importantly, why you do it.
2. Lack of Strategic Alignment and Planning
Many organizations are getting good at pivoting and deploying frequently and calling that Agile. Planning and strategic alignment is often lost amidst all the change. That was never the intent.
Agile is about getting better at discovering and delivering the next right thing. Pivoting is part of that. But the next right thing is always aligned with product strategy and organizational objectives. That’s what gives it its value – the impact it will make on strategic imperatives.
Value-Driven
Everyone talks about delivering value. How you define value may vary. Value is commonly defined as delivering what was asked for or by how much gets done each iteration – making the customer happy. The organization may even assign business value points to each story so they can report out on how many value points were delivered. There is value in making your customer happy, but it’s a deceptive definition of value. You can deliver what the customer asks for and never impact your strategic measures.
Value isn’t in what you do. Value is in what is achieved as a result of what you do.
You should assess the potential value of work to be done. That’s how you prioritize. Business value points may be the most pragmatic way to estimate that. Real value, however, can only be known post-deployment. In other words, what is achieved as a result of what was done. Most organizations are not measuring that. Is what you’re doing expected to influence your strategic measures and, when done, how much did it influence those measures?
Theory of Diminishing Returns
A feature can always be improved. There will never be a shortage of new tweaks you can make. Done can be a moving target. There comes a point when continuing to iterate on a feature has diminishing returns for the effort.
The Product Owner must understand what’s good enough for now and how to prioritize the team’s focus. In the desire to get it perfect, ongoing feature tweaks can sometimes be prioritized over starting new work because the definition of value is skewed. For each new idea, it must be assessed against existing backlog ideas and placed in order of value – value to the business outcomes, what you hope will be achieved as a result of doing the thing. There will come a point when the value of the extra tweak will no longer be more valuable than starting the next feature.
3. Lack of Empiricism
Empiricism is the theory that all knowledge is derived from sense-experience.
I don’t have enough fingers and toes to count how many times a customer provided detailed requirements, those requirements were delivered perfectly, and then they or the users didn’t like what was delivered or it didn’t meet the need. Why does that happen? People generally don’t know what they want or need until they have an opportunity to experience it – they need to see it, touch it, use it.
We don’t really know what we want and need in detail until we have something to experience. This is why it’s so important to build in short learning cycles. We need to do something, users need to experience it, we need to learn from that experience, and adjust. That’s why Agile exists – to find our way to the best solutions.
Feature Factory Mentality
Getting more done in less time is still desirable, and understandably so. The Lean movement helped us to define and optimize value streams and remove waste – all so we could improve flow and maximize outputs. That’s a good thing.
Many teams today operate like factories. They are well-oiled machines taking detailed requirements through to production like clockwork. New idea after new idea comes in and goes out. Teams optimize every process to get more done. Sounds great, right? But that’s not what Agile is for. Agile is for finding your way to the right solutions. Feature factories assume the requirements are correct and it’s just a matter of coding and deploying, and then moving on. There’s no empiricism in feature factories.
Far too often, organizations are more focused on burning through the backlog than measuring what was achieved (or not) as a result of what was delivered, and then adjusting.
Requirements Mentality
“Requirements” sounds so definitive, so right, so required. If you deliver requirements that don’t meet the need as anticipated, can we really say those were “required”? This assumes the teams even follow up to see if what they delivered had the desired impact on outcomes.
What if instead you worked from assumptions? Well-founded, data-driven assumptions that reduce your risk, sure, but assumptions all the same. And what do you need to do with assumptions? Test them to see if they are true or false. Validate or invalidate them. Can you see how your mindset will shift working from assumptions rather than requirements?
It means you stop trying to define every little detail up front. It’s futile to think you’ll get it all right up front. Start with the end goal in mind, quickly get something in front of users, get feedback, and iterate based on that feedback. Your goal is to shorten the learning cycle so that you arrive at better solutions rather than focusing on getting more done in less time.
3.5. Lack of Discovery
Product Owners, subject matter experts, and other team members can assume they know what’s needed and proceed without proper validation of the problem or without testing ideas and user experiences (UX) with real users before plowing ahead.
As users of software, surely what we like and don’t like is what others like and don’t like, right? Not true. We can allow our biases to lead us to believe that we know what to do and how it should be done. Studies show, however, that our ideas fail to meet the desired outcomes 2/3’s of the time.
Since the solution you propose is supposed to solve a problem, you first need to make sure you’re solving the right problem. Then you should test out your ideas in low-fidelity ways to make sure you’re headed down the right path. This is not work you can fit into the same sprint you’ll develop within. It requires a separate track from development where you refine the problem and solution space.
Only validated ideas should move forward into the product backlog. From there, your amazing capability to develop and deploy quickly can get those changes into real users hands for post-deployment validation.
Conclusion
Agile is much simpler than many make it out to be. Your software products exist for a reason – to help support a business objective. You build new products and features to solve problems and close the gaps between where you are today and where you want to be. That planning supports your strategic objectives. You humbly accept that your biases may not be correct, so you validate problems and solution ideas in discovery. Those ideas that promise to move the needle the most are the most valuable and get prioritized. You improve your confidence in those solutions through empiricism – testing assumptions through data, product use, and getting feedback. You find ways to deliver validated ideas as quickly as possible so that value is realized, and you can learn from its post-deployment experience whether you hit the mark or need to iterate. Do, experience, learn, and adjust. Many organizations often forget to learn and adjust.