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.
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".
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:
- 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
- Seiri - tidiness,
- Seiton - orderliness,
- Seiso - cleanliness,
- Seiketsu - standardized clean-up, and
- Shitsuke - discipline;
- Seiri - tidiness,
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.