Systemic Thinking

Some days ago I read this article about how the credit crunch was explained to the Queen by a “group of eminent economics” (whatever that means).

The interesting part in my opinion is this paragraph, which was contained in the letter sent to the Queen:

“Everyone seemed to be doing their own job properly on its own merit. And according to standard measures of success, they were often doing it well,” they say. “The failure was to see how collectively this added up to a series of interconnected imbalances over which no single authority had jurisdiction.”

If that doesn’t make people believe in systemic thinking, I think this might be a lost cause : )

Lean Lego Game @XP 2009

Next month, Me and Danilo Sato will be presenting the Lego Lean Game ate XP 2009, which will be held in Sardinia.

So, what is it?

The Lego Lean Game is an activity developed to teach people about the basic concepts of Lean thinking in a dynamic and fun way, demonstrating Lean practices in an imaginary production line to build Lego houses.

Why?

The idea came from the fact that Lean is becoming a common term in software development, but many people haven’t been introduced to the concepts that made it successful. This workshop aims at introducing this concepts to the participants, making them understand where Lean comes from, and why apply them in the software world.

Should I Come?

If you are interested in Lean, but haven’t had time to study about it, this is the perfect place for you. More experienced people are also welcome, since the hands-on activity makes you discover many aspects that might have been missed before.

If you want to have a better idea of how it is, you can check this video (sorry for the shaky camera : ) ), from the presentation we made at Agiles 2008.

Hope to see you there!

More!

Since the advent of the industrial age, we have had a terrific word: “more.” It really worked for everything. When our roads became crowded, we built more roads. When our cities became unsafe, we hired more police officers, ordered more police cars, and built more prisons.

This is the introduction for one of the chapters of the book I’m currently reading, Information Anxiety, which talks about how to live in a world where we don’t have time to retain all the data that is thrown at us.

What I’ve found interesting about this sentence is how it can be applied in different areas, from police officers, like stated above, to software development.

It is surprising to see how many people that work in the area believe that a software project running behind schedule can be solved with a simple measure: throw more people in the team.

It is so appealing that nobody thinks it can go wrong, and they often forget to consider some minor points, like:

• time it takes for newcomers to understand the project and its domain
• time it takes for newcomers to know the people in the project
• the decrease of communication levels brought by the addition of new nodes

and more than often, the same persons that believe in this measure forget to take a look at their team in order to really try to understand the root causes of what is happening, in a totally anti-genchi-genbutsu way of solving problems.

In a recent project I’ve participated, 4 persons were added to a 3 pairs team in order to try to increase velocity the team was delivering. Needless to say that in the first week we had a 5-pair team with 4 newcomers, and if you looked at the team room, you could see that in each pair there was one person trying to explain to the other how the system worked.

It is pretty straightforward to understand that the team was in reality less than half strong, and that in the first iteration we delivered…. guess what? Half the points.

So if you are thinking about ramping up, think again, and again, and again, and spend some time just looking at how your team works before you make any decision.

The Forces of Destruction

This post came to my mind while reading this post in Sarah‘s blog .It is not my intention to discuss pair programming (or flying a plane) here, but one thing that got my attention was the mention that there is a culture bias towards single programming, more specifically:

…Gladwell has lead me to start believing that there is a cultural bias towards single programming. Take universities for example – you can be expelled for working collaboratively; individual results count, team work in assignments is often discouraged.

And I definitely agree with it. Actually, that is exactly what Deming says in one of his books. According to him, everyone is born with a power of intrinsic motivation, dignity, cooperation, curiosity and joy in learning, but all these characteristics are consumed by the “forces of destruction” that our present style of rewards brings with it, like grades in school, competition between people and payment for individual performance.

And if we analyze it, that is kind of the funny part (not to say sad…): We teach everyone since primary school how not to collaborate with anyone. Students cannot share their knowledge in exams, are always competing for better grades, and when these same persons start they work life, one of the most requested skills is what? working with teams…

But like this isn’t enough, the same companies that hire employees “who can work in teams” still have individual performance reviews, blame cultures, give individual bonuses and promote managers because of the good performances of his subordinates. And when cooperation is not easy, everyone still wonders why is so difficult for people to work collaboratively.

And coming back to the world of agile software development, this doesn’t stop being a reality. It is not unusual to see teams where only the most experienced people are valued, where project managers have an authority position against the rest of the team and less experienced developers don’t have a say when discussing with more experience ones (and here comes pair programming….)

So, if you really want your team to work collaboratively, think about all the times where you are measuring and rewarding them individually, and stop doing it!

Focus on the Right Point

This post came from a pub discussion with Liz, and actually originated from this thought I’ve been having for some time, an came back in one of my recent readings (not to say also in one of my recent projects)…

I participate in some agile mailing lists, and one question that frequently happens is what I should do about people not showing up/showing up late for the stand-ups in the morning. And normally this comes with statements like: “I’ve tried it all already: waiting, not waiting, punishing late arrivers, making them buy ice cream, etc… and nothing works”

And this situation came again to me mind while reading Ricardo Semler‘s book, Voce Esta Louco! (not published in english so far, but it means You Are Crazy!), when he describes how flexible time was introduced in his company.

To give some context, Ricardo runs Semco, a brazilian company which has business units in a lot of different areas, from shipbuilding to hotel management, but is best known for the industrial democracy that its owner has been implementing since the 80′s.

This particular situation he describes occurred when Semco, in the 80′s, was going to allow production line employees to have flexible work hours, and as expected, most of the top managers were totally against the idea, since it violated a basic principle: for a production line to work, everybody has to be there at the same time.

And ricardo’s answer for that was (free translation):

It’s obvious: if the employees are not working at the same time, the production line stops. We know it, but the adults that work in the production line also know it. And why would they put their productivity and their jobs at risk? If they are not worried about how the production line is, producing or not, then we have a much bigger problem, and the sooner we know it, the better.

And that’s what happened, one day before the program started, the employees gathered and decided what time they would start to work.

But what does this have to do with daily standups? Well, the whole example was to indtroduce the same answer I always give to these questions: if your team doesn’t show up for the standups, you shouldn’t worry about why they are late, but ask yourself why they don’t care. That’s your problem.

Lean Workshop at Agiles 2008

Last October me and Danilo were in Buenos Aires, Argentina, to present a Lean Workshop at Agiles 2008.

The idea came from our perception that despite being one of the main buzzwords in the agile community, Lean and its origins are still a mistery to a lot of people, specially now in the current tool age , where kanban means a card wall with some numbers on it.

The workshop aimed at introducing Lean concepts through a hands-on activity, where the participants had to build a simple lego house in this 4 step process.

• Step 1: “Buy” the Lego(TM) pieces and sort them by color
• Step 2: Sort them again by size
• Step 3: Separate the pieces required to build one house
• Step 4: Build the house and sell it

If you are wondering how that turned out in practice, you can check the video here.

In order to go through all the Lean main concepts, the activity was divided in three phases, being the process executed differently in each one: a push system in the first, pull in the second and a single person workcell in the last.

Before every phase, we introduced the concepts that were going to be applied, and after the production, a “retrospective” was held to discuss good and bad points of the process according to the participants.

This way, we could stop and explain the needed concepts between each phase, and were able to go through push vs. pull systems, waste, kanban, kaizen, and work cells, among others.

The feedback we got was very good. All the participants we spoke to later said it was easier to understand what we were talking about when they actually implemented the ideas in practice, and felt the problems that each solution had.  What also helped is that most of the participants we’re being introduced to Lean, and this was the exact kind of public we had in mind when we prepared the workshop.

After the activity, a link with software development was made, but always making clear that creating software is not producing cars, so it is much more important to understand the principles then to apply the practices.

Cheers,

Francisco

What is Lean? And Agile?

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

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.

“Tell me how you’ll measure me…” (2)

Coincidence or not, after writing the last post, I’ve just received the InfoQ newsletter, which contains this article, about bonus distribution within agile teams. And what does it have to do with measures and incentives?

Well, if you want to have some great individuals, reward them based on individual performance, if you want a great team, don’t try to establish some weird criteria, and measure everyone’s performance based on the team result.

Like Mary Poppendieck cited on her book, distribution of bonus to an Agile team is like playing with dynamite.

Lean no MIT

Pra quem ainda não conhece Lean, ou acha que não é serio, tem uma lista legal de artigos nesse post, que são alguns dos que fazem parte do MIT Lean Advancement Initiative (LAI).