Here is an excerpt from an article written by Lindsay McGregor and Neel Doshi for Harvard Business Review and the HBR Blog Network. To read the complete article, check out the wealth of free resources, obtain subscription information, and receive HBR email alerts, please click here.
Credit: DUAL DUAL/GETTY IMAGES
* * *
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.
Agile software development
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.
For example, in common practice, processes and tools have become the driver of work, not individuals and interactions. In one large Fortune 100 company, the head of digital products said to us, “we’re not allowed to question the Agile process.” In another Fortune 500 organization, product managers and engineers communicate exclusively through their tools, which are used primarily for the former to issue commands to the latter.
Similarly, documentation often trumps working software. In one large tech company, their product team focused significant upfront time writing small requirements (called “user stories”). These requirements were put into a ticket queue as tasks for the next available engineer to start working on. The bar for documentation to keep the queue moving became high. Ultimately, this process became one of many small “waterfalls,” where work is passed from a product department to designers to engineering. This process is exactly what Agile was meant to eliminate. It is no wonder that the CTO of this company said, “my engineers feel like short order cooks in the back of a diner.”
* * *
Here is a direct link to the complete article.