Scaling Agile

I get nervous talking about capital A, Agile. Why? Because there are a lot of passionate opinions about it and I don’t have a background in agile implementations. I am 100% behind the principles described in the Agile Manifesto. But implementations are another thing. It’s hard to get it going in startups, let alone scaling it. Before we go into some of the challenges, let me define what it is for those who don’t know.

Agile teams are self-organized. They get to determine–with guardrails–the best way to achieve desired outcomes. Agile teams deliver work in (relatively) small increments. Results are evaluated incrementally, so teams have a natural mechanism for responding to changes quickly, getting back on track if divergence has occurred, and continuously improving work where possible.

This, I believe, belongs all across organizations and is a requirement for thriving in the 21st-century digital world. Agile principles were developed by software engineers who, for all intents and purposes, were at the forefront of the digital revolution. They were describing the work principles necessary to deal with the complexity and uncertainty of the world they were building.

I am agnostic on how we get there, as long as the principles are at the forefront. Believe me, I am no expert. I truly come to the problem with the mindset, “Hey, Agile principles are pretty spot on. How do we get everyone to adopt them such that the organization and its people benefit?”

The problem with scaling Agile

The fundamental problem with many efforts to scale Agile, is that principles are often forgotten or ignored, whether in large Engineering groups or when attempting to implement across an organization. Deserved or not, SAFe (Scaled Agile Framework) takes the brunt of the criticism, arguably because it is in so many organizations.

With that in mind, my colleagues, Kavita Appachu and Mike Kendall, and I sat down with Scaled Agile Coach, Per Nordgren, to learn more about SAFe, it’s strengths and weaknesses.

What I particularly liked about our discussion was SAFe’s adoption of Lean principles in addition to Agile. (These are not the same!) Plus, I didn’t find anything in SAFe that precluded the implementation of Agile principles. I love the focus on Value Stream and at least the ethos of “Customer Centricity,” though it seems to fall a bit short in the follow-through on that front.

There are things that I wince at, such as the assumption that this implementation was for product development and not other parts of the organization. An organization with “agile” development and “waterfall” in the rest of the business, is a “waterfall” organization.

Also, I found that SAFe pretty much assumes that technical risk is greater than market risk, so “validate” is always after “build.” This is a 20th-century notion and is fundamentally wrong today, for most organizations. There is actually very little technical risk for new products, services, or internal processes.. That’s why the “correct” interpretation of Lean Startup’s “Build Measure Learn” is to build an experiment and learn from that. Not build the product first.

The biggest flaw with SAFe, however, is not uncommon to most enterprise-wide change programs. The problem assumes that fundamental change requires a top-down approach to implementation. But Agile principles reflect behavior change. Behavior change requires ground-up implementation, enabled by top-down support.

It’s ironic that the SAFe implementation approach is neither lean nor agile.

As with any project facing a degree of uncertainty, implementation requires a focused, iterative approach. In by latest book, Disruption Proof, I share a phased approach I call KASE:

• Kickstart — don’t over plan because you’re going to get stuff wrong. Start small, with a few engaged, enthusiastic Agile teams to figure out what works. These teams then become promoters who can model behaviors and demonstrate how agile practices can be implemented in your organization. Leverage what you already have. Drive immediate impact to prove capabilities, demonstrate success, and generate interest. But also, identify capability gaps and early adopters.
• Accelerate — Double down on what’s working. Formally build an implementation team and roadmap. Maintain internal control, don’t simply outsource. Find a high-confidence project or most needful company group to grow the implementation.
• Scale — Push the new way of working to business units, until they start pulling. Implement structural components–mechanisms and scaffolding–that codify the new way of working, while protecting emerging efforts.
• Endure — Implement corporate governance practices to ensure stability, while making adaptability a core part of structure, hiring, internal promotions, and so on.

In contrast to the SAFe implementation chart above Kickstart first aims to prove that behavior change is possible and that it drives impact. Only then, will other parts of the organization buy-in.

1. You don’t have to train anyone at this point, the people with the skills already exist to get started. You don’t start with consultants or a rigid framework, because no one in the organization has any reason to believe in the training they’re receiving. The organization already has design professionals, startup folk, and agile practitioners. These people likely have an “entrepreneurial spirit” that will serve them well.
2. You can’t train leaders and the start, because they will manage the behavior that’s already happening. They can’t change behavior, they must reinforce new behavior. Often they don’t trust their people, so are incapable of providing a safe (ironic) environment for new ways of working,
3. Identifying value streams is fine, but it’s just more analysis and planning, when what you really need to do is empower people and practice new behaviors.
4. Implementation plans are fine, as long as you know they’re going to change dramatically.
5. I tell the startups the era of the big launch is over. Products are never done, so why arbitrarily choose a point in its development and try to create a hype cycle, without truly understanding if your product creates value. Same here. Start small, iterate, create momentum. Create momentum through proving impact is the new “launch.

Do this instead:

1. Identify real business challenges, big or small, that will likely have a positive impact on the business achieving its priorities. Ideas can come from leaders or from employees themselves. You can use the project prioritization board to choose challenges or let teams choose for themselves.
2. Form agile teams to cover each challenge. (Number of challenges and participants up to leaders. Shoot for “investing” in 100 internal “startups” in 100 days.
3. Assemble your coaches as described above and sette upon the behaviors to practice: developing empathy for stakeholders (including customers); rapid experimentation; developing evidence of need and direction for solution.
4. Create a “growth” board or “innovation” board composed of leaders who will actact as project investors.
5. Find time and space, create a sense of safety to teams, to enable them to do the work of developing evidence that the challenges can be solved. Could be 2 days, a week, or 10–15% of their time.

Remember, these are working to solve real business issues. The exploration work doesn’t take away from “execution” work, it makes execution work more efficient. Additionally, the teams are very quickly practicing their “agile” and “lean” work. It’s a real world point to iterate from, rather than from in the mind centralized planning and training.

Training can contribute from the beginning, but again it’s ground-up and can be fairly light. So teaching teams lean innovation practices — human-centered design, rapid experimentation, and agile form the basis for behavior change. Upskilling coaches on EQ as well as lean innovation IQ to augment their existing abilities, is important in establishing a safe environment. And helping leaders to learn to mentor, not just manage, provides real-world practice, rather than top-down enforcement.

If you want to learn more about scaling agile I’ll be doing a live Q+A on the subject on July 14 at 11am PDT. Click here to join.