Agile and its many flavors take many of their tenets from The Toyota Production System.
At Toyota, there is a concept of Obeya, or “The Big Room.” Obeya, is literally a large room, where all the critical players can gather and make important decisions on the spot. That room can be considered a project room, or Obeya where concise charts show the state of the project. Additionally, the frequency of meeting is typically every morning for ~15 minutes or less and sometimes the team gathers there when critical decisions are required.
The Agile movement has taken this concept and applied it to developing software. For software, the whiteboard involved typically contains basic things — again, all taken from Toyota:
|Backlog||Requirements Gathering||Ready to Code||Coding||Ready to Test||Testing||Rolled to LIVE|
The above table shows the basic contents of the whiteboard that the team would gather around. The contents would be index cards, showing stories explicting specific features for that iteration. Here are some details:
The backlog takes Toyota’s “Pull” concept. It is a staging area for features, manifested in index cards. The team or product owner determines which features to “pull” into which iteration. The “Backlog” concept is Agile’s version of Toyota’s “Heijunka”, which is production leveling. In other words, instead of new features being placed directly into an iteration, they are placed in the Backlog, which is a way to control variation and level the production.
Iteration in Agile takes Toyota’s notion of one-piece flow, which is also known as take-one-put-one, or single-piece flow. It is an alternative to “batchy” processes and forces the software team to focus for 2-3 weeks on just a few features — from coding to testing to rolling live. This is an alternative to the Waterfall process, which is incredibly “batchy” — batchy processes leads to defects and many other problems.
Agile identifies features, places them in a backlog, then as a team prioritizes those features and assigns them to iterations. So, you may have 3 iterations, each of length of 3 weeks and each iterations containing 10 features for example.
Requirements Gathering and the remaining items are standard.
The White Board & Index Cards
Again, this is copying Toyota’s notion of the Kanban and the notion of the Visual Workplace. It is effective and the whiteboard acts as a living, breathing document showing current status all the time, and what else needs to be done and by whom. It’s very effective.
Once the team has some history in terms of delivering working code using this approach, Agile encourages something called the Burndown Chart, which is, again, taken from Toyota. The Burndown Chart is nothing more than Takt Time. Takt Time comes from a German word “takt”, which means rhythm or beat. Takt time is not the same thing as Cycle Time or Lead Time, though Takt Time has a very real relationship to both. Takt time is measured as (Time/Piece), not the other way around. This is important because the operator knows that he or she only has so much time per x. Similarly, the engineer measures his or her productivity or rhythm via (time/feature) and, again, only he or she knows beat at which he or she can follow. Takt Time can be measured by the following calculation:
Having spent time at Toyota and having studied Lean for several years, I can see how the software engineering world has adopted it wholeheartedly. I have a unique perspective because I developed software for several years and I’ve been in manufacturing, fulfillment, and Operations and even spent time at Toyota. I even still develop software today, but just for fun. I’ve personally found the stand-up to be very effective — both in and out of software engineering. For software engineering, it works incredibly well and brings unity to the team and encourages communication. For non-software environments, I’ve found Obeya to be very, very effective.
If you emjoyed this article, you might also enjoy this interview with Mary Poppendieck, the author of Lean Software Development: An Agile Toolkit for Software Development Managers (Paperback).