.png)
This week at Haystack, we had a prospective customer reach out to us as they wanted to gain metrics on how they can continuously improve their Software Development Life Cycle, but were concerned by the micromanagement tools offered by their current vendor.
Impact of Project Micromanagement
This potential customer was using a tool called LinearB, a screenshot of what their tool looks like from their marketing material is as follows:
In essence, rather than seeking to improve the Software Development Life Cycle, LinearB offers project managers tools to offers surveillance tooling to provide insights into how engineers are working in an attempt to avoid deadlines slipping.
We have previously written about the studies from Google showing why micromanagement is harmful. This is also reiterated in work in the 2019 State of DevOps Reports showing the key importance of psychological safety in technology teams (backed by ~31,000 different data points from different organisations).
When this micromanagement is conducted by project managers, instead of engineering managers, we also find it is usually is associated with greater levels of stress and distrust between different departments.
Essentially, these tools lead to Waterfall software development, purporting to be Agile software development, with additional stress and hostility within the workplace.
By delivering small sized user stories iteratively, software can be delivered faster and more reliably. Providing Project Managers a tool to micromanage the delivery of oversized product features does little to achieve this.
Without this; Product Managers cannot learn during the product development process, they struggle to ship Minimum Viable Solutions or be able to get early information from customers. Instead they attempt big-bang projects which are likely to fail due to both technical and market implications.
Agile Development
The Standish CHAOS Report identified in 2015 that Waterfall projects are only likely to be fully successful (delivered on-time, on-budget with a satisfactory result) 11% of the time. Agile approaches are more than 3.5 times more likely to be successful and far less likely to completely fail. For optimal levels of performance though, Cycle Time should be cut so product managers can test their ideas in production rapidly and get feedback from the market fast. Product and engineering learn together.
This is only part of the solution though - research, like that found in the Accelerate book, places particular importance on lowering Cycle Time and driving down Mean Time To Recovery.
When instead features can be delivered in short iterations (of less than 1 day in elite performers), Product Managers are instead able to learn rapidly from the real world. They can put things in front of users and learn as they go.
This component of the DevOps revolution is what takes Agile software delivery to the next level.
Make Meaningful Change
Bolting on micromanagement tools abreast a Waterfall software delivery process goes contrary to what the Agile and DevOps revolutions have taught us.
Focus on shipping small, not just because it will allow you to deliver more reliably and faster, but because of the lessons you learn from your users.
β
About the author
