Product teams — agile done right

After transforming management, comes changing the actual teams working on your software. Most organizations think about software as projects: something that has a finite set of requirements, schedule and budget, and a finite end date, the date it’s delivered. There’s some consideration put into updating the software, managing its full life. This project mentality can seem to make a lot of sense, esp. if you’re outsourcing much of your software.

Mark Schwartz calls this project approach the “contractor control” model. His theory is that this model is based on management’s mis-trust of the people doing the work, whether they’re contractors or internal staff. As he outlines in A Seat at the Table, this drives a heavy emphasis on status meetings, compliance, and lock-step road-maps:

How could you control a contractor? You asked for an estimate and pressured the contractor to deliver at or close to that estimate. Or you agreed on a fixed price. How could you control IT? Same model, but with the twist that the IT staff were your own employees who were paid a fixed salary — a bit awkward. Since their cost was fixed (at least in the short and medium terms), your biggest worry was that they would waste time on frivolous activities. How could you know that they weren’t? Simple: you insisted that they deliver on schedule, and kept the pressure on them to do so. Some of IT’s work was transactional: user support, device provisioning, updates, and maintenance. In those areas, costs and lead times could be benchmarked and monitored. But a good deal of IT’s work involved delivering capabilities — developing and integrating applications, rolling out ERP systems, installing collaboration tools, and so on. For IT to demonstrate that it was performing that type of work responsibly and for the business to verify that it was doing so, the scope of each task had to be defined precisely, bounded, and agreed upon in advance. The work had to be organized into projects, which are units of work with a defined set of deliverables, a beginning, and an end. You could establish control by making sure the project was completed within the bounds of its estimated cost and schedule. How perfect the Waterfall model is for this purpose! How perfectly it aligned with the business’s need to know that IT was under control.

The results are predictable: frustrated people, bad software, and slow failure like two drunks in a bar-brawl.

Sobering up starts with two words: product and team. Doing software well requires thinking about it as a product, not an ongoing project. This is how software vendors think, of course: the software they create it what they sell. A product is interested in accomplishing its user’s (and customer’s) goals, ongoing, until it’s no longer needed. A product evolves to match the user’s evolving needs. The focus is on continually making the best software possible.

Product-centric organizations move from the functional organization, contractor control model to an agile, product-centric model.

Read more here