Several years before, two senior managers couldn't agree on an approach to access the database, so they formed two competing teams and implemented their respective ideas. By the time I arrived, the multiple library calls were entrenched in the product, and customers weren't happy because the calls to the database were different. Likewise, the developers were unhappy because it was difficult to incorporate new features into the existing, disparate calls. So they simply kept creating new calls. When my engagement ended, sales were down, staff cut, and the company was trying to recreate itself. It now has new management and a new look for its legacy products.
The competing teams contributed to AVS's stumble. Customers depend on companies to be consistent with their products, and AVS's product was inconsistent.
I've also done some consulting at a large insurance company that has a huge Agile program aimed at unifying all products under one umbrella to let agents sell anything, anytime, anywhere. The project teams at first refused to synchronize their iterations. Some teams wanted two-week iterations, some wanted three-week ones. After several iterations, it was clear the program wouldn't meet the first deliverable, so the program manager mandated that each team move to two-week iterations and synchronize their work. They finally released the first chunk--a month late.
A senior VP estimated the company lost up to $100,000 per business day that the system was late. That's a cost of $2 million for a one-month slip. That's a high price to pay for teams that couldn't agree on iteration length.
Sometimes it's difficult to separate technical teamwork from bad architectural and requirements decisions. But those decisions are part of teamwork, too. When we don't pay attention to teams and how they work, we risk alienating customers, losing business, and being unresponsive to the rest of the organization.
Johanna Rothman is a management consultant and author of Behind Closed Doors: Secrets Of Great Management.
.svg)
.svg)
