Through time we've practiced the Royce Waterfall model of the 1970s, the US and German concurrently derived V-Model of the early 1980s, the Boehm Spiral model of the late 1980s, the Martin Rapid Application Development model of the early 1990s, the Iterative-Incremental model of the early to mid 1990s, and a class of multiple models known as Adaptive Software Development processes in the mid 1990s and thereafter, also known as "Agile". Along the way of course, there are flavors and hybrids of each that show up and disappear all the same such as Double-Vee, Iterfall, and WaterScrum. The most popular frameworks are the aforementioned.

Expectedly, people are the challenging parts of every new idea we bear out in the industry. And as is a normal situation, the problems to be solved ordinarily stimulate the process definition and implementation; and we then rely on people to practice and evolve it. According to my own studies to date, I believe the most notable difference between all historical models and Agile class models lay in a single observation: Agile and its derivations are borne out of trench-level, industry-wide collaborative solutioning with the intent of quality driven, quick to market, customer defined product. Amplified, I believe the flavors of Agile are currently unique to history because of the associative industry-wide, collaborative solutioning. Tersely and for the third time, the people actually doing the work told the industry how to do the work. This has happened before, but not at this scale and has therefore been a watershed event for the community of software engineering. Unfortunately, the class of Agile precepts is just as often misunderstood and misapplied as all those before it. Many people are just doing it wrong which is why consultants will always be employed.

  • From personal experience, I know that some people choose only a few elements of Agile and believe it will integrate cleanly into their existing culture built on an assumption that the culture itself already works and is capable of another fractal characteristic. This is goofy logic and suggests that wearing a rugby jersey makes an athlete.

  • I also know from personal experience that many leaders do not actually understand how to move product to market at all; so another "methodology" as it may be articulated, is just another scapegoat for anticipated flavors of or direct failure. A leader is unable to move product to market on-time, on-budget, and with associative quality built-in from inception -- must surely be Agile. This form of logic suggests that when spilling Starbucks in your lap whilst driving, it is the fault of Starbucks.

  • And I'm disappointed to have experienced the situation where someone believed anything to do with Agile is just another passing phase. The disappointment comes from seeing someone imply, an alleged leader no-less, that current_state industry is no more valuable than historical industry. In fact further stating that if anything to do with Agile is valuable, someone else will figure it out or it will die like all the rest. This logic suggests the person is posing as a leader or team-mate and we unanimously encourage this fine organic to find another career where such esteemed apathy is welcomed as an asset. Please go to one of my competitors.

For most people and models through time, the next revision of life occurred as we learned, adapted and evolved from each rebase. Unfortunately in every single decade and adaptation were people who were doing it wrong, weren't doing it all, were apathetic or downright lazy. These people continue to get jobs and will always make evolution difficult. We will prevail in positive evolution nonetheless.

So, what's next?

The most logical next destination for us is an adaptation of Agile -- eXtreme Programming (XP) to Lean software development. As an arguable lowest common denominator, XP figured out how to go quickly, in short bursts, driven by quality and customer demand balanced with technical risk. Lean will take this and eliminate the remaining waste. "Lean" is "waste removal".

What will it look like?

Continuous integration, continuous test, continuous inspection, pairing and test-driven development will remain, though they will evolve to be more poignant contributors than they already are. User stories and acceptance criteria will remain, though they will benefit from an expansion or fixed variability of the idea to accommodate the different skill-sets in the field that try to use simple user stories and fail. To loosely quote another friend, Brandon Carlson, "XP and Scrum are local optimizations". He's right. It's time the people doing the work migrated into system optimizations in addition to practicing local optimizations. It's time for the next rev -- adapting lean behaviors into mainstream XP.

Kaizen, also referred to as Value Based Management, is a form of slow, purposeful, continuous improvement. Retrospectives, popular in the Agile communities, seek to learn from the past and improve the future at the end of each sprint. Unfortunately for many, that's where it stays -- in the meeting. Discussed in a digestible fashion on the Value Based Management.Net site, Kaizen concentrates upon five base elements:

  • teamwork,
  • personal discipline,
  • improved morale,
  • quality circles, and
  • suggestions for improvement.

These five base elements are then pursued through a core set of behaviors:

  • Elimination of waste and inefficiency (Muda),
  • Good housekeeping practices

    1. Seiri - tidiness,
    2. Seiton - orderliness,
    3. Seiso - cleanliness,
    4. Seiketsu - standardized clean-up, and
    5. Shitsuke - discipline;

  • Standardization.

And KanBan. The fundamental principles of a Kanban system are built upon the ideas of organized inventory, small inventory elements, triggers for requests, optimized delivery, and optimized replenishment. Take incremental behaviors and optimize them within and without across the end to end supply chain. If this is new to the reader, reference The Goal, by Eliyahu M. Goldratt and Tom and Mary Poppendieck's materials.

It is now an assumption that good teams practice continuous integration, continuous test, continuous inspection, test driven development, small iterations and frequent customer driven code drops. It is a foundational behavioral assumption. If you or your team are still evaluating the merits of V-models or feeling innovative discussing custom hybrids like Iterscrum or Hyperfall I encourage you to get back on path. We need to move on and expand to organizational optimizations and some flavorful blend of XP and Lean is next up.

Don't let anyone ever tell you there is no "art" in the words "software engineering". We have work yet ahead of us.


  1. A couple comments

    1) KanBan has it's roots in manufacturing, but software is not hard goods manufacturing due to the art of software as well as the intangible aspects. Need to reconcile KanBan as it relates to software

    2) Value based management - distinguish between innovation (radical) and Kaizen (continuous). Given the innovative nature of software how does that tie into Kaizen for software - blend is needed?

  2. There is definitely blending. Regarding KanBan, the characteristic of most interest in the software space is the elimination of "start:stop" behaviors in system level processes (and sub- for that matter). So rather than any characteristic unique to hardware assembly line behaviors, we're interested in taking a higher level behavior away and applying it to software -- in particular -- eliminating waste by eliminating wait time. Wait time can be transition from one system to another, person to person, system to person, customer to vendor, etc. No small task and to be pursued, must be pursued on purpose as it won't happen accidentally. Which then leads us to your second statement regarding Kaizen.

    I don't see a balancing act necessary between 'continuous' and 'innovation'. How about 'continuous innovation' through waste elimination? What we're fundamentally discussing are behavioral and cultural attributes. So, it is very reasonable to purposefully seek innovative solutions to waste elimination, continuously; but that would be too easy. We need to continuously eliminate waste and innovatively evolve concurrently. Sounds like a blend of XP, Kaizen and Kanban to me -- though that's likely too simple a statement as well.

    Good thoughts.