Saturday, October 25, 2003

TOC World 2004

The TOC World 2004 conference will be held from April 13th to April 16th in Uncassville, Connecticut, USA. If you would like to attend and would like to see me present my software engineering material at this event then please fill in the “What you would most like to see at TOC World 2004” section of this form and show the organizers that their is an interest in a TOC solution for software engineering and agile software development. Hopefully if there is demand AGI Goldratt Institute might invite me to speak.

TOC at Boeing

An interesting white paper titled “TOC Project Management in Aircraft Assembly” [Registration Required] about how Boeing is using TOC, has been made avilable by the AGI Goldratt Institute. The article looks primarily at the deployment of Critical Chain scheduling and Earned Value metrics between Spring 1999 and Fall 2000.<!—StartFragment—>

In this paper, Dave shares the dilemma of needing to quickly improve schedule and cost performance, yet not wanting to lose ground introducing a new, but unproven application of TOC Project Management (TOC PM). He tells of managers, schedulers and workers who make the tough calls against established practices as they pilot TOC PM in the factory on an EMD program - and gradually implement TOC PM factory-wide. Dave describes the meaning of the logistical and cultural changes required to make the program successful. Ultimately, the factory makes TOC PM, Lean Manufacturing and Earned Value Management System work together.

Thursday, October 23, 2003

Chapter One - Theories

Chapter 1 is intended to lay out the theories which are discussed throughout the rest of the book. It leads off with Dilbert (from March 14th 2003) being asked by a customer to start delivering “just in time”. Needless to say the hapless customer is rebuked. A very brief history is then given of the Theory of Constraints, Just-in-Time, Quality Assurance (Deming), Total Quality Management, Lean and Six Sigma along with a comparison chart. Eli Goldratt’s theory on the 3 phases of evolution in scientific development - classification, correlation and effect-cause-effect - is explained.

It then takes a look at some topics which have been actively debated or promoted in the agile community recently. The definition of empirical versus defined processes is examined along with their relationship to chaos theory. Systems Thinking is introduced and Complex Adaptive Systems (CAS), a.k.a. Emergence is described.

The chapter concludes with a summary. Agile management techniques must cope with uncertainty - software development is an uncertain business but not necessarily chaotic. It suggests that “delaing with uncertainty” be achieved by using the principles of TOC, Lean and Quality Assurance. Agility is delivered through a focus on quality, reduced work-in-process inventory, focus on system bottlenecks and reduction of variance. Agile management methods are methods of empirical control but this does not mean that agile software development is necessarily chaotic or constantly on the edge of chaos. In CAS terminology, agile software methods are adaptive systems which exhibit emergent properties - e.g. standup meetings, burndown charts - and desired adaptive behavior - working code. Chapter 2 takes up this system theme and goes further…

Wednesday, October 22, 2003

Maturity and Measurement

Mary and Tom Poppendieck seem to agree with me that the most important measurements in agile software management are the inventory of work-in-progress and the lead time to complete that work. “Agile Management…” Chapter 5 - Software Production Metrics - gives a full treatment of this topic.

Mary and Tom also agree that abstraction is the important route to simplifying what we do as managers. However, their essay, Toward a New Definition of Maturity does have a major flaw in the foundation of its argument - the use of Miller’s paper from 1956 “The Magic Number Seven Plus of Minus Two : Some Limits on our Capacity for Processing Information” and his discover that “short term memory” can typically only hold 7 items +/- 2 - which they suggest affects our ability to analyse things and is limited by this short term memory, which psychologists now refer to as “working set memory”.

This really is a stretch of the original work. In fact, Miller references work by Bousfield, which I also referenced in “Agile Management…”. Bousfield showed - 1 year earlier in 1955 - that humans had trouble categorizing random words into more than 6 categories. There are later studies to show that people become attached to these categories and find it impossible to change them. The common language expression for this is “pigeon-holing”.

To quote Miller’s final paragraph from his paper,

And finally, what about the magical number seven? What about the seven wonders of the world, the seven seas, the seven deadly sins, the seven daughters of Atlas in the Pleiades, the seven ages of man, the seven levels of hell, the seven primary colors, the seven notes of the musical scale, and the seven days of the week? What about the seven-point rating scale, the seven categories for absolute judgment, the seven objects in the span of attention, and the seven digits in the span of immediate memory? For the present I propose to withhold judgment. Perhaps there is something deep and profound behind all these sevens, something just calling out for us to discover it. But I suspect that it is only a pernicious, Pythagorean coincidence.

It seems that our ability to categorize and abstract and the number of elements in our working set memory are probably only coincidentally related. I’m not aware of any paper which has more recently proved a link between these two.

So does this invalidate what the Poppendieck’s are saying? No, not in the slightest. The metrics suggested are the right ones. It is simply the case, that they need a better way of articulating why abstraction is difficult and why Systems Thinking is difficult. Dr. Miller doesn’t have the answer.

Tuesday, October 21, 2003

Replacing Metaphor with Shared Vision

I’m sitting at ForUse2003 listening to Arlen Bankston of CCPace who is presenting “Can Designers Dance? Surviving Agile Teams and Astringent Customers”. Arlen has been working as a ui designer with XP teams.

He has found a good way to avoid confusion with metaphors. The XP metaphor might pollute thinking on the ui design. So he has dropped metaphor from the method and replaced it with shared vision - one of Peter Senge’s 5 disciplines.

The specifics of the shared vision are a Visual Vocabulary diagram and usage-centered design role models and task cases.