There Are Many Ways to Effectiveness: Reflections on the European Lean-IT Summit

November 28, 2012 — Posted by Al Shalloway

I was at the European Lean-IT Summit in Paris last week.  It was a real pleasure.  The highlight for me was listening to Pierre Masai, Toyota Motor Europe’s CIO.  It’s been said that Toyota doesn’t do Agile in their IT organization.  It’s also been said that’s because they don’t attend to IT too much.  Not sure why I ever believed that.  Monsieur Masai devastated that myth.  In listening to his talk, it was clear that Toyota IT is very effective and not a step-child at all.  True, it may not be Agile, but it’s still effective. 

It was clear that,

  • Toyota IT takes an holistic view towards adding business value
  • They have achieved a level of stability needed to coordinate with their hardware folks
  • Sometimes it is better to take a longer term view and get people thinking properly than it is to solve an immediate problem
  • They are very effective, more so than many Agile teams I’ve met.

This got me thinking about what it takes to be effective in software development. I had already seen from my own experience that having cross-functional teams working on one project at a time achieves a 3-to-1 performance improvement over siloed teams. Even when such teams continued to use waterfall.   Agile’s effectiveness is based on feedback, so we clearly we have two different methods here that help:

  1. Use cross-functional teams
  2. Achieve a high degree of feedback in your define and build process so as to be more effective (the essence of Agile methods)

What other ones were out there?  Well, Agile achieves it quick feedback by working on small batches.  This is also a cornerstone of lean and flow. Managing the level of work in progress (WIP) also is important.  So we seem to have 2 other methods to add to our first 2:

  1. Size of batch size (e.g., waterfall is big, Scrum is 1-4 weeks, Kanban can be as short as you like)
  2. Managing Work in Progress (WIP) to achieve production leveling (heijunka)

Not surprisingly, Scrum, uses all four of these.  This is why when you can actually do Scrum, it works. Unfortunately, Scrum only implicitly manages WIP and then only at the sprint level.  Kanban can use all of these, but has some extra flexibility by not requiring cross-functional teams.  More importantly, Kanban explicitly explains why all of these are useful.  Scrum implies it, but doesn’t talk about it (see Why Scrum Works and What This Tells Us About When it Won’t).

The important issue here for me is that we need to go beyond Agile and beyond branding of different methods.  We need to understand why things work.  These methods have a relationship with each other, but none of them are required for effectiveness.   Cross-functional teams can be made more effective if one implements a pull system to manage WIP.  This, however, requires explicit policies, something many in the Scrum community disdain (see The Real Difference Between Kanban and Scrum).  So our belief systems about how things work also have an impact (see Mindsets, Waterfall , 1st & 2nd Generation Agile).

The point is not just what practices work, but how are we putting them together, where we are coming from, what our mindset is.  At Lean-IT I saw that proper mindset and discipline was much more effective than following practices without the bigger picture, business need view.  I guess I’ve been seeing and saying this for a long time, but in Pierre's talk it was even more apparent.

I am reminded that the problem with answers is we stop questioning.  We need to realize Agile has become an answer for many.  And no matter how you hold it, there are aspects of Agile that does imply certain answers.  Then we stop questioning, we stop looking for better ways.  We, ironically, stop being Agile.  We need to look beyond our solutions, even beyond our problems, which subtly define our answers.  We need to remain curious.  We need to remember one of Voltaire’s great insights – “doubt is uncomfortable, certainty ridiculous.”

Alan ShallowayCEO, Net Objectives

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

Hi Alan. This post of yours highlights why I find the Toyota definition of Lean* preferable to Agile or any other as a guiding framework. The pillars of Continuous Improvement and Respect for People built on a base of effective management with all the evolving "science" stuff in the middle seems to have held up incredibly well over the years.

* As reflected in http://www.craiglarman.com/wiki/index.php?title=Lean_Thinking_house, for example

While U.S. car manufacturers foresee a downward pattern in light automobile sales for 2013, Toyota Motor Corp. estimates a year in which it will challenge for the leading spot as the world's biggest automaker. Automotive News reports that demand from overseas markets is forecasted to boost Toyota's sales by 2 percent to a record total. You can get a <a href="http://www.cardealexpert.com/TML">car loan with bad credit</a> for your new Toyota too!

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban