Blurring the line between software development and operations

There is a lot of emphasis on reducing waste in Lean but one aspect that is as important, if not more, is the drive for continuous learning. So much so that I think that “lean” is a misnomer for a process that fosters a culture where kaizen is the highest order of emergence in the organization that successfully adopt it.

Few years ago, I came to a personal realization that learning is what makes my life worth living (alongside with my family and friends). At the time I wrote an article in which I declared “I learn for a living!” and threw away measurements putting my skills against some kind of grading scale – I realized that such scales turn my goal into a race for an award represented into a grade and take away the intrinsic motivation I feel when I push myself to learn something for the sake of learning and the sense of mastery that follows.

I later admitted that some kind of qualitative assessment can help me push even harder and avoid the trap of being blinded by early success, not realizing the potential in front of me is much bigger than I thought. The key is to set up a positive feedback loop between the motivation to learn and the assessment itself.

In an earlier post about the value of agile, I wrote about the path from cooperation to collaboration for agile teams and suggested a list of metrics that help teams assess their mastery of team collaboration. I have been thinking since about my personal perspective on learning and what makes Agile and Lean processes so successful in helping teams collaborate and overcome even the most challenging problems, improving their efficiency at the same time.

I now know that these processes have put together the right complex mix of tools, metrics, practices and rituals that allow continuous learning to emerge.

While this is not a definitive list and it is hard to hit that place where the team starts collaborating and continuous learning emerges, I hope that it will make you think if your team and organization is striving towards a place where they exist to learn and they learn to be successful:

Self-assessment – I strongly believe that metrics like those I proposed in my earlier article are required for the team to push themselves to get out of a complacent mode in which they feel they do as best as they can onto a path of constant improvement. The key is that teams should measure themselves and don’t get focused on external metrics that measure performance but are blind to opportunities for improvements.

Reflection – The trap with metrics, even those where the team assesses themselves, is that they too easily and too quickly become a replacement for the true goal. Reflection is an important practice that allows your team to look critically at their work and the metrics they use and figure out if they have learned anything about themselves in the past period.

Learning actions – It is no good if one measures something and takes no action to improve that. Meaningful learning cannot be directly measured, therefore you need to ensure that your process allows activities whose goal is acquiring new knowledge to be part of your work. Whether that is in the form of lunch & learns, group code reviews, refactoring user stories, etc., those teams who don’t plan to fill up to the brim for the next iteration and plan “slack” time when they’re not working on features create an environment in which learning is invited and appreciated.

Many Agile and Lean processes embrace the principles of self-assessment, reflection and learning actions, but they’re not prescribing how should the teams implement them. If your team simply follows a certain set of practices without truly understanding their value and the opportunities of continuous learning, you’re at a great loss. Agile or Lean becomes just another misguided effort to produce results.