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.

User Story Dogma

To articulate the definition of done with regards to acceptance criteria and a particular user story, many people are good and getting better. To articulate the definition of done with regards to an effectively written user story, we still have miles to go. The need for low/no-ceremony requirement definition is sound; however, low/no-ceremony does not imply pre-emptive thought to design is unnecessary.

Mike Cohn's intent in user story definition was to simplify what is historically an over-engineered, mis-understood, error-ridden process of filling out templates, defining gibberish contextual to the template and delivering nothing useful as a result. Delivering working code that matches a populated template full of refuse (an obvious synonym) is not success, nor should one be proud; hence, user story statements -- simple, quick, explicit, tacit.

Ample time to think through a user story's system implications, needs, risks and rewards sometimes appears to be lost in "be quick" which is itself a preposterous lunacy and easily a mistaken behavior masking laziness. User stories, use cases, shall statements or otherwise have all historically presumed someone would do the needful thinking up front where possible. Think of everything? Of course not. Think of most? That's why engineers get paid -- systematic, structured, pre-emptive thought.

For example:

User Story Statement
"As a user {type} I would like to perform {this action} so that I can accomplish {this goal}."

User Story Description
"(Describe the business problem) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis quis sapien id tellus laoreet blandit. Fusce pede eros, malesuada nec, egestas ut, euismod commodo, justo. Etiam nibh elit, pellentesque ac, faucibus sed, dignissim porta, nulla. Ut vehicula interdum nibh. Aenean eu arcu in augue viverra faucibus. Suspendisse quis mi. "

Acceptance Criteria Testable Statements
1. Positive functional statement(s) testable definition of done (Must)
2. Negative functional statement(s) testable definition of done (Must not)

3. Load+Performance goal
e.g. {user/transaction mix, concurrency expectation, good == ?}

4. Data architecture goal
e.g. {sql/syntax req, sql perf def, sys call/stack penetration def, good == ?}

5. System infrastructure goal
e.g. {b/u/recovery def, hw/network needs, disk, i/o, mem, good == ?}

6. Fault/Failure goal
e.g. {logging standard, recovery standard, good == ?}

7. UI/User experience goal
e.g. {CSS stndrd, transact end2end elapsed time/keystrks/scr, good == ?}

And this just covers a problem statement, description and criterion for "done" and "good". Hereafter would we relative size, prioritize and then very importantly... task out each acceptance criteria using ideal effort hours and a rule of thumb where one task cannot require greater than three business days of effort for completion else it requires further decomposition.

I've heard it argued that the more extensive thought on acceptance criteria articulated above is best left to task-ing experiences. This logic may be sound IFF people actually take the time to task things out, but I neither subscribe to it, nor do I believe it effective. Absent the task out, and then absent the acceptance criteria build-out, we have subjective evolution of an interpreted user story statement between a product manager and a pair, if pair, believing that their hard work matters. As always, working hard does not mean working usefully.

The need for writing an effective requirement has not changed through the years, nor has the idiocy that comes with arguing requirement elicitation dogma. Light-weight no-documentation solutioning is neither XP, nor Agile; it is a betrayal of intellect for those who actually have some.

Use user stories; but think ahead farther than just functional declaratives.

Business and Technology Symbiosis

How many times have we observed IT being oblivious to the business? Sometimes IT may not know what its like to get spanked in a demo, outplayed during a sale, or to provide a contract without true costs of doing business so that margins are bad and the gig is a sunk cost from the beginning. Ever see an IT group that fails to work together as an IT group, let alone as a component of a larger business machine? My least favorite IT failure is a group of technologists who simply take orders from business team members without questioning, guiding, facilitating or crafting solutions that address both business value and technical risk&complexity appropriately. If an IT team takes direction without questioning anything requested or stated other than for clarity, its not a team -- its a catering service.

A friend of mine, Tim Ottinger, stated it best recently in a parallel conversation when saying, "In the software world, the difference between a contractor and a consultant is whether you are paying for obedience or advice". Similarly, the difference between an IT shop that is a team-based solutioning component of the business versus a group of co-located automatons pursuing the latest directives is the difference between the Defensive and Offensive line coaches versus the water-boy. Everybody needs a water-boy to address their thirst of the moment. Games will be won or lost with the Defensive and Offensive coaches working together to structure the team, the plays, and the timing.

The business has a clear dependence on IT to show up and actively co-solve problems. Understand the problem to be solved, not just the words being uttered. Understand the current and future positional dependencies the business is in contextual to the request, not just the rank, serial number and long-windedness of the speaker. Understand the current and future positional dependencies, risks and complexities of the technology, not just the IDE, CI poll times, and next iteration demo date. Understand the business mission, vision and objectives, not just the quarterly meeting updates. The business needs IT to show up with options and options exist due to understanding the system level game board, not the local component. Without IT, there is no game.

Conversely, IT has a clear dependence on the business to show up and actively co-solve problems. Understand and articulate what business problems need to be solved, in what order, and how they are important in context of the larger business direction, mission and vision.

Sometimes the business may not know what its like to add new software to a system that really needs re-factored before it needs a new widget. Or what its like to support an international 7x24x365 shop while the locals go to bed at night. Perhaps better yet, recognizing that in order to race the Iditarod, one first needs to get the equipment, the dogs, the training, the route, the funding and the approval. IT should be invisible. Knowledge of it should not.

When the business shows up filled with perception versus fact, emotion versus reason, or self-declared impunity over accountability for things uttered, or my favorite business stakeholder failure -- indignity when questioned, success opportunity is minimized. Just like IT is expected to have a clue regarding larger business context, business is conversely responsible for IT context. For example, going SAAS as a business? Understand load balanced farming, traffic patterns and customer behavior possibilities. Going PAAS? Understand exposed APIs, SDKs, customer integration possibilities and whether the customer IT staff, if any, have the skills to make use of the functionality and make it happen. And so on. The time for guessing at answers and stabbing in the dark with the hope that fairies and pixie dust are real ended with college entrance exams. Business stakeholders need to know the acute business problems to be solved and have answers to associative questions.

Without the business and business stakeholders, there is no game. Without IT and IT deliverables, there is no game. Without both taking the alternating roles of defensive and offensive coordinators, there is no game. Without preparation, accountability, complete transparency, and communication through real human relationships there is no game.

If each member of the team is as good as they believe and state they are when prodded, then the proof will be evidenced through purposeful, transparent, organic relationships, constructive problem statements, solutioning through options, and context for all predicated by the business plan. If one side slacks on this dependence upon each other, then we're relegated to just being a co-located group of water boys believing in fairy dust.

Is there anything more important than learning?

Is there really anything in life more important than the ability to learn?

Hiking the Appalachian trail requires learning about the journey, experiencing the journey, adapting to situations during the journey, and at journey-end reflecting on what to do different or same the next time -- per instance skill measured by general state of post-hike health and distance covered.

Cooking requires learning what food is good to whom, in what situations, paired with what other food and drink types, and knowing when it is prepared 'just right' -- not too done, not too over-done -- per instance skill measured by who eats it.

Participating in a triathlon requires learning about preparation, training, in-race execution, post-race recovery and recognizing what changes need to be made for the whole process next race -- per instance skill measured by your finishing rank.

One could easily argue personal religious worldviews and practices are more important in life than learning, but to defensibly believe in something likely required reflection, learning, outward behavior of some sort -- perhaps measured by whether one knows why they believe what they believe.

Going to school. Having a family. Being married. Negotiating a good deal. Knowing where to get a good meal for business guests. The best beer and brat. The best team composition for a team-based goal. Handling conflict. Taking an important customer phone call. Going to a formal dance ball. Getting the best seats at NASCAR. Making it through London Heathrow without getting lost. Where to eat local in Puerto Vallarta. Delivering product to market under-budget. Leading by example. Navigating a round bottom canoe. Snowshoeing in the forest. Knowing when to say when. If to shop on Black Friday or stay off the streets. Know how much system testing is enough. When to believe the weather person. Getting an "A" in a class and actually knowing the material to boot.

What is more important than the ability to learn?

I believe there is perhaps one thing more important in life than the ability to learn... choosing to learn at all. To have the ability to learn is not to have the desire. I assert that having the desire to learn is more important than the ability to learn. Everyone is capable of learning if they choose so; unfortunately, not all people choose to learn.