Kallokain

I had reason to think about how to design processes recently, and just for fun I drew the Intermediate Objective map you see above. This is a process level IO map. It shows the necessary conditions that must be fulfilled in order to have a good process design. The map is meant to be generic, so you may have to adapt it to fit a special situation. In most cases, it can be used as is. Note though, that one of the necessary conditions for creating a good process is understanding how the goal of the process furthers the goal of the organization using the process. In other words, you need an IO map for the organization (or equivalent) in order to create a good process. I won't write a long-winded article with a detailed explanation of the map, at least not for now. However, if you have any questions, don't hesitate to ask.

Frank Patrick showed this little gem:

Larry Leach pointed to an interesting article about behavior change in individuals and organizations in the CriticalChain group at Yahoo. According to the article, medical research shows nine people out of ten would rather die than change their behavior. In other words, scaring people into eating less junk food, quit smoking and drinking, and exercising more has only a 10% success rate. On the other hand, with positive reinforcement, 77% will change.

You might wish to read this article, by John Seely Brown and Richard Adler, on how we learn. It has sparked a lot of discussion in the blogosphere. Here is a quote: Compelling evidence for the importance of social interaction to learning comes from the landmark study by Richard J. Light, of the Harvard Graduate School of Education, of students’ college/university experience. Light discovered that one of the strongest determinants of students’ success in higher education—more important than the details of their instructors’ teaching styles—was their ability to form or participate in small study groups. Students who studied in groups, even only once a week, were more engaged in their studies, were better prepared for class, and learned significantly more than students who worked on their own. 6 The emphasis on social learning stands in sharp contrast to the traditional Cartesian view of knowledge and learning—a view that has largely dominated the way education has been structured for o

Clarke Ching blogged about the video above. You can also find it on Youtube . I am really glad I live in a country where this is less of a problem than it is in many other places in the world.

Managers like to talk about business value. It usually goes like this: A group of managers sit around a table. It may be in a conference room, around a dinner table, or in a bar. "We must offer more business value," one of them says. Everyone nods in agreement. Then it grows silent. Uncomfortable. Everyone carefully avoids looking directly at anyone else. Finally, someone breaks the silence: "Anything interesting on TV tonight?" Agile software developers caught on to the notion of delivering business value several years ago. As a result, software developers now have the same sort of dead end conversations about business value their managers have, with the same result. I have played this little game myself upon occasion, both as part owner of a consultancy, and as a developer. It always played out the same way. I was reminded about this today when I read an InfoQ article about business value. The article quoted extensively from an article by Joe Little, Toward A Gen

I have been thinking a lot about how to present information about agile and TOC improvement efforts lately. Last night I had a look at some old process data, and had the opportunity to reflect upon a route I didn't take at the time I was involved in the improvement project. The project was switching from traditional RUP-based development to Scrum (with a healthy dose of TOC). At the time I collected the data, from an andon (Kanban board) I had helped a development team set up, the top priority was finding and exploiting bottlenecks in the process. The second priority was reducing inventory (Design-In-Process). Therefore I focused on Throughput and DIP. That was the right decision under the circumstances, and it did work. The manager I worked for had experience with Lean, and had no problem understanding what the development team and I was doing. That particular manager did not need my assistance in explaining what was happening to other managers, but what if he had? Is there som