I remember it well. It was about 11:40 a.m. and we had been meeting with senior directors, vice presidents, and a number of influencers since 9:00 a.m. the previous day. The conference room was strewn with the remainder of breakfast and a high number of disposable coffee cups. There were large sticky note sheets of "products," "product groupings," "value streams," and the proverbial "parking lot." As people sat silently and leaned back in their chairs - some with hands over their faces - there was a single question written in a large black dry-erase marker on the whiteboard at the end of the room: "Where do you want to go now?"
An agile coach stood next to this question as if it were less a question and more a charge for action. Purposely, however, I had phrased this as a question and not as an answer. For the past day and a half, we had solutions, talked about moving from a project to a product-based culture, discussed budgeting and finance, examined as a group different principles and practices of continuous improvement, reviewed the challenges that the current teams had not been able to overcome, and argued over what was the most important thing to work on for the upcoming year. Now it was their time to make a series of important decisions.
Organizations that are going through adopting agility and transforming their corporate culture are faced with a series of questions when they hit this plateau of scaling. Large organizations, especially, are faced with a number of challenges in breaking down outdated ways of thinking and working in order to support faster time-to-market, greater response to shifting customer needs, and rapid changes in technologies. Some, have seemingly outgrown the planning and communication constructs of scrum or XP or even individual team Kanban and need something more to facilitate their products. What generally happens is that they face the same challenges when deciding to scale that they faced when they decided to give agile a try and they get locked back into the old familiar "analysis paralysis" of making a decision around scaling. The following are three misconceptions that we have.
Misconception #1: Only one scaling framework is proven.
We have met with several current and prospective customers that have led scaling conversations with, "We have decided to use XYZ framework. Now tell us how to do it." There is no conversation about the practices that are working well, the problems they are trying to solve, the external or internal drivers for the change, or even openness about which framework may or may not fit their culture, desires, or staff. When MCG starts to talk about other frameworks or even apply scaling principles to fix identified needs, the conversations quickly diverge to why XYZ is the only proven framework.
Fact #1: There is no scaling silver bullet.
Remember when we used to say "Agile is not a silver bullet. It does not solve all of your problems." And then we would go on to explain that agile practices highlight weaknesses, help create a desire to solve those weaknesses, and then encourage continuous change to relentlessly improve. Scaling is the same way. Choosing a scaling framework does not default to success because change requires courage, not rules. As you and your organization decide on a scaling framework, it is imperative to look at what the organizational challenges are, the business drivers, and the external client drivers, and then choose an approach that fits the need. Then, the real work begins.
Misconception #2: Only an all-inclusive scaling framework will give you a bang for the buck.
Like in the example above, many organizations we work with have been exposed to scaling through seminars, cold calls, or even blogs like this! They hear the benefits of moving beyond simple "scrum of scrums" and how planning more can be an effective tool to solve common challenges. In some cases, clients feel some familiarity with the more rigid methodologies of their past when plans were 18 months long and everything worked out fine (a bit of sarcasm there!) They see the promise of worksheets to solve complex decision points and even algebraic formulas to help them solve prioritization and estimation stand-offs. "Only if I choose this all-inclusive scaling framework can we be successful!" they say to themselves.
Fact #2: All scaling frameworks are packages of agile practices, tools, and processes.
The fact is that all of the scaling frameworks are comprised of principles (ways of thinking), practices (ways of working), and tools that have been packaged based on the experience and empiricism of the author and his or her "stream" of colleagues. Because they have experienced certain challenges at certain organizations and have had certain successes, the all-inclusive scaling framework has grown and changed to what it is now.
This does not mean that in your specific challenges at your organization, you will have the same successes. And as one of the authors of one scaling framework says, "Always fall back on the principles when making decisions." Scaling frameworks can be helpful, but always be agile in your application or decision-making.
Misconception #3: Once you pick a scaling framework, that's it, you are locked in.
Last year we were working with a large organization that had already started down a certain scaling path. They had chosen a certain way of working based on input from a development partner and were gaining some ground and had some successes. Unfortunately, they were seeing some challenges in an area around team formation and around the backlog that was, frankly, quite scary.
As they continued, it became evident that they needed some changes in their ways of working in order to fix the challenges that were starting to reveal themselves. As coaches, we went to them and mentioned what we were hearing, seeing, and sensing in the force and we recommended that they try a certain practice to fix the challenge.
Some mid-managers balked at the change, stating that it didn't align with the current scaling framework. Others questioned whether we were trying to derail the current implementation by throwing in a principle that seemed to live outside of the all-inclusive framework.
Fact #3: Plan to fail fast, and fix fast, even with scaling.
As we started to move up the organizational management chain in that business unit and started engaging more folks in the conversation, we had to explain and coach that just because you engage a scaling framework, it does not mean that all other agile practices go out the window! If a challenge needs to be solved, find the right change to fix it! Choosing a framework can help your organization move forward, but it does preclude you from making good decisions around solving problems.
To recap, scaling has become a necessity in some organizations as product and technology complexity has increased. As your organization decides what to do, start by using agile practices and principles and implementing them to solve challenges. Is communication between teams a challenge? Then move them closer together or expect additional planning time to solve for cross-team dependencies do not just launch into a framework. Is your organization struggling with knowing what is being worked on by multiple teams? Increase transparency into backlogs, do better refinement, and consider even more collective (team and business) conversations around the direction of the product before inserting more disruption through more processes. Overall, try incremental and continuous improvement efforts based on the challenges your organization is facing!
Motion Consulting Group
