Can we apply DevOps principles to Project Management?

It is always worth remembering that good ideas are contagious. Other minds have wrestled with problems similar to yours before and effective solutions tend to bubble up and can be re-applied to new initiatives in ways that can often appear obvious in hindsight.

Or at least that was the feeling I had when reading a recent article on the benefits of DevOps. There seems to be little argument that DevOps adoption leads to;

As it happens, these are exactly the same outcomes we have been striving for in our efforts to disrupt project management. So, does it then follow that if we apply DevOps principles to project management, we might see similar benefits?

The short answer, I believe, is “Yes”.

To give context, in recent months, I’ve been speaking to dozens of engineering and project leaders about their approach to managing projects and in particular monitoring project status. The consistent message I hear is that this is a pain point and a key source of stress, excess effort and miscommunication.

There is a shortcoming with exiting solutions. Currently, we capture a lot of information, but it is trapped in different systems and despite the considerable effort expended it is still hard for the extended team to see how things are actually going and react accordingly. In short, the information is neither easily available nor actionable. This results in a string of avoidable problems up to and including missed, or degraded, deliveries. All of which results in unnecessary stress that is caustic to team health.

For some reason, in today’s agile world of continuous integration and delivery, we still batch project level issues and treat them in an inconsistent “waterfall” manner often after the problems have had a chance to escalate.

What we are missing is a simple, common signal that indicates project status and team health that can be updated more or less continuously, and is clearly visible. So the team itself can make small frequent adjustments to adapt to problems as they are encountered. Project stakeholders would have better visibility and be able to lend support more effectively and other teams can both see what’s happening and share their own signal to highlight dependencies and enable better cross-team collaboration.

To get started we needed to greatly simply project status reporting and find a common framework applicable to different teams with diverse goals and composition. Reducing the problem down, at a fundamental level every team has two aspects we’re really interested in;

We can use these aspects as a common framework. Once a goal is defined we believe the best way of establishing the likelihood of success is to simply ask the team. This might feel like an over simplification, but leveraging the wisdom of crowds makes even a simple signal from a diverse group surprisingly insightful.

At Genchi we capture the team’s sentiment through an automated, 2-click pulse check (which takes ~2 seconds on Slack). By combining the unique insights of each individual we get a confidence score for the whole team. This is a really useful signal, which reflects the team’s collective best guess of achieving their goal at that point in time.

Like a standup, we recommend checking in daily to keep this signal current and to create a feedback loop so small incremental changes can be made to adapt as the team’s confidence changes when obstacles are encountered, or milestones are reached. Also as teams don’t operate in isolation Genchi makes it really easy to visualize and share this information with other teams, helping to highlight dependencies and increase communication and collaboration.

We believe this is a new approach that emphasizes simplicity and leverages automation and transparency to create a continuous feedback loop that will remove a lot of unnecessary friction and stress from the system improving team health and leading to better project outcomes.

Seems obvious in hindsight, right? Check out a free trial at Genchi.com.