Imagine you have just been asked to build an Agility Enablement Organization for your company. Sounds like fun, but there are some constraints you need to work within or around…
There are 100+ teams with varying levels of interest in Agile
You only have a small team of enablers
You would like to deliver incremental, measurable business value
Where would you begin…?
THE THREE TEACHERS
I've been thinking about how I would answer this questions and consulted three wise teachers for their advice...
TEACHER #1: SCHOOL OF HARD KNOCKS
My first teacher was the Shool Of Hard Knocks.
This teacher distilled the wisdom from my practical experience helping introduce, scale and optimize Agility in organizations of varying sizes - from 10 to 350 teams (150 to 4,500 team members).
This teacher taught me 3 key lessons...
Be prepared for a wide spectrum of agile hunger / aversion in the teams
There will likely never be enough people to help nor enough time to accomplish what we would like to
There might be a temptation to start thinking like B.B.Watts - and running a Big-Bang, Waterfall Agile Transformations.
Read an earlier Blog to understand what this mindset looks like and how you might avoid it: Enterprise Agile Transformation – The Story of B.B. Watt’s Lawn Service
TEACHER #2: THOUGHT LEADERS FROM SCRUM.ORG
My second teacher was conversations with thought leaders from Scrum.org who help large organizations Scale Agility each day.
They challenged me to think differently about Agile Enablement & Scaling...
What if we de-scaled? This was a radical notion. Sometimes less might be more - could we potentially increase agility and delivery of business value with fewer teams?
What if we were selective? What if we were super-selective and laser-focused about which teams we focused on?
Could Agility be offered as a service? What if we offer Agile Enablement as a set of services, kind of like API's that interested consumers could invoke?
TEACHER #3: INSPIRING CXO - MICHAEL DUNN
My third teacher was Michael Dunn - a very inspiring CXO with whom I partnered to scale Agility in 2 organizations.
Michael taught me 3 key lessons...
Agility should be a choice for teams
Agile Enablement Teams should introduce Agile Value, Principles, Practices & Tools and make them available to teams so that those interested can step-forward and explore them
When interested Agile Teams request for help, the Enablement Teams should be ready to serve. He supported a "bottom-up pull" for agility and not a "top-down push"
As I look at the wisdom from these 3 teachers, 5 key lessons stand out...
LESSON #1 - SEGMENT: Agile Interest + Business Value
It is important to segment teams based on their level of Agile Interest and the Business Value that might be created by coaching them.
LESSON #2 - FOCUS:Intentional + Surgical
Since there will likely never be enough people on the Agile Enablement organization nor enough time to do what we want to, we must apply the Scrum Value of Focus and be very intentional about which teams we help and how.
LESSON #3 - BE AGILE:Measurable + Incremental
We must practice what we preach. We must apply the same Agile Principles to Agile Enablement, that we preach teams to use for Agile Software Delivery.
We must create targets for incremental, sustainable, measurable Agility,
We must frame hypothese on how to accomplish these targets
We must design & execute experiments to test these hypotheses
We must measure results to validate / invalidate our hypotheses and create validated learning
We must apply the learning to adapt our approach
LESSON #4 - DIVERSIFY:Services + Packages
We must have a diverse portfolio of services organized into simple packages that are easy to communicate and understand.
LESSON #5 - BE SELECTABLE:Allow Choice
Finally, we should allow teams to step forward and select how they want to engage and choose the package that makes most sense for their goals.
We can segment teams along 2 dimensions...
DIMENSION #1 - BUSINESS VALUE
Some teams would be working on products that are strategic to business value, while others might be working on products that are tactical or that will soon be retired.
DIMENSION #2 - AGILE INTEREST
Some teams may love Agility and are ready to do whatever it takes to become more Agile. Others may hate Agile Value, Principles and Practices.
Now that we have segmented teams in 4 quadrants, how do we rank them to make sure we are laser focused on helping the teams that can deliver maximum increase in sustainable, measurable value for the business...? Here is one possible rank ordering...
- Focus maximum energy on the teams that are hungriest for Agility and are working on the most strategic products
- Support teams that are very hungry for Agility but may not be working on strategic products
- Get wins from teams in quadrants 1 and 2 that might shift teams in quadrant 3 towards quadrant 1
- Ignore teams in quadrant 4
Now that we have segmented and ranked our teams, here are 10 questions that might help you offer Agility-As-A-Service for choice-based Agile Enablement...
QUESTION #1 - WHERE IS THE TEAM TODAY?
Each team might be in a different state of Agile Maturity and Readiness. We can use Agile assessments to help teams clarify where they are in terms of ability to deliver business value and desire for getting better.
QUESTION #2 - WHERE DOES THE TEAM WANT TO BE?
Teams may be interested in different goals. Some may be interested in faster time to market. Others may want to improve quality, stability, flexibility, etc. What's most important is that the goals be important to the teams themselves.
QUESTION #3 - WHEN DOES THE TEAM WANT TO GET THERE?
The next question is by when does the team want to accomplish their goal. Like the target destination, the target date should be determined by the team. Both these ideas are captured really well in the concept called Wildly Important Goals or WIG's by the Franklin Covey 4 Disciplines of Execution Framework
QUESTION #4 - WHAT IS THE TEAM WILLING TO INVEST?
Sometimes, there might be a disconnect between what the teams are willing to invest, what they expect from the Agile Enablement Organization and what they expect to get in return.
- Some teams may be willing to commit to investing time on a regular cadence, while others might not.
- Some may be like to be challenged, while others may not.
- Some may want to be coached, others may want to be left alone.
- Some may want existing culture and processes to be improved while others may consider those to be untouchable.
No matter where each team might be, is important to bring transparency into what the teams are willing to put in and what they expect from others, to manage mismatched expectations.
QUESTION #5 - WHAT SERVICES CAN THE AGILE ENABLEMENT ORGANIZATION OFFER?
The Agile Enablement organization should be equipped to provide key services...
- Business Outcomes & Measurement Services: How to quantify business outcomes in terms of business value and how to measure progress towards the target
- Strategy & Portfolio Management: How to define a strategy to help accomplish the business outcome and how to invest the portfolio of funds in a way that is aligned with the strategy and outcomes
- Delivery Frameworks: How to understand and implement Agile Frameworks like Scrum, Nexus, Evidence Based Management (tm)
- Craftsmanship: How to master engineering practices - emergent architecture, evolutionary design, pair programming, automated testing, build, deployment, etc.
- Culture & Enablement: How to design an organizational culture that supports sustained Agility at all levels
QUESTION #6 - WHAT PACKAGES DOES THE AGILE ENABLEMENT ORGANIZATION OFFER?
Can we create some bundles or packages that are easy for teams to understand? Kind of like the combo meals on a fast-food menu. Some possible packages...
- Measurement Only: For teams that may not care about Agile but may still care about delivering sustainable, measurable business value.
- Self-Help Only: For teams that want to on-demand resources like blogs, videos, books and the flexibility to choose what they want, if they want, when they want.
- Training Only: For teams that want training in select areas and then want to be left alone.
- Quick Launch Only: For teams that want training to be followed with a short intense "boot-camp" like engagement that helps them apply what they learned in training
- On Request: For teams that want to "buy" a bundle of coaching hours that they can request on a first come first serve basis as needed
- Embedded: For teams that want embedded coaches who will sit with them for a time-box, 40 hours a week.
- Transformation: For teams that are willing to do whatever it takes to accomplish sustainable agility and lasting transformation.
- Build Your Own Package: For teams that want to pick and choose and build a customized package
QUESTION #7 - WHICH PACKAGE DOES THE TEAM WANT TO CHOOSE?
Now that teams understand the different ways in which they might engage with the Agility Enablement Organization, they can pick and choose the package that works best for them or co-create a new package. If the Agility Enablement Organization feels that there is a disconnect between where the team is, where they want to be, by when they want to get there and what they are willing to invest, this would be the time to respectfully disengage or guide the team towards options that are more realistic.
QUESTION #8 - HOW WILL THE TEAM MEASURE PROGRESS TOWARDS THEIR GOALS?
To make sure that we eat our own dog-food, we must manage our Agile Enablement empirically. We must design and execute experiments in short sprints and measure leading and lagging indicators so teams can empirically inspect and adapt their progress towards their goals.
QUESTION #9 - WHAT'S AVAILABLE FOR THE AGILE ENABLEMENT ORGANIZATION?
QUESTION #10 - HOW WILL THE AGILE ENABLEMENT ORGANIZATION USE WHAT'S AVAILABLE?
Finally, the Agility Enablement Organization must be strategic in their Build or Buy decisions.
- Can they reuse any of the existing frameworks, assessments, trainings or workshops as is?
- Can they complement internal talent with external talent?
- When should they they complement / customize / replace industry resources? Why?
You can also view the slides for this blog on my slideshare presentation.
How would you apply what we have explored? What experiment would you execute to test your hypothesis? Try something and let me know what you learn.
Until our next conversation, keep calm and Scrum On!