In the spirit of becoming more adaptive, organizations have rushed to implement Agile software development. But many have done so in a way that actually makes them less agile. These companies have become agile in name only, as the process they’ve put in place often ends up hurting engineering motivation and productivity.
Frameworks for adaptive software development like Agile have been around for a long time and have manifested in many forms. But at the heart of most of these models are two things: forming hypotheses (e.g., what is a feature supposed to accomplish) and collaborating across domains of expertise on experiments, all in the spirit of driving learning and not careening down a path that proves to be incorrect.
When Agile software development was born in 2001, it articulated a set of four critical principles to elevate the craft of software development and improve engineering and product manager motivation:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Over the last three years, in our research on human motivation, we have analyzed the practices of engineers across over 500 different organizations using a combination of survey-based and experimental approaches. We’ve found that what happens in practice wildly departs from these stated principles.
Read our full article in the Harvard Business Review to learn why agile goes awry - and how to fix it.
