Agile Transformation Anti-Patterns

About 16 years ago, a group of prominent technologists came together to discuss how to improve the software industry. The result? A document they called the manifesto for agile software development, though you might know it simply as the agile manifesto. A deceptively simple statement, it gave rise to an industry sea change.

Over the following 16 years, agile would, among other things, go from an adjective to a noun in common parlance. No longer would you only describe a person or thing as agile. Now, you can adopt agile or convert to it. Looking for a leg up, companies abandoned the traditional "waterfall" approach in droves in favor of this new way of doing things.

Companies of all shapes and sizes have looked to ride this wave. Obscure shops, world-beating startups, and Fortune-5 companies have all gotten on board. But it's usually at the enterprises exclusively that adopting the agile approach earns the impressive designation of being a transformation.

As you might expect, well-intentioned enterprises have well-documented struggles when rolling out initiatives. Getting dozens or hundreds of people to adopt a new initiative is a tall order.

So what are some of the pitfalls of these agile transformations? What common, predictable mistakes occur? Here are some that I've run across.

Mapping Old Roles to New Ones

At most organizations, adopting agile means adopting Scrum or some variation on Scrum. And Scrum, believe it or not, calls for only three roles on any given team. They are as follows.

Product owner, who manages the backlog and sets the priority of the team's tasks.

Scrum master, who serves as a moderator of sorts, to make sure the team follows the rules of Scrum.

Development team members, who, well, develop the software.

Let's consider some roles that are absent. First, there are no managers of any kind. That means no project managers, product managers, program managers, or anything similar. Second, you have no tech leads, team leads, architects, or similar. And, finally, you don't really differentiate by skill set. The "development team" may be a mix of testers, front end developers, back end developers, etc.

This completely blows of companies attempting these agile transformations. Typically these companies have deeply hierarchical, highly specialized pecking orders. So they wind up mapping this new world to old, comfortable roles.

Scrum master kind of sounds like manager, so let's have the project manager do that. And product owner sounds like the boss, so we'll have the dev manager do that. We'll also have a tech lead and an architect, since, while all team members are equal, some are more equal than others.

It's completely understandable. And it's also a way to virtually guarantee that you don't adopt Scrum as intended.

Absentee or Non-Empowered Product Owner

Now that we've covered the roles involved in Scrum, let's take a look at a problem unique to one of those roles. The product owner has a unique set of requirements.

Scrum operates under the premise that the product owner prioritizes the work. The development team then commits to doing as much of that work in a fixed time interval (sprint) as possible. For this to result in software that users/customers like, the team has to deliver and the product owner has to faithfully represent their interests through prioritization.

The product owner becomes the single, authoritative voice of the product, synthesizing all inbound requests and creating an orderly backlog for the team. In order to do that effectively, the product owner has to be all of the following.

A single person.

Authoritative.

Available to the team.

Some organizations trip up on the very first requirement, creating a disaster in which a committee serves as the product owner. But, more commonly, they struggle with the next two requirements. This happens because at organizations, authority and availability vary inversely. Find an empowered manager, and she sits in meetings all day. Find an available business analyst, and he probably has to clear everything with several bosses.

Organizations often struggle mightily with the product owner role.

Agile as a Meeting Schedule

Enterprises undergoing transformations usually conceive of agile as a project management methodology. They used to do "traditional" development, and then they switched to RUP, then CMMI, and now it's time for Agile. And project management (agile manifesto notwithstanding) means detailed plans, Gantt charts, status reports, and meetings. Lots and lots of meetings.

Scrum calls for certain collaborative "ceremonies," including planning, daily stand-up, sprint demo, and retrospective. These are mainly intended as lightweight affairs to facilitate development and continuous improvement of practices. But organizations often latch on to these like life preservers.

They become obsessed with following protocol to the letter. That, in and of itself, isn't the whole problem, though. The real trouble comes when the organizations focus on meetings and process at the exclusion of the software development practices.

Agile software development isn't just about Scrum, and it isn't just about process. It also calls for development practices that shorten the feedback loop and automate validation and quality concerns. If you're going to ship production software every week or two instead of every six months, you need to change technical aspects of how you work.

But transformations often at ignore this, at their peril. They mistakenly think that they can just have different meetings, and magic will follow.

Thou Shalt Be Agile

The last agile adoption anti-pattern that I'll mention involves a sad bit of irony. One of the main underpinnings of a successful software development team, particularly one practicing an agile approach, is empowering the team to make decisions that matter.

Software development is knowledge work. One of the main failure drivers for large, waterfall efforts was their command and control nature. They involved a lot of management type people doing excessive planning. Management would then hand those plans to architects and tech leads who would, in turn, create even more detailed plans. They'd hand those to senior developers for still more planning, and those senior developers would supervise regular developers doing the implementation.

That doesn't go well because the organization completely separates the power to make decisions from the context that should inform those decisions. High performing agile teams remedy this by empowering the people on the front lines of this knowledge work to make the decisions.

But the enterprise agile transformation often happens via leadership edict from on high. In and of itself, that doesn't necessarily prove problematic. But it does set the tone for all manner of command and control agile. Are you guys doing your stand-ups correctly? Are you giving agile your all? You need to do this the way I say!

Without empowered teams, you really miss the entire point of the philosophy.

Don't Get Discouraged

Why do I list all of these anti-patterns? Simply so that you can recognize them early and attempt to course correct.

Adopting a new way of doing things is hard. Doing it at the scale of an enterprise, coordinating dozens or hundreds of people, is like trying to turn a battleship from a life raft. It's really hard.

The fact that you're making game attempts to improve is a good sign in and of itself. Make sure that you're constantly evaluating yourself and looking to build on that improvement. In doing that, you'll ensure that any anti-patterns you happen into don't persist for very long.