Lean

My first experiences with Agile/Scrum development date from 2006. The agile manifesto resonated immediately and it was easy to get the software community ‘sold’. The agile / scrum practices such as working in fixed length iterations, frequent demo’s and feedback, fixed budget – variable scope fit very well with the way software engineers think and work.

It was at first surprising (but naïve) to learn that my colleagues in the other functional areas did not immediately see the benefits. Marketing did not like the idea of not getting the full scope committed with guaranteed timing, the colleagues in the test department only wanted to start testing finished features to protect the efficiency of their department. Also the mechatronics and electronics people somehow failed to see the benefits of fixed length iterations and incremental hardware development.

In any business where software is not the end product and the management does not have a software background, the language confusion is substantial and creates misunderstanding.

The “Lean” toolbox does not have this problem. Some of the dogma’s in agile/scrum causing the cross functional objections (like “fixed length iterations” or “variable scope”), are absent. I used to believe that “lean” was something for manufacturing and it could not be applied to R&D. I was wrong. The lean mindset and toolbox is highly applicable to any organizational unit once you “get it”. The lean mindset toolbox and language can be used in all departments at all levels.

At Philips Image Guided Therapy our whole leadership team (multiple levels) was trained in the “lean” mindset and toolbox. We are serious about lean. We adopted lean in finance, purchasing, quality and regulatory, manufacturing and R&D. The benefit of a shared language in all departments helps tremendously with understanding and building on each other.

Where agile has the ‘scrum’ board, the lean toolbox defines practices for ‘daily management’ or ‘communication cells (comm cells) ’. Kris Hoogendoorn describes in his article what applying “lean” brought to his team in addition to applying “agile”.

For me as a manager of multiple departments, aggregation of KPI’s using ‘tiered’ communication cells are invaluable. KPI’s can be aggregated on my own and higher levels. This mechanism provides a way to create insights and focus were it matters for next level senior managers. We have tiered daily management mechanisms in place for multiple business objectives, to improve factory defect rate, field replacement rate, track critical HW obsolescence’s, measure response times to supplier change requests but also for aggregating software quality metrics. Tiered daily management brings great value and can clarify to teams what their objectives are and how they aggregate up towards departmental targets.

Let me conclude by summarizing my “lean” learning’s:

• Start at the top: be serious and train the full leadership team.
• Have a standard, measure the standard, improve the standard. At times of conflict: reflect if you agree on the standard?
• Adopting a lean mindset is more important than the deployment of lean tools and practices.
• When you are not working in software only/dominated environment: favor introducing “lean” over introducing “agile”.

Continuous improvement used to be a ‘buzzword’ for me, management lingo. I believed it was something I already did. Only when I grew to appreciate the lean mindset, it became meaningful. My journey as a lean leader just began…

(this article is best read in combination with Combining Lean with Agile: the developer perspective by Kris Hoogendoorn