Why is it that, when I bring up concerns surrounding production efficiency, some people react as if I’m suggesting we return to the abuses 19th century factories? Agile is, of course, focused on delivering value. However, no business can succeed if it squanders money on inefficiency. That is, outcome is critical, and that’s where our planning focus should be, but output is important, too. You cannot improve output, however, by forcing things from outside. Collecting (dubious) metrics and then trying to move those numbers is an actively destructive practice. Instead, we need a way to maximize output in a way that we can effectively forget about maximizing output. We need to set up a humane, but efficient, system that aligns with Agile values, letting us then spend our time planning around valuable outcomes, and if done right, productivity takes care of itself.
One way to do that is to think about waste (in the Lean sense. If you don’t know what I mean when I talk about “waste,” google muda, and while you’re at it, google mura and muri as well). Waste is anything that doesn’t directly put value into your user’s hands. And when I say “directly,” I mean directly. Some meeting that leads to some other meeting that leads to somebody creating an initiative that, eventually, leads to a real improvement is entirely waste.
The most painless way to improve productivity is to remove waste from the system. Don’t focus on metrics. Instead, identify waste.
Waste includes many factors, but they include things like defects (both bugs and technical debt), over-processing (not following the Agile simplicity principle), waiting (on things like unnecessarily siloed skills like testing or UX design—eliminating waste leads naturally to cross-functional teams). Meetings are all waste.
You can’t eliminate waste entirely; our goal is to minimize. Getting a cup of coffee or having lunch is waste (it’s an activity that doesn’t directly put value into your customer’s hands), but it’s necessary. Walking to a meeting is waste, but it’s unnecessary because you can eliminate it by meeting around your desk rather than in a meeting room (or eliminating the meeting altogether).
The next question is: who’s responsible? The Lean answer is: the teams. The notion of kaizen advocates, among other things, that the teams constantly focus on eliminating waste. A defect is a case in point. Defects are waste, and the teams need to figure out how to eliminate that waste by eliminating defects. At Toyota, when a defect is noticed anybody can pull the Andon cord and stop production until the teams figure out how the defect got there and how to change process to prevent the defect from happening again. In fact not pulling the cord is itself a problem that needs to be addressed. Agile teams should work the same way. The only acceptable known-defect count is zero. If defects are in the code, it’s indicative of a process flaw. Figure out how to change your process so that those defects won’t occur again.
Note that there is no jack-booted manager forcing anything on anybody. There’s no Tayloristic “time manger” holding a stop watch and forcing everybody to be “more efficient.” Instead, the teams look at how they work with a focus on improving it. That’s one of the reasons that retros exist. Constantly assessing what you’re doing and improving it is an internal (to the team) process.
Re the people who immediately go to the notion of efficiency-obscessed managment forcing everybody to work harder, that is itself a form of waste. That is, violating the “sustainable pace” principle naturally leads to things like increased defects—waste.
You do not have an Agile organization if management is creating, rather than eliminating, waste by forcing things like overwork. Waste elimination is essential, and it’s everyone’s responsibility.