Why Enterprise Agile Teams Fail
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.
If you stopped any team member in the hallway and asked, “what is the long term vision for our product,” would they be able to articulate it in one or two sentences? Of course not. They may know a bit about the target customer. They can certainly pontificate knowingly about the features of the solution. But can they really say what pain point the customer has that they are trying to solve? I would guess not.
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.
The team doesn’t think about costs and revenues on a daily basis. In fact, the team probably doesn’t know how much it costs the company to keep them all working there. They don’t know how many customers they need, paying how much per time period, in order to break even on this crazy idea. Basically, they don’t think much about where their salaries come from.
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.
When was the last time that you interrupted the normal flow of work because of some urgent change in direction. It could be anything from a recent customer complaint or request, to a strongly worded email from the CEO about the color scheme used on last week’s product demo.
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 is a biggie for me. Every large company I work with has this problem. Most people on a project are assigned to multiple other projects. When I ask who is on the team, I get answers like engineer So-and-So is 50% allocated, and engineer What’s-her-Name is with us 20% of her time. More than half of the people on the project are spending more than half of their time on other projects. No wonder it’s a train wreck!
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.
Large enterprise teams tend to be composed of “resources” (please, shoot me for calling people “resources”) from a large geographically distributed pool. As a result, enterprise product teams have members in different timezones. This makes coordination very slow and expensive. The example above could be easily written as an example across geographic zones.
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.
It’s typical to find massive teams in enterprises building products that frankly are not that sophisticated. The teams are that large for a variety of reasons, mostly having to do with the fact that executives tend to build their egos around commanding large groups of people.
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.
Enterprises tend to have a lot of older codebases. However, this isn’t the real reason why technical debt accumulates for Agile enterprise teams. I’d wager that most of the technical debt in your current project was put there by your team since the beginning of your current project, rather than inherited by using older legacy systems.
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.
Right up there with dedicated teams is the criticality of doing a few things at a time and doing them very well. Most enterprise teams, probably because they have too many people, tend to be working on dozens of features all 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.
Connected to the problem of those legacy systems most enterprises have lying around is the problem of lengthy deployment. Enterprises usually have an Operations team that is responsible for shepherding the code to production. These folks are trained in making sure code is secure, performant, and functional before it is approved to live on company servers.
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.
And finally. Your “experiment” in Agile, so important to you and the team, is completely off the radar to any number of critical functions that you will need in order to get your work done. I am talking procurement, legal, marketing, HR, and so on. If you have to coordinate with a non-Agile part of the organization in a timely manner, you’re in for a world of hurt.
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.
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.
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.
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
No, you’re not crazy for trying this. In fact, I’d argue that it is the only way you are going to get your company into the competitive position it needs to be for the next generation. The alternative is slow — or fast — death at the hands of smaller, more nimble competitors.
