Sunday, June 25, 2006

Nested Synchronization and Harmonic Cadences

I was reading David Anderson's weblog and his recent entry on good versus bad variation (which references an earlier blog-entry of mine on the same subject). Apparently this was a recurring theme at the recent Lean Summit in Chicago, and the consensus there was:
  • Organizing for routine work: Drive out variation (and automate profusely)
  • Organizing for innovative work: Encourage variation (and collaborate profusely)

One of the links was to Don Reinertsen's website (he is the author of Managing the Design Factory), and at the top of the page was the "tip of the month" for June 2006 on the subject of Synchronization:
The practical economics of different processes may demand different batch sizes and different cadences. Whenever we operate coupled processes using different cadences it is best to synchronize these cadences as harmonic multiples of the slowest cadence. You can see this if you consider how you would synchronize the arrival of frequent commuter flights with less frequent long haul flights at an airline hub.

Also, Mary Poppendieck was mentioning "Nested Synchronization" in the Lean Development YahooGroup while she was working on her latest book Implementing Lean Software Development: From Concept to Cash where she advised to use continuous integration and nested synchronization instead of infrequent, big-bang integration.

I think both of these apply directly to "Lean" SCM!
  • Harmonic cadences address nested synchronization of integration/build frequencies, both in the case of
    1. different types of builds (private build, integration build, release build), and ...
    2. different levels of builds (component builds, product-builds)
    3. and also in the case of connected supplier/consumer "queues" where builds or components are received from an (internal or external) supplier and incorporated into our own product/components builds.

  • Harmonic cadences would also address release cycle planning for a product-line of products that are releases of multiple (internal & external) component releases.

  • Nested synchronization would seem to apply to branching structures where development branches feed into integration/release branches and their relation to mainline branches, and the direction and frequency with which changes get merged or propagated across codelines.

Of course, when you can manage without the "nesting", that is ideal for continuous integration. Continuous integration together with test-driven development seems to approximate what Lean calls one piece flow. An article from Strategos discusses when one-piece flow is and isn't applicable.

In the context of SCM, particularly continuous integration and TDD, one piece flow would correspond to developing the smallest possible testable behavior, then integrating it once it is working, and then doing the next elementary "piece", and so on. This is typically bounded by:
  1. the time it takes to [correctly] code the test and the behavior
  2. the time it takes to sync-up (merge) your code with the codeline prior to building+testing it, and ...
  3. the time it takes to verify (build + test) the result
Working in such extremely fine-grained increments might not always work well if the one-piece-flow cycle-time was dominated by the time to sync-merge or to build+test, and/or if it always had a substantially disruptive/destabilizing effect on the codeline.

In those two cases, if the time/cost "hit" was more or less the same (independent of the size/duration of the change), then since the penalty per "batch" is roughly the same for a batch-size of one piece as it is for a larger batch-size, then it makes sense to develop in larger increments before integrating and committing your code to the codeline.

Monday, June 19, 2006

Agile Metrics in the Agile Journal

The June issue of the Agile Journal is devoted to the subject of Agile Metrics. Check it out!

There is also a review of David Anderson's book Agile Management for Software Engineering. Little did I know that while I was working on the review, David would be honoring me with praise at his own weblog.

I swear I knew nothing of it when I wrote my review, and that David had no knowledge that I was writing the review of his book (much less what I would say in it). We simply share a very deep admiration and respect for each other's work and ideas.

Wednesday, June 14, 2006

Agile Ideation and Lean Innovation?

More on "agile futures" from some of my earlier posts on globalization 3.0 and extreme competition and how the only way to stay competitive will be to innovate faster and more frequently than the competition ...

So does that mean that the "most valuable features" to implement first will be the ones that are considered "innovative"? Before we can execute on doing agile development for innovative features we have to have some kind of initial "innovation clearinghouse" in the organization where we have a buffer of potential innovation idea-candidates. Those "gestational" ideas will need to undergo some kind of evaluation to decide which ones to toss, which ones to develop a business case for, and which ones to do some early prototyping of, which ones to "incubate", etc.

Eventually, I see two queues, one feeding the other. The "Candidate Innovations" queue will need to "feed" the agile/lean software development queue. Things on the candidate innovations queue will have to go thru some equivalent of iterating, test-first, pairing/brainstorming, refactoring, and continuous innovation integration so that the queue can take "raw" and "half-baked" ideas in the front and churn out fully-baked, concrete, actionable ideas to then feed the development queue.

So the one queue will exist to create "actionable knowledge" (ideation) and will then go into the queue that cranks out "executable knowledge" in the form of working software. Given this two-queued system, how does this work where the "software queue" has both a request (product) backlog and a sprint (iteration) backlog. Lots of things on the product-backlog might be viewed as waste. And yet if they have made it thru the "ideation" backlog to produce an actionable concept and business-case, then that will indeed have value (but it will be perishable value).

What would Lean+TOC say about how to unconstrain and eliminate waste and maximize flow of the innovation flow that feeds the agile development flow? (I'm assuming the innovation flow would be a bigger bottleneck than the software development flow)

Friday, June 09, 2006

Extreme Economic Gloom and Doom

According to a number of different sources, the US economy is going to have its bottom fall out somewhere around 2010 due to a variety of reasons that are converging all around that same time:
  • Massive trade deficit, soaring personal and government debt, a housing bubble, runaway military expenditures, and skyrocketing healthcare costs with employers' insurance plans covering less and less these days (the usual)

  • Globalization 3.0 and the commoditization of knowledge-work & knowledge-workers

  • Peak oil supply will have been breached (some say it has already, others say it will happen anywhere between 2004 and 2010), resulting in soaring oil prices (far more than they are today) and the race for efficient mass production & distribution of low-cost alternative energy sources

  • Retirement of the "baby-boom" generation (starting in 2007 and peaking between 2010-2020) and its impact upon social security reserves (because of ERISA) and US supply of knowledge-workers

  • Global warming and depletion of the environment will reach the point of no return sometime between 2010 and 202o (if you believe Al Gore in the recent documentary "An Inconvenient Truth")

  • Likelihood of global pandemic flu (possibly bird-flu, but possibly any other kind of flu) happening within the next 5-10 years, and its global impact on medical and industrial/business supply chains (how far away will we be from harnessing nano-biotechnonology when it hits?)

I gleaned all of this just from browsing a bunch of books on, like the following:

There are LOTS more saying the same things. On the other hand, a few authors hold out hope that we will finally focus on some of the right things (like the environment and alternative energy sources, and turning to nature itself for innovation):

These things are all converging together (coming to a "head") within the next 10 years. I wonder what the state of Agility will be like then ...
  • Will little/no inventory be desirable amidst the threat of global supply chain disruptions due to pandemic health crisis?
  • Or will agile business partnerships and the resulting "agile business ecosystems" somehow be "autonomic" by that time.
  • As for oil and transportation, might not the threat of pandemic flu end up fueling "virtual" travel and telecommuting?
  • Or will that just give people more time to use their cars for non-work reasons.
  • Who will want to go to the mall or the grocery store if they're worried about contracting life-threatening illnesses?
  • What about emerging markets that are going to "boom" but haven't yet? (Many say nanotechnology and biotechnology will do this eventually - but when?)

I won't be eligible for retirement for ~30 years, and within ~15 years I want to be able to finance a college education for my two children (less than 2 years apart in age). All this sort of makes me want to say "Beam me up Scottie!", or "Why oh why didn't I take the blue pill!"

Monday, June 05, 2006

Vexed by Variation: Eliminate or Encapsulate (with TOC+Lean+GoF)

I had some positive feedback on my previous entry about Six Sigma and Good vs. Bad Variation.

The Six Sigma methodology is largely about eliminating or reducing [destructive] process variation. In the case of software design (and what should be the case in software process design, but all too often is not) we recognize that change and uncertainty is inevitable and we use techniques to minimize and localize the impacts of changes. Three of the most common techniques come straight out of the classic Design patterns book from the "Gang of Four":
  • Identify what changes and Encapsulate the thing that varies
  • Program to an interface, not to an implementation
  • Prefer composition over inheritance
These principles could just as easily apply to process design and the design of process-families (a Product-Family or Product-Line for a family of processes). I attempted this in an earlier blog-entry entitled CM to an interface, not to an implementation.

So how do we find this variation, and how to we know what to do with it? Both Lean and TOC give us some tools to do this (as does Six Sigma). Six Sigma's process-maps are similar to (and quite possibly borrowed from) Lean's Value-stream maps. These are one way to form the "current reality tree" of TOC's Thinking Process and then look for things like waste, non-conformance, or conflict (e.g. a "process" impedance mismatch).

When we find something, what do we do? ...
  • If it is waste, we attempt to eliminate it or reduce it using Lean.

  • If it is variation, we should ask if it is destructive variation (causing poor quality) Is the variation the cause of the problem? Or is it the inherent uncertainty and/or our inability to adapt in the face of change?

  • If the variation is destructive, seek to eliminate it. Sometimes automation helps to eliminate variation as long as there is enough certainty in the procedural details and outputs of what to automate.

  • If the variation is not destructive, or if the problem is uncertainty and/or our ability to be resilient and adapt to change, then try to isolate and localize the variation by encapsulating it. Use the GoF principles and patterns to separate policy (process interface) from mechanism (procedural implementation).

  • If the problem is conflict, then look to see if it is destructive or constructive interference, or impedance mismatch.

  • Impedance mismatch needs to be corrected, and destructive interference (friction) needs to be eliminated or minimized.

  • Constructive interference, and possibly other forms of conflict may need to be retained, in which case we would again look to encapsulate the conflict by trying to separate policy from mechanism, or interface from implementation, and discovering the higher-level rules/forces that they still have in common.

In all the above cases, TOC's Five Focusing Steps can help with the identification of the appropriate patterns/practices to apply.

Comments? Did that make sense? Did it seem like a reasonable application of using OOD patterns and principles in conjunction with TOC, Lean and Six Sigma?