Start Your Agile Transformation with a Framework
by Patrick Delany
I recently found myself in an agile coaching engagement that was “agile agnostic”. This means that there is no overarching agile framework guiding or shaping the transformation. Rather teams and areas within the company are free to pick and choose the agile practices and structures as they see fit from a wide range of frameworks such as Scrum, SAFe®, Agile@Scale, Spotify, and many more.
In theory, this sounds wonderful. We get to pull the best of each framework and create the right one to fit our team, business unit and particular business context. In practice, it is an unmitigated disaster.
Think about it this way. Rather than going to the car dealer and selecting from one of the makes or models of a car that best fits your needs, you decide to build your own car with parts from a Ford, Toyota, Tesla, Fiat and BMW. Remember, you have never built a car before nor have ever driven one. But you have seen pictures of lots of cars and have traveled many miles in a horse and buggy. What possible could go wrong?
In short, a lot, a whole lot. Here are a few obvious ones for starters.
- Words mean things. In agile, there are many new terms and a lot of those terms mean one think in one framework and another thing in another framework. Take Product Owner. In Scrum, the Product Owner is a higher level, more business focused strategic thinker and decision maker. In SAFe®, the Product Owner is more tactical, and team focused. The Product Manager is SAFe® is a closer fit to the Product Owner in classic Scrum.
- Lack of Direction. A scaling framework adds top-down direction to a transformation. When paired with the bottom-up change from the teams, it can produce meaningful change. When you do not have top-down direction, teams often struggle to shed old ways of working for new ones. Additionally, top down leadership is needed to address organizational or structural impediments.
- When one area of the company is adopting a different form of agile from another area and so on, they tend to diverge. Although, we should not strictly proscribe rigid conformity or standards among teams, a set of best practices based on shared learning is extremely helpful in a transformation. When we do not have a shared framework, it is harder to apply shared learnings. Additionally, the difference in the frameworks, often results in disconnects and delays. Thus, defeating the overall purpose of the transformation.
A better approach is to start with a single framework and adjust it as needed based on experience. A starting framework will help standardize vocabulary making change easier. Additionally, you should follow the framework and only adjust outside the framework based on shared experience. Otherwise, there will be a strong tendency to not adopt the key framework elements where it is politically hard to do. These areas are often the areas when reformed, provide the biggest improvements. Finally, unless you are a small organization, a scaled framework like SAFe®, DAD, or Scrum@Scale should be used to get the full benefits of agile.
In short, do not start your transformation from scratch. Leverage the millions of dollars and ten of thousands of hours that others have invested in building and testing their frameworks.
Patrick Delany is a leader in lean-agile enterprise transformational and a Scaled Agile Coach/Trainer with over 20 years of information technology leadership and consulting experience. Patrick has transformed technology organizations, programs, and teams across multiple industries and technology disciplines including management services (operations, program, portfolio), applications development, and infrastructure.
Patrick Delany, MBA, SPC5, PMP, CSM, ITIL v3
Senior Lean-Agile Transformation Coach Consultant