Archive for August, 2008

What is Lean? And Agile?

August 25th, 2008

In my recent readings about Lean, I’ve found a very informative table, which tried to clarify the myths around what is and what is not Lean, and contained the following information:

Myth – What TPS is Not

  • A tangible recipe for success
  • A management project or program
  • A set of tools for implementation

Reality – What TPS is

  • A consistent way of thinking
  • A total management philosophy
  • An evironment of teamwork and improvement
  • A never-ending search for a better way

Despite Lean not being a set of tools, all we see in the IT industry about it is a lot of … tools. Cycle-time, kanban, flow, pull systems, you name it and someone has already announced it as the latest solution to software projects.

I’m not saying that this tools won’t help us developing sotware, but we will sure miss a lot from what Lean has to teach us if we don’t start thinking about principles, i.e., the second part of that list, the philosophy and the thinking.

And if you start to think about Lean principles, you’ll see that they don’t differ much from the Agile ones (at least what I think about Agile :-) ). If you read about an environment of teamwork and improvement, can you tell if they are talking about Lean or Agile?

But again most people, when thinking about Agile, think about practices and not principles. Instead of being collaboration and communication, Agile for them is pair programming, iterations and retrospectives. And this is where I think the solution is. Stop thinking about what is the next set of tools that will make us better, and start thinking about which are the principles we are following and how to better apply them.

About Retrospectives and Accepting Criticism

August 18th, 2008

I believe the most important point in any agile methodology is the possibility of improvement that is offered to the team through constant feedback and also practices like retrospectives.

However, I notice that sometimes teams are not used to question their own behavior, and make the same mistakes over and over again. This was also brought to my attention in one of the mailing lists I participate, where was questioned if teams do enough continual improvement.

These days, while reading the Toyota Way, I got some better understanding about it . According to the author:

Teamwork never overshadows individual accountability at Toyota. Individual accountability is not about blame and punishment, but about learning and growing.

And more important, in the words of Andy Lund, who is a program manager at Toyota and grew up in Japan:

People who have not been to Japan may not understand that the objective is not to hurt that individual but to help that individual improve – not to hurt the program but to show flaws to improve the next program. If you understand that deeply, you can get through that constructive criticism. No matter how good a program or a presentation someone makes, we believe there is always something that can be improved, so we feel it is our obligation. It is not an “obligatory negative”, but an obligatory opportunity to improve–it is the heart of kaizen

And that is exactly what happens in practice. People interpret suggestion and observations as negative criticism, and don’t see that the only way for a team to continually improve is to continually question its own behavior and face its weakest points.

Cheers.