Kanban for Software Development

Last Wednesday I got a full scale indoctrination into the agile software development methodology called Kanban, loosly based on the Toyota Production System (TPS) mechanism with the same name.  Toyota uses the kanban as a mechanism to allow for just the right amount of parts to be ordered and to be delivered just in time (JIT) in order to avoid overproduction and waste in the production line.  Kanban Software Development Methodology (KSDM) brings the same lean ideas to a development team.

Taiichi Ohno Reinterpreted

Taiichi Ohno is credited with the creation of the Toyota just-in-time production system, and his book “Toyota Production System: Beyond Large Scale Production”  is a surprisingly good read even today when many of these principles are considered well established.

My interest was in understanding how this philosophy applies to Agile/Lean Software Development. 

26 Hints for Agile Software Development

I collect nuggets of wisdom on various topics. Recently I have been going over the topic of Agile software development; what really matters?  Below is a list of 26 key principles to guide an agile software development team.

• Get case 1 fully working before starting case 2. Another way of saying this to use a kitchen metaphor is: “Serve the current meal before starting to cook the next“. 

Notes from Keynote at Agile 2009

Find the complete talk, audio/video by Alistair Cockburn with slides on the InfoQ site. I am spending a lot of time on Agile Software Development techniques, and this talk presents a number of important concepts, so I am posting my notes here to help others looking for good materials on Agile software engineering.

Process Language, Agility, and Fitness

When designing a business process, you need to design for change, because business is always changing and agility depends upon the ability to change.  Once you understand that change is a constant part of business, you know that the business process you design today is not going to remain static.

If you are going to design for change, it is important to pick the right language.  If you pick the wrong language, then change will be very difficult.  We say that a language is a good language

Model Strategy, Round-Trip & Agile Development

We often talk about the process “round trip”. The process lifecycle is explicitly about moving the process through different people with different specializations. The business analyst draws a high-level model and the systems integrator includes details for connecting the systems. Another dynamic is the continual process improvement that occurs when you assess how effective the current process is, make a change at the high level, and take that change through the lifecycle again.

Is the BPMN/BPEL Debate a Dead Horse?

Bruce Silver’s latest post “Reframing the BPMN vs BPEL Debate” calls to question whether it is worth continued discussion of the definition of BPM. Like most of Bruce’s posts, it is insightful and well worth reading. This is in response to a post by Boris Lublinsky on “BPEL: Who Needs It Anyway?“

I am a little surprised by Bruce’s response, 

Agile Development – Road Trip Analogy

I needed to describe the reason that an Agile approach to software development works, and why it is not something that is isolated to the development team.  I wrote up the following explanation.  Maybe this will be helpful to you in explaining agile development to others.