Why Enterprise Agile Teams Fail

Sam McAfee
Feb 18, 2018 · 11 min read

Last week, I was standing in a conference room at a $20 billion company, facilitating a workshop on Agile. The group in attendance was made of the directors and line managers of each function in just one product line within this giant company. These dozen or so leaders, selected from UX, Engineering, and Product Management, represented a broader team of about 150 others who work on this product line. As a unit, they have recently embarked on a journey to become “Agile.”

This is not an Enterprise Transformation situation. They have neither explicit support nor discouragement from senior executives. The official corporate attitude on Agile in this company is best described as benign indifference. So, they are more or less on their own to try it and either succeed or fail.

The only reason that I was there, as is pretty typical for me, is that it was not going well so far. My role was to help them figure out why, and get them unstuck. As it happens, they are failing for the same list of reasons as every other team I have met with in the last 5 years.

Here are those reasons. For simplicity, these are written as blunt, matter-of-fact statements. Not all will apply to your situation.

1. There is no clear vision for the product.

The “idea” has been handed down by some senior executive based on an epiphany during a leadership retreat. It got thrown into a Thunderdome-like budget planning session, and this particular executive won the influence battle and got their pet project funded for 12 months. The news was delivered to you as a fait accompli Power Point presentation with all the resources, features, and timelines planned out in advance. You were told effectively just to “go build it.” Now you’re trying to pull off that impossible task, and hoping Agile will help you.

Solution: Spend some time articulating a clear vision statement for the product. Use a business model or lean canvas to capture your assumptions. Invite everyone on the team to participate. Take those assumptions back to the senior executive (if they refused to attend themselves) and make sure you’re on the same page.

PS: If they bite your head off, give me a call.

2. The business metrics are obfuscated.

If you were to ask most startups, they have a much better idea of their overall burn rate and sales performance, because revenue and profitability are always top-of-mind. That’s rarely ever true in enterprises.

It’s not that hard to calculate in any case. In fact, when pressed, line managers can usually come up with an accurate figure for the burn rate of their engineering team in a few minutes. When we then compare that figure (what we actually cost) to our current sales figures (what revenue we’re actually generating as a team), it’s a whole new ball game.

Solution: Calculate the revenues and costs of your team that are required for your product to be successful, and make sure everyone knows it. It can be pretty eye-opening. You should try it with your team at the next planning meeting.

3. You keep interfering.

In any case, if you’re breaking the flow on a regular basis, you are causing an enormous amount of stress on the team. That stress translates into slower throughput, lower morale, higher turnover, shipping delays, shoddy workmanship, and general drag on the team’s performance.

So, cut it out. You don’t get special privileges in the prioritization scheme just because you’re more important on the org chart.

Solution: Allocate some capacity each week for unplanned work, say 20% of your total capacity. That means, only schedule 80% of your team’s time and leave the rest unscheduled. This capacity can be deployed in the event of “emergencies” without impacting the schedule. Use it to pay down technical debt whenever it goes unclaimed. You can rotate team members to do this.

4. Your teams are not dedicated.

This. Doesn’t. Work.

Agile teams must be dedicated. How many startup teams do you know of where half the engineers are working at some other startup 50% of the time? I’ll answer for you. NONE!

Product development is a team sport. It takes an extreme amount of focus and a lot of communication and coordination between team members. Every person on your team, that also is assigned to some other project for part of their time, is adding significant delay to the ship date, measured likely in weeks or months.

And since I get more push back from enterprise managers on this point than any other, I will give you a concrete example:

You ask, “Do we really need a dedicated UX person on the team? What if they are idle half the time? Aren’t we wasting money?” Admit it, you’ve said that before.

Let’s think it through.

You have ten engineers and one interaction designer (you shouldn’t have this 1/10 ratio, but you probably do, so we’ll just go with it). The designer builds the wireframes for the engineers to implement, let’s say 100 of them. Now you have 10 engineers cranking away, and the designer goes back to their other projects.

Almost immediately, an engineer needs clarification. They put in a request to the designer, but the designer is tied up so the engineer has to wait (delay). Maybe the engineer opens another task and starts working. When the design comes back online, the engineer will have to set down that second task to reopen the first (delay).

Now, a second engineer needs help. And possibly a third. They are both waiting too (delay). The designer becomes available again and starts working with first engineer, while the other two wait in line (delay). The tasks of the second two are sitting unfinished (delay). All three engineers have lost some of the context of what they were working on (delay).

In working with the first engineer, the designer discovers an error in the design and needs to update all 100 wireframes (big delays). Every engineer now has to stop and recheck their work against the new designs (big delays). Some work already done has to be scrapped and started over (bigger delays).

Are you getting the idea, or should I keep going? You can swap the designer in the example above for a backend API developer and it gets even worse.

Solution: Organize into small, cross-functional, dedicated teams. Work on a small set of tasks together as a unit, and get feedback and clarification from each other continuously.

5. Your teams are not colocated.

What happens as a result is a lot of waiting and miscommunication. The fidelity of communication remotely is never as good as face-to-face. Video calls do make it a little easier, but it’s not the same as being able to walk over to the whiteboard together and hash things out.

Solution: Put all of your team members in the same room, or at least the same floor of the same building. If you must work with remote people, break up tasks according to Conway’s Law, meaning divide geographically by component (modules with clearly defined interfaces) not by function (design, engineering).

6. Your team is too big.

100 engineers to build a SaaS product? Seriously?

Larger teams are slower because the coordination costs are immense. You need more layers of management, more meetings, and more documentation. The negative effect of a large team on its speed gets worse asymptotically as it grows.

Solution: You should use the smallest possible team you can to build products in enterprise. If you can get it down to a couple dozen, or even one dozen, you are doing great.

7. You have too much technical debt.

This is because, despite the 15 years of repetition by the Agile community on the importance of the technical practices of (1) pair programming, (2) test-driven development, and (3) continuous integration on the quality of code, very few enterprise teams actually do any of these things.

For a variety of reasons (having mostly to do with the sale of “Agile” to executives by big consulting companies that focus on the process but not the technical excellence), enterprise Agile teams rarely have embraced the core technical practices that make Agile so great in the first place.

As a result, you have large engineering teams cranking out poorly designed and executed systems, and then crashing into each other during their long and painful release cycles.

Solution: Employ “Extreme Programming,” basically. Use the technical practices of Agile, for Pete’s sake!! Further, use the modern technology tools and languages that are built with Agile in mind. If you’re too concerned about risk to use these new tools because “we’re a public company”, well, Amazon is already crushing you. Good luck with that.

8. You are doing too many things at the same time.

You’d be a lot better off limiting your iterations to a few key features that everyone on the team works on together. In Kanban language, we call this “Work in Process” (WIP) limits. In essence, you create a more collaborative environment by forcing a number of people to work together on the same items. No one is allowed to start a new thing because of the WIP limits.

The results are fewer things at a time done better and faster. More teamwork and collaboration. Higher quality and higher morale. Less rework and fewer mistakes.

Solution: Immediately implement WIP limits. If you have a 10-person team, set the WIP limit to 5 items so that everyone is forced to pair up with someone else. Trust me, you’ll be amazed.

9. It takes too long to deploy new software.

Again, while you are wringing your hands about letting mere mortal engineers deploy their own code to production, companies like Amazon are rapidly stealing your marketshare. You may want to weigh the risk of opening up production access to the engineering team with the risk of going extinct in the marketplace because you’re too slow to respond to competitive threats.

Solution: DevOps. Any engineer should be able to spin up new development and testing infrastructure at any time. Pushes to production should go through an automated process that has all of the necessary testing and provisions.

10. The rest of the enterprise is oblivious.

There needs to be a way of working with groups outside your team in a way that doesn’t totally screw up your efforts.

We’ve been noticing in the Agile community that top-down, commands delivered from the C-suite, Agile transformation doesn’t really work. That’s because unless people on the ground are bought into and excited about the change, it won’t stick. And neither does bottom up, without executive support.

Solution: You have basically three strategies for dealing with Agile to non-Agile translation, and you need to do all simultaneously.

  1. Wage an ongoing influence campaign within your organization to win key high-level supporters. I guarantee that there are other executives and managers in your enterprise who are also trying, or thinking about trying, Agile at some scope or scale. Go find them and make alliances. That is, after all, how things happen in large human institutions. Corporations are no exception.
  2. Figure out what you need from the non-Agile functional groups in your organization, and make sure you talk to them ahead of time. Tell them what you’re doing, how it works, and most importantly — how it will make their jobs easier to work with you in the way you’re asking.
  3. Ruthlessly cut your dependencies. This part is more or less under your control. Push for using tools, infrastructure, marketing materials, legal language, or whatever, that you and your team can build, borrow, or buy on your own. It will take time to get this going, so you should start immediately.

Agile, Done Right, Is Awesome

If you want to get help, I am always interest in a coffee or a phone call. Drop me a line.

Be a better technology leader

Learn to apply these skills in the context of your organization. Check out the Startup Patterns master class on technology leadership. We cover topics like how to discover and pursue your purpose, effective communication, how to manage up to executives, and how to lead change in an organization using influence rather than authority.

Startup Patterns

We help develop better technology leaders and build…