Adapt vs Adopt — Agile is about adapting
In the early days of Agile, we were all just trying to figure out what would work, experimenting and exploring how we could help our organization become more ‘agile’ by asking ourselves if what we were doing was agile, and if it wasn’t what would it take to become more agile. We took to heart the statement — We are finding new ways of developing software.
We were focused on how we could deliver high-quality solutions that would bring value to our customers and do so in predictable and transparent ways of working. I remember those early years as a Project Manager who turned Scrum Master, I was struck by how much more I knew about the projects we were working on. One thing I had to adapt our agile approaches to was our need to still provide a project plan. Instead of creating a waterfall project with associated tasks, assigned to people with expected dates I instead created a shell project plan with the expected sprints identified in 2-week increments but the content of the sprint for the project plan would not be populated until the team committed to the work. This project had stalled in our waterfall ways and when we moved to Agile and Scrum, we delivered a new product that generated revenue quickly, that is the power of agility and adapting our ‘agile’ to the organization.
Agile over the years has moved from people learning how to adapt Agile to their organization to one that is almost exclusively centered on adopting one of a myriad of Agile frameworks that are sold to organizations seeking to become ‘agile;’.
It’s not that these frameworks don’t have both good intentions and foundational elements your organization can utilize, they are not however something that can be blindly implemented as your sole effort to make your organization ‘agile’. The frameworks provide structure for their interpretation of what they believe will make you agile. They all have missing pieces or have so much structure that they require you to change your organization to become the framework, which makes no sense at all.
To have long-term success with building agility, you need to focus on the intent of the frameworks and then adapt your organization to achieve the outcomes the framework seeks to achieve. For example, if the intent in Scrum is to get your teams effectively planning every couple of weeks, then you need to adapt your organization’s planning capability to ensure that teams have valuable work to plan and execute every couple of weeks. The problem with this is that most organizations are highly resistant to changing their planning and funding approaches and coupled with not having an effective way to strategically plan for outcomes your teams focus on outputs, not outcomes because those have not been defined. You are going faster nowhere.
As you embark on an agility transformation, you need to first assess how your company is operating and identify the areas of strengths and weaknesses that you all know exist but are typically unwilling to publicly admit to. Once you have this assessment completed, then you will need to define for your people exactly what you expect to be the outcome of ‘going agile’. Why? Because people need to change the way they work to rethink and adapt to more agile ways of working? Without the why don’t expect much success. And too often organizations skip this heavy lifting and move right to implementing a framework that is only concerned with itself. All the frameworks have specific operational expectations that frankly rarely align with how your business operates.
Another key aspect of the successful agile organizations I’ve worked for is that we were allowed the freedom to explore how to work in a more agile way. What you will find if they are allowed, people will talk to each other and when we see how things are working well for a team, we may want to incorporate what they are doing into how we are working. Allow this to happen organically and what you will find is that the processes and standards required to make your organization more agile will be driven by the people doing the work, not from a framework and a cadre of coaches who tell you to do it the way the framework says to, which is ultimately not how the frameworks should operate, they are frameworks for reason and should be allowed to be open to interpretation, remember to understand their intent and focus on the outcomes that will deliver value.
Adapt your way to more value and improved productivity and quality over adopting frameworks alone.
