Plan Do Check Act – it didn’t come from Deming

Plan-Do-Check-Act Deming circle, also known as...

Plan-Do-Check-Act Deming circle, also known as the Shewart cycle, since Deming claimed he took the idea from him. Later Deming changed it to be Plan-Do-Study-Act, but the first version seems more popular and has become the defacto standard. (Photo credit: Wikipedia)

Walter A. Shewhart

Walter A. Shewhart (Photo credit: Wikipedia)

We’ve all seen PDCA – the famous process control cycle. While delivering a Product Owner Class at our offices in New Jersey, the home of Bell Labs, I learned something I didn’t know about PDCA. One of my colleagues pointed out that W. Edwards Deming was NOT the inventor of it! I had been attributing PDCA to Deming. It is often referred to as the Deming Cycle or Deming Circle. The person who came up with PDCA was Walter A. Shewhart. Dr. Shewhart worked at Bell Labs! I’ve always been impressed with the innovation at Bell Labs, so learning about the origin of PDCA was particularly satisfying.

Shewhart was also credited with the statistical control chart and the distinction between assignable-cause and chance-cause variance. These ideas go to the heart of LEAN manufacturing, and ultimately, Agile development. For example, the notion of work loading assumes that chance-cause variance is not removable, and as a result, we engineer throughput to take chance-cause into account, and simultaneously use PDCA to remove assignable-cause variance. And we focus on adjusting the process to remove assignable cause variance.

PDCA is sometimes misapplied. We plan a whole release,, we do a whole release, we check a whole release, and then we attempt to improve the whole release. Instead, applying PDCA on increments of a release brings us closer to the ideal of continuous improvement. Shewhart introduced this idea during the development of telephone transmission systems.

Is Shewhart the real father of LEAN?


A-TDD applied to a Congestion Control feature for Telecom & Data Networks

Congestion Control is a common telecom and network application to manage overload of data traffic through high-traffic Network Elements (NEs). Some slides offer an example of how to use A-TDD to decompose the requirements into User Stories, and develop scenarios for Acceptance Test in large, complex product development. You can find the slides on SlideShare here.

A-TDD Research in Large Scale Complex Product Development

At the TDD workshop at ICST in Paris on April 10, Catherine Louis and I will invite collaborators to launch a study on A-TDD in large scale, complex product development. There is very limited research on Acceptance Test-Driven Development in Large Scale product development. By collaborating together we hope to:

  • Find new and Innovative ways to introduce A-TDD into Large Scale Complex Product Development
  • Maximize your chances of Success with A-TDD introduction in your development practices.
  • Explore the frontier of Change adoption

Our goals:

  • Collaborating on a framework for introducing Acceptance Test-Driven Development in large, complex product development
  • Iterating and improving on that framework
  • Publishing the resulting research, identifying all critical success factors.

You can find additional information by downloading our invitation here. If you are interested in collaborating or would like more information, please contact us:

Catherine Louis: – Web site:
Raj Mudhar: – Web site:

“Collaboration breeds Innovation!”

3GPP LCS Feature example using Component versus Agile Feature Teams

Feature teams as opposed to component teams allow you to organize in a way that maximizes architectural integrity and business value demonstration at the User Story level, and ultimately, at the feature level. Check out Catherine Louis’ slides on how to organize around a complex, multi-network element feature in the telecom domain. Really great work. You can find them here.

Thanks, Catherine, for sharing!

Launching an Agile Pilot

So you want to launch an Agile Pilot?

Taking the first steps are often the toughest. An Agile implementation is not proven in your own organization and it is difficult to know if the benefits can be real and lasting.

The following are some suggestions to consider when embarking on a pilot. They are taken from various sources including Mike Cohn, Jeff Sutherland, informal chats with Agile practitioners, personal experience and various books on the topic of Agile and organizational transformation.

Continue reading