There is a lot of noise in the industry now about “Scaling” Agile. I think you need to consider scaling for the right reasons. An executive order may be the impetus, but what are the real reasons that inform the decision-making process? What do you intend to gain for the organization? What is the timeframe for adoption? What is the payback or Return on Investment?
In this blog, we’ll review the scaling models and the need for them. As an Enterprise Agile Coach, I often describe the “Ideal versus the Real” when I speak about reasons for adoption. No two companies are alike but all have similar qualities and reasons for scaling. Here are some of them.
Why Would I Want to Scale?
So here are some of the reasons that would make logical sense to consider for scaling. Again, going back to the Ideal vs. Real concepts, Ideal Scrum is not always a good practice in real corporate life.
SCRUM or KANBAN Is Not Enough
We find that having SCRUM teams is good, but now we find that complex, large programs require more coordination, more collaboration and frankly, just more horsepower in our development engines than simple Scrum teams can provide.
Regulatory Compliance Needs
I have worked in several regulated industries, Utilities, Banking and others, that require more than User Stories and working software as documentation of systems. Regulated industries demand traceability and audit trails far beyond what is provided by simple outputs from SCRUM events.
As a corollary to the Regulated industries, Audit also requires knowing Inputs, Outputs, roles, separation of responsibilities and documenting the same – not always the case with SCRUM practices where we overlap a lot of responsibilities.
Major New Initiatives Requiring Speed to Market
This may be another variation on a theme of SCRUM being too small for the effort required, however consider major manufacturing or government programs where there are thousands of contributors, hundreds to thousands of vendors and suppliers delivering to large scale systems. It takes more than just “more scrum teams” to get the job done. We need an infrastructure capable of delivering major systems of systems on the scale of a jet fighter or an SAP conversion.
Enterprise PMO Looking for More Accountability
To do forward looking plans and budgets, large scale companies often employ Enterprise level Project Management Offices for the purpose of delivering Programs and projects for the enterprise with efficiency and effectiveness. These organizations will require more accountability on the part of SCRUM teams.
Tighter / More Effective Connection to the Business’s Needs
One on One in front of a whiteboard is the recommended approach for SCRUM teams to gather requirements for delivery of Minimum Viable Product. When your business customers are for example, banking managers for a global bank with participating units in 100+ different countries all with different banking laws, Face to Face does not work well.
In your organization, one, some or all of these topics (plus others) may be prevalent. What does your organization need to address? This sets the stage for making some headway on the topic of Scaling Agile across the enterprise.
What Does a Transformation Look Like?
An Enterprise Transformation is different for each individual company, but does have similar major phases and milestones. So here is a generic model for adoption.
Figure 1 – Enterprise Agile Adoption Phases
In mobilization, we do the kinds of things discussed in the first entry in the series, we:
- Define the Vision
- Define and deliver the Executive Steering committee
- Define and deliver the Adopter Delivery Group
- Get a budget
- Select measures to determine “Done”
Method Selection or “The Bake Off”
- Picking a “Winner”
- Roll out
- “Piloting (Early Adopters)”
- Publishing Success Stories
- Develop a Communication Plan
- Develop a Change Management plan
- Develop a Metrics plan
- Continued rollout
- Measuring “are we there yet?” See next blog for an explanation of Metrics
- Measuring compliance with agile practices and tool usage for all adopters.
- Ongoing maintenance and continuous improvement of the Enterprise Agile Transformation program intellectual property and practices.
- Measuring compliance with agile practices and tool usage
So how long does an Enterprise Agile Transformation Take?
Well, the answer is a very Zen-like answer to a question which is “How long does a piece of string need to be?” The answer is “Long enough”. So how long does an Enterprise Agile Transformation take? As long as it takes. There are too many variables to give an accurate estimate. It can take 1 1/2 to 4 years depending on the size of your organization, your Transformation plan, How you approach it and what your “Definition of Done” is.
What does an Enterprise Agile Transformation look like?
An Enterprise Agile Transformation is a multi-layered beast. At its Core you find:
People Crosscutting the Org
To misquote Bill Clinton in his 1992 debates with George Bush, “It’s the people, stupid”. At the heart of all of the work we do is the need to capture the hearts and minds of the people who do the work. NO amount of mandating by management will make an agile transformation work at any level, scaled or not.
We have multiple constituencies who we need to educate, and cause to change direction and stop using old patterns and adopt new ones. To do so, we have to assure that the people in the organization understand the why, what, when and how of what we are attempting to do.
Processes “Workable Selection”
Whatever process or method we choose for scaling, very likely it is not an IT-only decision process. And even within IT, there are several service groups affected differently by agile methods. All need to be included in the agile tent.
Tools “Enterprise or Local Selections”
Tools are often like religion, there are many and it seems we have different selections within large corporations. Some companies mandate the use of a specific toolset, others are very linear in their attitudes about tool usage. Regardless, the tools need to often provide upward reporting of metrics on adoption and sustainability of agile practices.
Requires Strong Leadership
“Personnel is Policy” to misquote Elizabeth Warren. Whomever leads the charge needs to have strong leadership skills Someone who can influence, what I call “Sell or Tell” and can make their arguments heard and stick. More on this topic in the last in the series “The Man Behind the Curtain.”
Acceptance is Highly dependent on:
Change Management Plan
All the good works done by the steering committee and the adopter group are no good if we do not have a strong change management plan. This sets the direction and rollout for the enterprise.
Communications Management Plan
Also essential is great communication plan. This plan outlines the messaging required for all levels of management for top down communication, and also describes the strategies and tasks for generating bottom up support for the program.
Figure 2 – Holistic Approach to Enterprise Agile Transformations
OK, I’m Geared Up and Ready To Go! What Are My Choices?
Here are the most popular, in alphabetic order, showing No favorites:
- DAD – Disciplined Agile Delivery
- Hybrid – Mix of best practices from two or more
- LeSS – Large Scale Scrum
- SAFe – Scaled Agile Framework
Of the listed methods, one stands out from the rest in a recent survey conducted by VersionOne, an agile tool provider. Per their 10th Annual State of Agile Report, the Scaled Agile Frameworks leads the pack with 27% of respondents reflecting that they were in some stage of adoption. This compares to 6% for LeSS – Large Scale Scrum and 3% for DAD – Disciplined Agile Delivery.
SCRUM and SCRUM of SCRUMs leads all with 72% responding that that is their method of choice.
So what do each of these Methods look like?
Disciplined Agile Delivery (DAD) 2.0
Figure 3 – Disciplined Agile Delivery 2.0
Good for Regulated Companies
If you are in a regulated industry and need more technology related approaches to building your apps, DAD is a good process to follow. It is strong across the IT infrastructure and is growing into the business community. Strong Milestones, and data points – lots of recommended system and technology related documentation.
Maturing to include Program and Portfolio levels
Differing from the original 1.0 version, there is new emphasis on Program and Portfolio level organization and delivery.
More Technology direction than other two
There is strong technical and technology direction form DAD. It covers details the others do not about “how to” in SCRUM and KANBAN environments.
Recognizes DevOPS Challenges
Separate from the other two, it specifically calls out and defines practices for DevOPS, a growing trend in these scaled methods.
Least adopted of the three proposed Methods.
Large Scale Scrum (LeSS)
Figure 4 – Large Scale SCRUM process
A Scrum of Scrums
This for all intents is just a Scrum of Scrums. Great practice to follow if you have organizational discipline and can enforce the rigor of using this approach as with simple scrum.
Very Idealistic Scrum of Scrums Implementation
To my Ideal versus Real argument, like all these methods LeSS is an ideal picture of how things work. Your mileage may vary. The higher the regulation and compliance needs are probably the less (no pun intended) you will likely adopt Large Scale Scrum.
Requires Discipline and Rigor
This approach in particular, will require significant discipline and rigor for adoption and sustainability. Since it is scaled scrum, likely it would require some to a lot of customization to work in your organization.
Not really a Method, more a set of Procedures
This is the original definition of a scrum of scrums with some additional roles to help it scale a little better.
Scaled Agile Framework (SAFe)
Figure 5 – Scaled Agile Framework 4.0 Expanded to 4 layers
Most adopted of the three
According to VersionOne’s 10th annual Survey of Agile, SAFe is the most widely adopted and accepted method of the three recommended. It has traditional KANBAN and SCRUM support, and for programs and projects has sync and cadence points for matching up disparate types of waterfall, and agile projects.
SAFe does represent a built up, ground up approach to a method based upon LEAN practices.
Business centric based (lots of business collaboration)
As indicated by the diagram above it is in my opinion the method that goes the farthest to include the business in a collaborative process. Its sweet spot is 150 to 400 participants and covers the whole organization. It provides an even balance of Tech and Business focus.
Moving to Scrum implies a behavioral change
– to the Agile mindset
– supported by the Agile Principles found in the Agile Manifesto
– potential organizational change
Many teams find themselves in the land of FrAgile (i.e., fake Agile)
– Scrumbut (i.e., we are doing Scrum, but not some of the practices)
– WaterScrumFall (i.e., some elements of Scrum within a waterfall lifecycle)
– Kantban (i.e., Kanban without respecting the queues)
This may be because there…
– wasn’t a commitment to go full Agile
– wasn’t an understanding of what an Agile method entails
– wasn’t the talent (such as an Agile Coach) available to help bring about that change
– was an incremental Agile deployment approach which stalled along the way
Frameworks like LeSS, Dad and SAFe are developed by experts. Who’s writing your hybrid? How measurable is the work done under your hybrid?
Each Enterprise has different needs and characteristics that would inform your decision making.
Here are some common areas to develop criteria to use if they apply to you:
- Regulation (Sox, Banking, Pharma and other)
- Geographic Distribution (multiple locations for both business and IT)
- Offshore contracting / Vendors and Suppliers inside the firewall
- (“Inside the firewall” meaning teams from these sources are part of the local team)
- Size of teams (Do you organize around projects or work?)
- Audit Requirements and Compliance needs
- Internal Need for Command and Control (politics, cultural resistance to change)
So I have to start this section with a Disclaimer:
These sample criteria represent my opinions alone and no other organization or business. If you want to argue about them, feel free to ping me. Don’t blame anyone else for my choices.
Hybrids are not represented as it would not be possible to determine value for individual Hybrids, I’ll leave that up to you…
Here are SAMPLE Selection Criteria I have found useful over the years. Please bear in mind YMMV (Your Mileage May Vary) depending on any number of variables governed by and informed by Comparison Criteria.
Which One Should I Pick?
So here’s a simple consultant’s answer: “IT DEPENDS…”. It depends on your culture, your tolerance for change, on how you are organized, what timeframe you have, what problems you have to solve and what regulatory and compliance needs come up.
Each company I’ve worked with since my beginning Enterprise Rollouts in 1998 has had differing business models, differing requirements and what works for one org may not work for the next. What works in one portion of an org may not work in another. So you are left with the question, “What works for you?”. This is something you have to answer for yourself.
However, I do have some recommendations based upon past experience doing Enterprise rollouts.
Stick with Popular Methods (DAD, LeSS, SAFe)
Look for commonly supported methods. Between these three you are very likely to find a solution that you can customize to your need. These are supportable, customizable and have a long life span of 3 to 10 years.
I should note that I am not a big fan of Hybrid solutions. They take too long to define, compromise by committee will not achieve your long term goals, and likely will end up worse than waterfall in execution. Hybrids are technology bound, do not have a support structure for the long term and usually die a quiet death over 2 – 3 years due to adoption of methods that work.
Only scale for the right reasons – have a solid business case with an ROI
Do not start an Enterprise rollout without a case and an expected ROI. How else will you justify a budget, and the time expense and change to the organization without one?
Do not expect to adopt a Method Out of the Box
I have yet to see a successful adoption that did not do some to major customization of the out of the box method. Just the evidence of different business models says “one size does not fit all”. Expect you’ll have to do some customization. Some of these methods are like the fake town at the end of the movie “Blazing Saddles:”, just propped up storefront explanations of deep and wide topics. Get a close a fit as possible then tailor to your need.
Get a Sherpa guide
Get a Sherpa guide. You will be surprised during the journey what you discover you did not know and did not consider. While it may seem an expensive step, it is going to save you a lot of money and time if you get an experienced guide. See the last blog, “The Man Behind the Curtain” for a more in-depth explanation.
I Picked One, Now What Do I Do?
So what comes first, what comes next? We do the mobilization steps until we reach a critical mass of staff and budget approval. Then we move forward with selection. Once we finish that, then we start with:
Any adoption will most likely require an Out of the box (OOTB) Method with customization to your company’s needs. OOTB solutions are generic, and not meant to be adopted wholesale. Expect that you’ll make changes like a tailor building a bespoke suit of clothes.
You have several groups that need training:
- The Agile Transformation Team
- The Early Adopter teams
- The Leadership of the Early Adopter Teams
- Executive management on both the IT and business side
Dealing with Vendors, suppliers and contractors also should be a matter of focusing their contracts and SLAs along the lines of supplying staff that are trained in basic agile skills, so they can get ramped up quickly when they join your teams.
As part of the Change and Communications plan, you will need a communications plans to establish a roll out plan and process to get the customized method and training (and potentially tools) in the hands of the early adopters.
“Piloting (Early Adopters)”
Have you noticed I keep referring to “Early Adopters”, not “Pilots”? I do not like the term Pilots. It is a term that makes me think that if the plane is going down, you can bail out. Early Adopters has more of finality ring to it.
Measuring Are we there yet? Are we there yet? Are we there yet?
Conversion measures begin with early adopters. The quality and quantity of the teams on the journey need to be measured.
Critical Mass and Sustainability
Our goal is conversion of most or all of the organization. So let’s define what portions are being converted and target them in our change and communications and rollout plans.
Publishing Success Stories
Per John F Kennedy, “Success has a thousand fathers, failure is an orphan” – let’s celebrate our successes as much as possible. Let’s find every possible communications channel to highlight that staff are being successful with agile within and outside of the organization.
Who does this work? – The Steering committee, the Agile Adoption Group and Enterprise Coaching.
Parallel Processes are Engaged
You’ll find that once you start, there are a LOT of parallel processes you need to kick off. This implies a strong change management function be employed. I recommend the use of tools like any of the popular work item management tools Rational ALM, VersionOne, Jira, CA Agile, and others. Pick your own poison, but use one religiously to control all the parallelism and interaction of these different work streams.
Here is a sample list you might encounter:
- Create / customize training materials
- Configure tools templates
- Create new outcomes and outputs from new processes
- Create new metrics to measure new / different ways of doing work
- Define new roles
- Craft messaging for change management plan
- Cobble together news sources to publish events and news about the new method and success stories
So, a hint, staff effectively!
Picking Early Adopter Projects
“Don’t Use the Word “Pilot”
As I’ve said before, don’t use the word “Pilot”. I like the term “Early Adopters”.
Choose Early Adopters Selectively
Look for potential successes for early adopters. I had a psychologist show me a card trick once, and regardless of who he played, and what selections were made, the answer was always the 10 of spades. We want to use the same mentality in picking early adopters. We want to maximize the selection criteria so that the teams will succeed despite picking up an entirely new method.
Choose 8 Or 10, Early Adopters – You Are Likely to End with 1 – 3
The work assigned to early adopters can prove to be frail projects. My experience is that over the course of 6 – 9 months, projects get killed, de-funded, put on hold for more important work, and what started as 8 to 10 selections winnows down to 1 – 3 remaining survivors. Not a good showing when you want to validate the results with working teams.
Expect that you’ll need to run these experiments for a while, about 3 – 6 months, to determine actual success.
Here’s a model to also consider when selecting the teams. Some early adoption teams will like to take on new ideas and practices. Others at the opposite end of the spectrum, the Skeptics and Rebels may never adopt. My advice for that holdout group is “vote them off the island”, by finding them different roles in the organization where their negative attitudes do no harm. The figures are samples, YMMV.
I’d also pay attention to who is affected over time when adopting these new practices. There are a number of paradigm shifts that take place both for the adopter teams and for the rest of the organization.
Hopefully, this blog has given you a start in the right direction.
In the next blog, you’ll learn all about how to measure your transformation results. Stay tuned!