In many modern approaches to work, like The Kanban Method, Lean Startup, Agile Software Development, or DevOps, Feedback is an essential part of the approach.
Sometimes the role of feedback is explicit, whereas in some cases it is more of an implicit assumption that is only visible upon deeper inspection.
The Kanban Method has it pointed out explicitly as (currently) the fifth practice (Establish feedback loops) while the DevOps movement has one of its "three ways of DevOps" dedicated to it (The second way: the principles of feedback) which in itself consists of five principles.
“Let’s have more meetings” – a common misconception
Unfortunately, some of the currently popular approaches have introduced the notion that implementing feedback loops implies having some special meetings for feedback.
Feedback like that, could be a daily meeting regarding the current status of the work – especially focusing on problems or things to solve, or an event-based meetings, like post deployment retrospection.
For example, if you look into The Kanban Method, you'll find a whole slew of other meetings to be held at different cadences to foster more feedback in your work.
While these meetings can be very helpful, they are not at all the best way to get real feedaback, really quick.
The problem with meetings as the primary source of feedback
The trouble with feedback that only comes periodically, and is dependent on human interaction, is that most of the time it comes too late.
Consider some feedback loops from outside the work organization world:
- The speedometer of your car gives you feedback about your current speed – just waiting for the speeding tickets to come in would be way too slow as a feedback loop.
- Or how about another thing in your car that you get information about: the oil in the motor via the oil warning lamp and the oil dipstick. For certain kinds of information the dipstick, at which we look from time to time gives us enough feedback. For the important short-term feedback that the oil pressure is too low, we need faster feedback. That's why your car comes with an oil pressure warning lamp.
How can we crate feedback loops inherent in the ways we work?
What we actually want when we talk about feedback, is usually a very prompt response from the system we are interacting with. This system can be anything from a technical system through a physical system or a mechanical system to a system consisting of people interacting with one another.
One of the best ways to get early feedback is to actually remove inventory.
You may have heard that removing inventory is a central tenant of all the lean approaches, but when thinking specifically about feedback, removing inventory has the added benefit of making sure that we get our feedback earlier.
So really, what we mean by “creating feedback loops” is finding ways to see the final impact of the things we just did as early as possible instead of waiting for the effects to happen somewhere very far down stream.
till next time
I think this is where visual indicators can play a big role. The kanban board (feedback on the flow), the CI build results (feedback on the code quality), test driven development (feedback on the development) etc. They can give immediate feedback without meetings. But scaling that to multiple teams and alignment across the organisation is a challenge.
Post a Comment