Tophat: I’m back 🙂
I love control systems. I really love ‘feedback loops,’ which are probably the most popular form of process control systems in our daily lives. The feedback loop is a very common tool for controlling and improving the operation of processes from an automobile on cruise control to software delivery.
The feedback process works by:
- executing the process
- gathering data from the execution of the process
- proposing and applying a process adjustment that should improve the process; goto 1, “closing the loop”
Most users of a process have some expectations around how that process will execute. We might measure the process in terms of effort, cycle time, success rate, throughput, or some other characteristic we care about. When using feedback loops, we gather data about these process execution characteristics and try to improve the process.
DevOps practitioners optimize the delivery of changes from concept to customer. This optimization effort generally focuses on eliminating wasted effort and getting dev/deploy/test/operations process feedback to delivery teams sooner. This optimization is important because high software delivery performance (generally) improves business outcomes.
But where do these optimization ideas come from?
Delivery process improvement ideas rise from the frustration felt by teams executing the process.
Team members usually have the best and richest data about their delivery process. They (have to) work with it all day long. They are also well positioned and motivated to propose improvements to that process.
So if you want to improve a team’s delivery processes, I recommend putting your team in control of improving itself and support the team with practices and resources to help them do that. Of course, this isn’t my original idea, improving how teams do their work is the Third Way of DevOps specifically, and an instance of ‘Continuous Improvement,’ generally.
Chickens without skin in the game, including consultants like myself, can help by making the delivery team aware of known solutions to similar problem. We can also suggest why those solutions might or might not work in the team’s situation. However, it should generally be up to the delivery team to decide when and how to solve problems in their delivery process.
Over the next few posts, I’ll describe some practices that help teams integrate feedback loops into their operational processes:
- Retrospectives: a tool which provides a/the primary data gathering mechanism for the delivery process and team health
- Code Review: a tool for both gathering data and adjusting the software development process (and even team culture!)
- Design Review: a tool for gathering data on a component/system’s fitness for purpose
Whatever happened last week (or month) is done. What can you experiment with this week to make things better?
As always, I’d love to read your feedback. Just hit reply.
#NoDrama
