Real Agile Change

In the 20 years I've been involved in agile & lean change, I've seen real agile change produce better outcomes (higher ROI, happier customers and employees) while faux agile change lead to few, if any, actual improvements. The difference often comes down to whether you're actually managing risk or just appearing to do so. Faux agile change generally becomes an attempt to work in an agile way, without actually changing the way work gets done.

Why would anyone pursue faux agile change? Perhaps it's because they've been commanded to "go agile" or feel immediate pressure to quickly improve or maybe they simply aren't aware that certain approaches to becoming agile don't actually lead to meaningful change.

Real agile change tends to involve one or more of the following:

• Executive & Manager Education - If your organization has any hope of being agile, your executives and managers must first understand what it means to be agile (not "do" agile), how and why old processes and habits must change, what it typically requires to make real agile change and what they can do to support such change. It can help for these execs and managers to visit and learn about the cultures and behaviors of teams in other companies that are producing awesome outcomes. Agile initiatives need strong executive support to make real change a reality.
• New, Cross-Functional Pilot Team: This is one of the most tried-and-true approaches for beginning a meaningful agile change in your organization. Pick an important initiative, invite all of the right people (necessary to be successful on the initiative) to participate full time (or as close to it as possible), give them in-depth, hands-on training and extended coaching to help them truly change mindset and habits (in planning, management, development, testing, etc.) and begin to be agile. This is a full-stack effort, meaning that developers, testers, analysts, subject matter experts, operations staff, product managers, compliance, etc. - all get trained and coached in real agility. This pilot team will need to face down risks, like lack of alignment with strategic needs, building the wrong product or features, not integrating work early and often, not getting feedback fast enough, knowledge silos and too many handoffs. Such a team becomes high performing, it can become a training ground for others to learn what it means to be agile.
• Evolutionary Releases: Rather than work with just one pilot team, this approach applies essential agile principles to numerous teams that collaborate to produce a shipping product. They key is to have the teams evolve their product from a primitive whole to a more sophisticated product over time. For example, a 6-month public release is broken into numerous shorter releases, in which major risks are managed early and where you can show working software, albeit still primitive, to stakeholders on a regular basis. This approach requires people to truly practice continuous integration, not just install CI software but rarely integrate. It requires evolutionary planning and mastery of vertical slicing (walking skeletons), an essential agile skill that people can and should learn in training and via coaching. It requires enough technical excellence to ensure that you aren't producing tons of defects. The regular creation of working software enabled you to get regular feedback, to guard against building the wrong thing.
• Team-Led Process & Pull-Based Help: Rather than impose a process on people and teams, this approach simply encourages teams to own their process and improve it as they see fit. If a team wants help, there are experts inside the company who can help, but it's only supplied when it's asked for. In lean terms, this is pull-based, not push. For example, a team may decided they need help on refactoring or continuous deployment and ask for help in learning those skills. Many shops that have failed with grandiose agile transformations have transitioned to a team-led process change approach, with agile experts around who can help with impediments and skill building. While the teams have autonomy on their process, they still need to be aligned to organizational strategy and focused on accomplishing high value work.

On the other hand, here are common faux agile changes:

• Same Work, New Roles & Cadence: Work exactly as you did before, only divide it up into 2-week sprints and change people's titles. Conduct analysis and design sprints, followed by development sprints, followed by testing sprints, followed by code freeze sprints to deal with all of the defects. Change people's titles to match the agile process names and conduct daily standup meetings without removing any actual impediments. This faux change has been called Scrummerfall, a neologism made up of the words "scrum" and "waterfall."
• Same Work, New Agile Tool: Work exactly as you did before, only do it using an agile planning tool. Buy everyone a license to the Agile planning tool, optionally give them training in the tool and then watch the magic happen. Oh, and if you purchase enough licenses, the tool company will throw in free "Agile basics" classes that will expose everyone to a prehistoric agile method and help them understand how to use the tool to implement that method. OMG, I'm not even making this up!
• New Roles & Cadence, New Agile Tool: Perhaps the most popular faux agile change of all is simply the combination of the above two examples. Get everyone sprinting, change people's titles, use the new agile tool, then attend your PMO's "agile success" party. Meanwhile, nothing has actually changed.
• Same Work, New Training: Get everyone in your organization into expensive, multi-day training classes, provide them with no coaching after the training to help actually change old habits, then watch as they perform the same exact work they always did using a few new words and rituals.
• Same Work, New Scaled Process: The new vogue for faux agile change initiatives involves scaling. Purchase training from your favorite scaled agile goliath, prominently display images of the scaled framework everywhere, purchase the tooling to support the scaled process and watch hundreds or thousands of people jump onto release trains that aren't headed anywhere you'd actually like to go.

My company, Industrial Logic, often gets called in after faux agile changes produce dismal results. It usually takes a few years before the excrement hits the fan. "Agile" becomes a bad word in the organization, people are stressed and unhappy and the company has just lost a good chunk of change.

It doesn't need to be that way.

Real agile change involves learning how to work differently to produce better results. It's about actually managing risks rather than blindly following rituals. Ultimately it's about "being agile" (using the definition, characterized by the ready ability to move with quick easy grace), rather than "doing" an agile process.