People working on a product or system might have different interests and motivations. For someone, it might be shipping as quickly as possible. For another, it might be keeping operations stable. For a third, it might be ensuring adherence to some standard or policy. There are many forces at play, potentially in conflict.
These different incentives inevitably lead to friction at work, since the value of some work is assessed differently.
Most IT projects have been traditionally organized so that such frictions arise because activities and responsibilities are silo’ed.
The goal of most agile development practices it actually to reduce such friction by aligning incentives. That is, make teams of people aim at the same goal.
- If you want to reduce bugs and improve quality, make testing part of development. That’s the “definition of done” in agile methods.
- If you want to improve stability while shipping new features, involve developpers in operations. That’s DevOps.
- If you want to make sure developers care about long term maintenance, make teams responsible of components indefinitely. That’s product over project.
The idea is always the same: make the team responsible end to end. The team as a whole share a set of incentives.
Internally, team members might still value some work differently, based on preference or subjective factors. But chances are that the differences are smaller as with silos and consensus is also achieved easier. The context for all team members is the same and discussions aren’t biases due to individual incentives. The big “wall of confusion” between teams silo’ed by activities is replaced by a more balance approaches of simply weighting the pro and cons and commiting to one decision. A lot of the friction goes away.
More
://ewernli 