The Toyota Way to Lean Leadership

In partnership with George Trachilis from the Lean Leadership Institute (LLI), I’m making available material from LLI’s “The Toyota Way to Lean Leadership” course. Check back every week for a new chapter from the course.

Week 17: A3 Examples: Standards, Standard Work, and Visual Management
Week 16: More A3 Stories
Week 15: A3 Stories
Week 14: A3 Thinking
Week 13: Why PDCA?
Week 12: Problem Solving to Develop People
Week 11: Root Cause Using 5 Whys
Week 10: Toyota Business Practices – An Example
Week 9: Toyota Business Practices Explained
Week 8: Problem Solving Towards Ideal Part I and Problem Solving Towards Ideal Part II
Week 7: What is Lean? Problem Solving, Improvement, and A3 Thinking
Week 6: Developing People
Week 5: Lean Thinking—Philosophy for the Long-term
Week 4: True North Values
Week 3: Toyota Production System Origins
Week 2: Problem Solving: The Toyota Way
Week 1: Great Company Characteristics

 

Misplaced Agile Transformation Priorities

Most companies that I’ve worked with begin their lean-agile transformation effort by attempting to fix/improve the development teams. However, the source of most of the problems lies either upstream (lack of sequencing of work, demand far outstripping capacity to do the work, suspect value of work requestsed, etc.) or downstream (lack of environments, wasteful and onerous deployment processes, etc.) of the development teams. And, of course, management struggles in creating an environment that is conducive for high-performing teams is well known and another area for improvement.

A significantly better approach would be to start with introducing the CALMS conceptual framework (culture, automation, lean, measurement and sharing) for driving the integration of development, support, operations and business. Over time, plan and prioritize initiatives and improvement efforts to move each of the CALMS elements forward. Simultaneously, work with the business and with stakeholders to better define and sequence customer-valued increments of functionality.

You have a higher probability of making meaningful improvements and moving the needle on the busniess metrics that matter by changing your starting point. What have your experiences been?