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.

Preventing Fires

Firefighters are central and stalwart component of American society. We primarily associate firefighters with putting out fires and saving our lives and property. When we look at firefighters we think of historical events such as September 11, 2001, The Great Chicago Fire of 1871, and attributes such as ladder trucks, helmets, air tanks, axes, firehoses, firehouses, dalmations and perhaps even parades. We look at firefighters as people who save us from calamity. Given our esteem for firefighters and the profession, is it a surprise that firefighters do not really want to put out fires, saves dogs, elderly and children? Firefighters want to prevent fires, explosions and calamities from ever occurring so that people and property do not need to be put at risk, let alone saved.

Did you know that "Each year, more than 4,500 Americans die and more than 30,000 are injured in fires" (Hopkins, 2008).

The weighted average property loss per fire in the United States is estimated at $7,957.49 with Michigan reporting the maximum at $37,306.00 and New Mexico with the minimum report at $851.00 (, 2008). In 2006 alone the estimated property loss totals due to fire were estimated at $11.3 billion (Security, Sales & Integration, 2008).

And did you know that "Each year in the United States and its protectorates, approximately 100 firefighters are killed while on duty and tens of thousands are injured" (TriData Corporation, 2002, page 1).

Could we possibly argue anything other than the fact that preventing fire occurrences is far cheaper and safer activity than managing it in arrears? Firefighters want to prevent fires, not fight them. Unfortunately, due to accidental and purposeful fires throughout the United States alone, firefighters are forced to manage them after they happen when it will cost more time, money, health and most critically -- the lives of those in and around the fires. It is a fact. It is an unfortunate fact. Prevention is inarguably a better solution.

Software systems used in life critical implementations such as cellular communication infrastructures, nuclear facilities, air, sea and land transportation, medical equipment and military operations require extensive preventive measures to ensure availability, reliability, accuracy and scalability (as particularly noted by the cellular call load volumes of firefighters, police and infrastructure teams during the 9/11 events). Being equipped to deal with system fault and failure in arrears is equivocal to health and life loss due to fires. Software system fault and failure cannot and should not happen; and therefore must be pre-emptively prevented through training, design, test-driven development, continuous integration and continuous testing. To prevent is again cheaper on multiple levels than detecting and/or managing in arrears.

And then what about software systems that are not necessarily life critical, but critical to daily business operation? Is the need for proactive prevention any less important? There is a cost to failure in terms of time and money, though it is often undocumented in many businesses in any other form than system downtime. Yes, we have documented costs per defect research that came from Barry Boehm in the 1980s, IBM in sixteen reports from the 1990s, and NIST from 2002 -- but this isn't tacit knowledge for most business leaders. The easiest way to handle system downtime is to minimize the probability through contextual countermeasures such as training, design, test-driven development (TDD), continuous integration (CI) and continuous testing (CT). Because people tend to view software as a somewhat innocuous "thing" one can acquire for $N00 at the store or through $00/hour of labor, people exhibit a comfortability cutting corners to get software to market believing that lower cost of acquisition (cost to get it there) will guarantee lower cost of ownership and a quicker return on investment. If the software equivalent of a fire is system downtime (unavailability, non-reliability, lack of scalability, etc.), then the software equivalent of fire prevention is training, TDD, CI and CT.

Few if any would willingly hook themselves up to a heart managing life-support machine where corners had been cut; this is why we have safety regulations. Similarly, Chicago feels that the increased cost of acquisition for housing nowadays due to requiring electrical conduit throughout an entire building (so that no wiring is exposed) is quite conscionable because the cost of failure far outweighs the cost of prevention.

Unless there is distinct legislation or regulation, the balance between spending on prevention and detection and spending on fire management in arrears is subjective to the decision-maker in question seemingly making it an art. Since art is ordinarily a personal taste, where I may like the works of Paul Gauguin and you like that of Salvador Dali, it seems we are left with a Robert Frost-like conflict -- when is prevention a requirement and when is the expense of firefighting in arrears acceptable? It is a safe bet that firefighters will choose prevention every time because they understand first-hand the cost of failure. Is it then fair to assert that those who do not spend time on prevention do not really understand the cost of failure?


Hopkins, Gary. "Fire Safety: Activities to Spark Learning!", Education World. Published: October 1, 2008. Accessed: November 18, 2008.

Security, Sales & Integration, "Fire Statistics: Installations, Profits & Damage", 2008. (As quoted from the National Fire Protection Association (NFPA))

TriData Corporation, Firefighter Fatality Retrospective Study, Arlington, Virginia, Page 1, April 2002.

Planned v Actual Deltas

I'm not a fan of PMI or the PMBOK. I believe the fundamental premises behind PMI and PMBOK are honorable and correct in terms of work breakdown structures, dependencies, planned versus actuals, critical paths, and risk mitigation and issue resolution. The problem I have is with people who, having no experience in a particular industry, show up and apply what they believe to be universal laws of work, team organization, management and delivery without context of the unique elements of this industry over that. For example, the required behaviors of urban and regional planning require different behaviors and decisions than moving software to market, or even managing manufacturing assembly lines and production declaration through a plant. Context-driven decisioning is imperative. However, while there are some elements that are the same regardless industry and product, there is one in particular that I believe to be so important it transcends industry, product, practice, team and culture -- planned versus actual tracking and reporting.

What did you say you would do, what actually happened, and what is the delta?

Assembly line #12 is configured to construct one sub-assembly -- 50 units per hour, 24 hours per day. The math used to arrive at this goal and then used for baseline is built upon a series of assumptions and dependencies including sub-assembly availability, line staff availability across three shifts, power, mechanical availability and service frequency/responsiveness and so on. After arriving at the plan which includes what is needed to run and what will be the by-product of the run, we have a plan. What happens across a 24h shift and per hour within the 24h shift is the actual. If there is a delta greater than the planned and acceptable deviation percentage, there is a gap that impacts the entire supply chain and all ripples thereafter.

Software product #13 is expected to have 5 widgets planned to be delivered in AB time at XY cost. The math used for this experience is similar to that of Assembly line #13 in that there are presumptive dependencies to even start, let alone continue and resultantly deliver. There is technical and business design (plan) and then delivery (actual) where the delta is measured by business stakeholders, but primarily customers. Above this, there is overall project plan and actual with expected and manageable deviation; but deviation greater than plan is a gap actual therein unacceptable and requiring attention.

Both scenarios, and there are more examples in more industries for sure including financials, urban and regional planning, transportation logistics, etc., suggest the pertinence of knowing the plan versus the actual in order to manage the gap. No plan, no gap acknowledgment making actuals less relevant and/or meaningful. No documented actuals, and deviation from plan is unrecognized until funding is depleted. Sounds familiar in the 2008 US financial market, yes? We have a litany of Wall Street examples teaching us this concept very well right now. Even if there is a plan, an actual and an acceptable deviation margin -- there must surely be calculated probability suggesting an ability to deliver within margin.

If there is one and only concept from PMI and PMBOK for anyone, educated or otherwise, to take away and use for life in any industry and in any situation, I argue it is understanding plan versus actual versus acceptable deviation and probability of delivery within this framework. Ironically then, in order to understand and apply these concepts, one additionally needs to understand work decomposition (aka work-breakdown structure), time and dependencies, staffing, critical pathing and cost.

Seems like fundamental concepts of the PMI PMBOK just transcended industry, service and product. Now if we can just get the majority to understand context-driven application.

Mind the Gap

While on a trip to London I spent a fair amount of time on the Tube going from here to there in order to see things, eat things, hear things or all three. I am absolutely fascinated by a mature railroad system where society has an indisputable dependence upon its presence, value and predictability. I've utilized trains in different parts of the States, Belgium, France, Spain and Portugal and am a bit jealous that passenger train systems are so prolific in other parts of the world, yet not so popular in the States. I've had good experiences on every train excursion to date, but something during the London Tube experience stuck with me -- it was the wonderfully British accented voice telling me to "mind the gap" between the platform and the train itself so I wouldn't fall into the void and die a grisly death. Until then, I had not recognized a gap worthy of conversation even existed, let alone one which could contribute to my demise. Now I can't stop thinking about it. Well done wonderfully British accented voice recording. I'm still minding the gap though there is not a train within miles. The difference between what I thought was important and what someone called to my attention did not match.

What this brings to mind is the oft-discovered-in-arrears delta between what someone thinks they know, and what they actually know. There is often an unrecognized gap -- sometimes built on inexperience, hubris, different planes of existence, or carelessness. Unfortunately, or fortunately depending upon your outlook, we often discover the gap through error.

How long will it take to complete a particular project or task? Unless you've personally performed the task before, have parallel experiences from which you can extrapolate, or have at your disposal a panel of experts who have personally performed this work or have parallel experiences from which to draw an aggregate postulate, you simply do not know with precision. You can however, surmise or posit a theory --- and this brings into conversation the idea of relative sizing. You may not know exactly how long something will take, but you know if it is larger or smaller than some other form of personally derived measurement and can then extrapolate, relatively. Of particular enjoyment to me, I watch with interest those people who are not actually involved in the situation and neither have direct experience, nor parallel experience, but cannot seem to help themselves from espousing what must surely be a correct estimate anyway. Gap, indeed!

What I tacitly know is built upon first-hand knowledge gained from personal experience. What I think I know is built upon extrapolation and/or perception referential to personal experience. There is a gap. When do I find out there is a gap?

This abstraction is likened to watching children grow. At early ages, when the ball disappears behind the couch, the child assumes it is gone. However, as the child ages, based upon aggregate data collected through personal experience in the past, he or she deduces that the ball must surely be behind the couch even though not visible. There is a gap. In order to eliminate the gap, one must first crawl behind the couch and find the ball thereby affirming the original deduction. Ball here. Ball gone. Crawl behind couch and see ball behind couch, or see someone pick up ball from behind couch and extrapolate. Now, the next time the ball rolls behind the couch, I know it is there even when I cannot see it. Done.

At what point did the child recognize there was a gap between what he saw and what he knew? Was it a choice or an accident to make this recognition? Was discovery of the ball behind the couch a by-product of curiosity or chance alone?

Let's go back to the London Tube. I did not recognize, nor give thought to the gap because I was pre-occupied with other goals, and working on a set of assumptions:
  1. I assumed I correctly knew how to move from platform to train;
  2. I assumed I correctly knew how to be safe whilst making the transfer;
  3. I correctly assumed I needed to board the train prior to departure; and
  4. I correctly assumed I needed to avoid getting caught in crowd congestion or door movement.
Nowhere in this line of thought did I overtly identify minding the gap. Had the wonderful British accented voice not called out the point of "minding the gap" to me, when would I have made the observation? After I tripped, fell through or got a foot stuck? Or maybe after I saw someone else trip, fall through or get their foot stuck?

How often do people think they know something and fail to recognize there is a gap, perhaps canyon, between what they know and the way things actually exist? Unless we purposefully ask ourselves this question on a regular basis, we'll never know until we trip, fall through or get a foot stuck. More difficult for all involved is the fact that leaders often make decisions based upon what they think they know which may or may not match reality. This brings up two interesting observations:

  1. Given that leaders are often abstracted out from the ground-level line of work, it would be easy to feed a leader disinformation, falsity, or misrepresented facts in order to exploit the unrecognized gap; and
  2. Given that leaders are often abstracted out from the ground-level line of work, it seems logical there should exist one, preferably more than one, team member responsible for keeping the leadership accountable to reality.

Let me explain.

If there is a gap between what a leader thinks she knows and what she actually knows, until it is discovered or pointed out, she will make all forward moving decisions built upon the perceived information available in her mind. Seems like this gap may be a normal part of life, yes? Is the gap between reality and actuality, i.e. knowledge deficit, acceptable to you were a neuro-surgeon removing tumors from your brain? How about perceived versus actual altitude during a commercial jet landing? How about perceived versus actual facts while you're on trial for a crime you did not commit. Gaps are important. Whether we recognize them with immediacy is the criticality.

Flashback: What if during neuro-surgery a nurse pointed out that the tumor of interest was located at X and Y axis coordinates? Fact or fiction? Misinformation or disinformation? What if the surgeon modified his actions based upon the new information assuming that the nurse is likely more accurate? Or, what if the surgeon ignored the nurse? What we think we know and what we actually know should be questioned.

IF you were to argue that your job, responsibility or life were quite less impacting than that of a neuro-surgeon or commercial pilot OR that due to your own circumstance the binary decision to be exact is less relevant; THEN I argue you are negotiating shades of mediocrity with yourself -- which is yet another reason for accountability to the gap. Maybe you believe being inexact is okay; and maybe the guy who has to live with your world view and decision disagrees with you.

It is my opinion that all leadership requires accountability; not just for moral and ethical dilemmas, but also for corroborative fact-based assessment and decisioning. In fact, it is because of the gap between what we individually and collectively think we know versus the risk of a differing actuality that we should question leadership, decisions and direction. However, it is not just leadership that requires said accountability, but anyone with a supposition or opinion. Unless you crawled around behind the couch and personally verified that the ball is there, how do you know with unquestionably surety? Unless you can indisputably evidence that your perception is in fact reality, how can you confidently march forward in a care-free stride? How do you even have an argument?

There is a valid argument that we do not live long enough on this earth to personally verify everything, and that there are some things that we choose to accept as fact, whether through faith, extrapolation or juxtaposition of multiple elements.

The important thing to recognize is that there is a gap between what you think you know and what you actually know. Will you mind the gap in advance, or will it only be after you've missed the train or been run over by it?

"Agile Journal" Interview, June 2008 in Toronto

This is a 10m interview clip of me whilst at the Agile 2008 conference in Toronto. Patrick Egan, of eminent fame in the software engineering community, performed the interview for the Agile Journal with the purpose of exploring my (and that of many others) views on Agile evolution and permeation through the industry. I first learned of and interacted with Patrick over a decade ago via the configuration and change management communities. He has maintained his affiliation and leadership in the software community, in particular through CM CrossRoads, and we are all the better for it ... continuity.

Good Enough: Is This Really Mediocrity in Disguise?

Self-evident perhaps, there seems to be a very simple argument at hand regarding good enough software and how this statement alone may or may not stimulate right behaviors out of teams:

  1. Is choosing 'good enough' a form of identifying when to stop spending time, money and effort contextual to the return on investment; or

  2. Is choosing 'good enough' an excuse for choosing mediocrity?

For those who know, and then choose, to look at software through the lens of cost of acquisition, cost of ownership and return on investment the idea of 'good enough' is a decision on spending money versus making money. Even then, pride of ownership and contribution challenges many people because doing their best may exceed the minimally required cost of acquisition, i.e. to put icing and sprinkles on pastries may be the extra mile when a plain pastry may have been good enough.

This brings into question the conflict of the 'art of'' software delivery versus pure solution engineering.

Were I to have a bakery, I would want to make the indisputable best pastries in town while not only making profit, but ensuring the reputation I create is one that keeps me in demand through the coming years. If I concentrate heavily on profit margin, then I may focus on minimal investment (internal focus). If I concentrate on being the indisputable best, then I may focus on my competition and the perceptions of others (outward focus). To balance this out, I focus on a target cost and margin coupled with a target audience and I arrive at a somewhat algorithmic approach to balancing one with the other. Notice I said somewhat given the predictability of people lay in question (maybe I inadvertently started a pasty business in a vegan town, or failed to recognize people only visit this town in the summer).

Were I to desire scale commerce, then I'd additionally concentrate on cost of ingredients, volume of ingredient use per batch and individual pastry and may lean toward margins as a priority. Were I to conversely desire community specialty boutique status of greatness, value and artful innovation/creativity, my focus may lean toward 'going the extra' mile...suggesting I may use more icing, more sprinkles, serve larger portions, and spend more time on presentation in general.

And why do some restaurants stay in business to our mutual surprise, and others go out of business -- again to our mutual surprise? Is the answer always location, location, location? What if I have a great location, but I chose to focus on minimalist effort for maximum margins in a community that prides itself in having the best of the best?

If running a bakery or restaurant were math alone, accountants would be restaurant owners.

And then back to software... is delivering software so easy as identifying cost and stopping the work when the cost is met?

What if "good enough" conflicts with "pride of ownership"? How does that get reconciled? What if a buttered croissant is good enough, but you're really a frustrated pastry artist at heart -- longing to make that one, artfully innovative new fahrvenugen? Or, what if you personally have no issues with buttered croissants, but the staff you hire wants to do more? Where does 'team' come into the conversation versus just employer v. employee? How does one stimulate pride of ownership and innovation without breaking the bank along the journey?

My argument is this:

Delivering software is not only engineering, it is art.

If delivering software were anything less than art, anyone with an opinion and a calculator would be successful doing it. Standing in a garage doesn't make me a car anymore than someone choosing hourly rates over quality of work makes them a successful problem solver from the perspective of a customer. I find it hard to argue that math alone is a valid solution delivery pursuit given the condition of the United States financial market. And since we know failure statistics for software projects around the world to be very high, we know that opinions and calculators simply are not good enough -- alas, but the definition of success and failure is relative as well. To know what tool, language or framework to use per situation oftentimes comes down to objective subjectivity in selection. An art? One person may be perfectly talented in Java whilst another in .Net. Thereafter, predisposition influences selection. And then how Java or .Net is implemented is unique to the implementer. Again, art.

To use ten team members or eight.
To use on-shore, near-shore or off-shore.
To negotiate based upon rates or experience.
To start a business, stay in business, and be successful.
To blend a combination of elements making a unique solution?

I believe the definition of 'good enough' is relative to the definer. I believe the definition of mediocrity is as well. I also believe that some people simply do not understand the art of solution engineering and hide behind the argument of 'good enough' as a defense for skill deficit. One person's 'good enough' may be another person's 'mediocrity' without either knowing their definitions vary -- except when all members of the team sit beside each other and pair program using test driven development. The definition of greatness becomes a community pursuit and each person's definition of great is challenged frequently and often. Not so when teams of technologists sit in their own cubes/holes/closets and solution on there own. And no, despite wonderful fractals generated by mathematical algorithms, the pure definition of art does not request a spreadsheet as it's pre-requisite to existence. Pure art ordinarily involves human intervention, ingenuity, interpretation, adaptability, vision, execution contextual to individual skills, and sometimes a bit of attitude.

How about we change this conversation into simple problem and solution statements we can all relate to?

  1. What is the business problem we need to solve?
  2. What is the simplest possible solution we can use to solve this problem?
  3. Do your best at every opportunity and go home proud of your contribution, daily.
  4. Get the solution out there, get immediate feedback and invite change.

When I know what business problem I need to solve and refine it as I learn more, I concentrate on the definition of done. When I search for and choose the simplest possible solution, I not only meet the criteria of minimized cost of acquisition, but minimized cost of ownership and compressed return on investment windows by default. When I ask people to do their absolute best in every opportunity and to go home proud every night, my challenge is to each individual contributing to a team. I don't have to define mediocrity because I don't believe anyone proudly chooses mediocrity. And when I get the solution to market as quickly and simply as possible, I'm equipped to get immediate feedback so that I can change with the market demand. Paired programming, test driven development, continuous integration/test/feedback, short iteration windows, and clear business problem definitions (user stories) and definitions of done (acceptance criteria and test fixtures) combinatorially define good enough and mitigate mediocrity through team synergy. The focus is on the behavior, not the dollar. And the behaviors are ironically subjective.

Deciding if a business problem statement is in its simplest form is subjective and relative. And deciding if a solution is in its simplest form is subjective and relative. Responding to market shift is again subjective and relative. And deciding if this article entry covers the topic well enough is subjective as well.

Maybe this explains why there is so much subjectivity in delivering technology solutions. The end-users are usually humans and we seem inordinately challenged at agreeing whether there is first a problem and how it gets characterized, let alone what the solution may need to be, if any at all.

Self-Destruction thru Disparate Relativistic Goals

Have you ever tried to teach very young children? Have you ever tried to accomplish a seemingly simple, single goal by depending on very young children? Have you ever taken a group of four and five year old kids and attempted to teach them organized (football) soccer? I have. I failed. I'll elaborate.

During undergrad I volunteered to help run the athletics portion of a church program during the summer months out on the US Eastern seaboard. Sounded fun, would get to see another part of the US, and I thought I had a clue for such a simple task. Twas the night before my public humiliation, when all through the park, everyone but me knew my plans to teach organized soccer to four and five year old children would fail, likely even the mice. I had a single goal - to teach them field positions, strategy and to score points. As you can imagine, no one maintained position and everyone chased the ball en masse. For those who grew tired of being a single-celled organism chasing a ball, they found other more interesting things to do such as playing with grass, dirt, twigs and bugs. In the end, we fed my personal cache of chocolate and strawberry pop-tarts (that's all I could afford to feed myself that summer plus noodles) to ducks and geese on a nearby pond.

From the perspective of the children, the day started out weird because they couldn't relate to the initial goal and then ended up great because they could relate to the revisement. From the perspective of the staff, the day started off challenged because they didn't buy into the original goal and ended up great because they could buy into the value of the revisement. From the perspective of the leader, the day started out perplexing because he failed to recognize context and ended up great when he did.

Companies are like these four and five year old children.
  1. If the goal doesn't intuitively make sense, the group won't pursue it and does what it wants;
  2. If the goal takes too long to achieve, the group will get distracted and does what it wants; and/or
  3. If there is no goal, the group does what it wants.
Now apply this logic to circumstances and situations we've all seen in different companies through our careers. For those companies with leadership too far removed from the reality of the trenches, some goals make complete sense to the people writing them -- and are quite abstract and perhaps meaningless statements to most others. To bestow upon people ...
  1. All personnel shall exemplify the characteristics of a leader by displaying courtesy and professionalism at all times
  2. Company X will achieve its goals of N million dollars per quarter in annual revenue through innovative research and pursuit of technology
The first statement is relative to the reader as most people believe themselves courteous (I said most), and I imagine the same number of people view themselves as professional. So, the goal becomes a non-statement that requires no pursuit -- everyone likely believing they just need to be who they are and all will be fine. And the second statement is important to the executive team and stakeholders yet means nothing to the college fresh-out who is the first one to go to college in her family, just bought her first car, and is just happy to be here. Bad goals yield fractal teams and company. If the entire team cannot relate to the goal or understand how to contribute to the pursuit, they are then not equipped or enabled to live it personally or evangelize it to their team mates. To write goals using the SMART method of {specific, measurable, achievable, realistic and time-based} is Effective Writing 101 - it still doesn't make them relatable.

And what about the company that has no goals? What gets pursued is relative to the situation, who has the most power, who is the most persuasive (sometimes confused with loudest) speaker in the room, or even which contract yields the greatest Day 1 revenue. Companies using relativism as their basis of goal-setting and subsequent decisioning have a limited time-horizon to self-destruction. At some point, relativism will spawn competing goals and internal efforts will be spent on internal self-reconciliation rather than corporate pursuits and being competitive in the marketplace.

Deliberate, purposeful commitment and pursuit of goals to which the masses can personally relate and internalize grows great companies.

In fact, when each person in the company, from bottom to top, understands the three top goals for the quarter AND how their work contributes to meeting those goals, we have SMART goals that a great company will not only pursue but achieve -- and then they will repeat the behavior again next quarter.

A company without declared goals may use such language as "we're too small to need anything formal" or "we just need to generate enough revenue to make payroll" or "I used to be a in a big company and I'm opposed to formality". All of these statements are emotion; none of them are empirical growth goals. Since I posit that whoever you are at home is who you are when you go to work (remember that whole 'software is social' hypothesis I continue to argue), I'll refer us to a song illustrating life for the point. In 1991, a US country western singer named Aaron Tippin, wrote a song titled, "You've Got to Stand for Something" that articulates what I consider to be the foundation of identity, both for people and companies:

[Chorus] He'd say you've got to stand for something or you'll fall for anything
You've got to be your own man not a puppet on a string
Never compromise what's right and uphold your family name
You've got to stand for something, or you'll fall for anything

Now we might have been better off or owned a bigger house
If Daddy had done more givin' in or a little more backing down
But we always had plenty just living his advice
Whatever you do today you'll have to sleep with tonight

Artist: Aaron Tippin
Song: "You've Got to Stand for Something"
Album: "You've Got to Stand for Something"

I believe that companies, just like individuals, must not just have goals -- but rather they must have goals to which they can relate and therefore internalize; only then will they understand how to pursue and contribute to team accomplishment actions. The whole balanced scorecard logic coupled with SMART goal articulation is all well and fine... but since companies are individuals composing teams, they have to make sense to the people, not the composer alone. To have a goal is only one step above useless when companies/teams cannot believe in them, relate to them, or do not understand what it means to them. To have a goal that means something to everyone and that all members of the team can collaboratively pursue is success.

It is the responsibility of the individual to know what they stand for, believe in and want to become before he or she comes to work. And if this person does not yet know, he or she needs to figure it out. In parallel, it is the responsibility of the company to hire employees with personal goals parallel to the corporate goals so that symbiotic culture is fostered first through goal-setting, second through staff selection, and third through collaborative team pursuit.

With relatable goals that all intuitively understand and pursue, companies act as one and are setup to succeed incrementally, consistently across time. Without relatable goals that all intuitively understand and pursue, relativism rules -- and relativism spawns disparate commitments, individualism, egocentric heroism, fractal company pursuit, and inconsistent output, i.e. success.

Division within the ranks is more dangerous than solidarity of purpose.

Emergent Solutions

It is of interest to me when worlds juxtapose to form the next generation of 'something'. For example, I'm a pianist. In 1980s when I used electronic keyboards and/or synthesizers I was infatuated with the power of sound manipulation - always futzing with attack, delay, wave form, layering, etc. The power was amazing. The user interface on the other hand, was embarrassingly horrible. To provide the ability to manipulate a single note composed of three individual tones and compile three minutes of music into a single, mixed down sequence was unmatched - which was then ridiculously minimized down to a 3-5 line green screen window about as big as a mini toothbrush. Ridiculous. Even then it was apparent that legitimate computer peeps and legitimate music peeps had not spent enough time in the room together to provide technology with a useful, enjoyable user interface. Both industries had useful technology - no one had yet sandwiched them together into a new generational idea. Finally, just in the last couple of years have software and hardware engineers and their associative predispositions and experiences been juxtaposed into good software, good hardware and good music manipulation ability ... all have pre-existed, none have been melded together with elegance. Clearly, regardless how much time someone spent designing the future, their future designs weren't good enough for the 'now' needs of end-users. The juxtaposition, however, revealed itself through time. Here is an example of a yet ludicrous UI design given the sheer power embedded in this system; and here are two examples of people who got it right by minimizing hard-coded solutions and providing high configurability, high manipulation through a pleasant user experience.

The melding of cellular communications with additional media types is not yet there. Sure, we have the most current fantastical UI designs from a fruit company using a slim layout and having a reputation for wicked coolness; and then we have the post-apocalyptic clone wars thereafter. Yeah we have a cell phone melded with audio, video, text and web...but the industry is conflicted. They say to themselves, "How do we provide the highest multi-media bandwidth possible through the coolest user experience interface such that users cannot put our handsets down?" Well, the conflict is no longer merging my music with my phone to a single handset thereby eliminating one piece of hardware in my laptop bag; the conflict is now ... how to create the smallest, most non-intrusive piece of hardware that provides the largest experience possible? In particular, surfing. Aside from the unfortunate reality of so many websites sucking wind when pulled over a cell net down to the handset, the screen sizes - yes, even on the newest fruit company hardware - is still small. The emergent architecture most likely to emerge in the future doesn't even yet exist commercially... I argue the next evolution will be on demand HUD of sorts... yes, Star Wars. Cell companies are vying for position to merge media types into a single handset with configurability, flexibility, wearability, and small in physical stature for portability, but large in usefulness when pulling down web data that is miserable to utilize on a handset. One war at a time of course... all we're looking at today is the clunky third generation of emergent design. When cell companies put out their first generation cell phones, they were doorstops capable of phone calls only. Today? A completely different game. The next challenge is not data or media; the next challenge is making something small enough that you don't mind carrying it all of the time, but large enough to make anything you pull and view easy on the eyes, intuition and fat fingers. The next-gen will likely be a smaller physical with some sort of on-demand viewable hologram or HUD type solution. Emergent solutions reveal themselves in an evolutionary manner - in some cases based upon technology availability, and in some cases based upon user propensity or both.

And what of urban and regional planning? Does a town of 200 know the infrastructure design necessary as they grow to 50k people across the next 20 years? They indeed know the basic components; but do they know in what ratio these components should be mixed, implemented, administered and funded and when? No.

Sidewalks and college campuses? Oh, where to put a sidewalk in advance and where to let the dead grass underfoot 1000 collegiates reveal the need for concrete.

And cooking food for an unknown number of people? How much food to prepare? Even if we call each and every person planned for attendance, their appetite could vary between the initial phone call and showing up for the meal. As a host, do you gamble on less than or more than anticipated for food?

I believe that right solutions start with right ideas, but that end-state solutions ordinarily reveal themselves through the evolution of trial and effort. Just as customers ordinarily don't know what they want until they see what they don't want; systems and software engineers ordinarily don't know what solution needs to be in place until through time and effort a correct solution emerges. And yes, there are common baseline components and needs that we can be put in place as the initialization of the journey, but forecasting concrete end-state in advance is a waste of life and money. We are better served making sure we always leave ourselves with options rather than painting ourselves into a corner from which we cannot later escape unscathed (or unpainted as the metaphor may be).

Embarrassing Simplicity

Life seems to be full of irony and the idea of pursuing simplicity is one of them. How many times do teams solution a problem without considering simplicity?

For example, just because a team built a bridge across the river doesn't mean they have reason to be proud. Maybe said team over-spent, under-delivered, or ironically delivered something that meets the technical definition of a bridge, but is a violation of all things human due to quality concerns. What if the customer asked for something to enable them to cross a river the equivalent of five car lengths wide and one foot deep and the solutioning team gave them a state of the art suspension bridge? Should the solutioning team be rewarded for their prowess or chastised for their hubristic idiocy? What if all the customer really needed was a fallen tree with just enough girth to keep them dry whilst crossing?

More difficult yet is the customer who fails to articulate the business problem they would like to solve, but communicates what solution they want the team to provide. Absent clarity of the business problem, coupled with a team's sometimes inhuman ability to over-engineer a solution, we end up with a catastrophic miss while trying to deliver a solution to a yet to be discovered problem. For example, when a customer approaches a solution provider and says, "I need a data warehouse". Here we experience a prescription without description rendering mis-diagnosis. Months later we have a data warehouse solution built upon a high per-seat license cost Cadillac database technology additionally using a third party high per-seat license cost rendering tool only usable by people with explicit training provided by another vendor. Later, it is discovered that the customer simply needed a financial run-rate report that could have been created with straight SQL and cron'd on the back-end for daily distribution to a mail list. This solution could have been provided in approximately one hour.

And do not forget the classic complication of a team with a solution looking for a problem. Creating a process framework or solution in a vacuum that will address 'any' problem in the future is called premature abstraction. Why create a solution to a problem we don't yet have? Some will answer, "Because I can". Others may answer, "Because its the Boy Scout way to always be prepared". Both are the wrong answer. Most Boy Scouts I know don't have their own budget, financial targets and growth goals -- they just have Mom and Dad's checkbook and zeal to make their son the "best Boy Scout ever". Prudence suggests planning ahead, not solutioning the future before its time. And regardless perception, elegant solutions are garbage if no one asked for them.

  • When a young child comes in from an afternoon of playing outdoors with friends and declares his hunger, why cook a five or seven-course meal when carrots and juice may have solved the problem?
  • When a co-worker walks in and suggests the need for a streamlined method of fulfilling work requests, why have a series of one hour fifteen person meetings discussing tool purchases and automation when co-location of two key individuals may have solved the problem? What if the work request was discovered to not even be necessary?
  • When a customer calls and suggests they want a particular solution and it has to be done by a specified date, why do we feel compelled to impress them by over-engineering a solution for them as soon as possible? Maybe, just maybe, the customer has failed to understand the true problem and their solution request is wrong. And even if they do understand their problem well enough, why not pursue simplicity on purpose?

Solutioning costs money and solutioning a problem incorrectly costs more. Over-engineering a solution costs even more money. And solutioning a problem before it exists is just plain waste.

What if we practiced two things all of the time?

  1. First, find out what business problem needs to be solved; and
  2. Second, find the simplest possible solution to the problem and make it simpler.

Complexity breeds problems. Simplicity breeds satisfaction. So think about this:

If you're not just a little bit embarrassed about how simple your solution to the articulated business problem is, then it likely isn't simple enough.

Why Teams Suck Wind and Die

Company X does all of the expected 'right things' to build a great team and company. They spend high-end dollars to lure, recruit and then land what they perceive to be the best people to join their company -- sometimes from anywhere in the world. Immediately thereafter, these new employees are armed with expensive training from leading vendor companies on current pertinent subjects. Public relation activities occur, awards and certifications are pursued and achieved, and a reputation for greatness is created in the marketplace. These new people are put onto the teams most needing high caliber, well-trained individuals in order to rock and roll and embellish the company's greatness. The kicker? They don't rock and roll. In fact, they come off as non-union roadies who are allegedly part of the team, rarely seen, nor heard from when needed -- and when they are, their value is questionable. Money down the drain is it? Where did things go wrong? Was it a poor hire? Was it poor training? Wrong project perhaps? What?


First and foremost, look at the leadership. Any team with poor leader will eventually go stale and die due to missing energy, vision, morality, integrity, and trust in the leadership. People have to want to work for the people to whom they answer. If they don't, you have nothing but a collection of cogs showing up for their paycheck. Many leaders, to the loss of themselves, their teams and their companies, fail to recognize and understand their role and impact to team productivity. Leadership is not management -- either you have vision and pro-actively lead people to new places with your energy, inspiration and camaraderie, or you are a maintainer and manager of existing things created by someone else. Either you lead, or you maintain.

If your leader is inspiring and you like the direction the leader is heading, or you just plain believe your leader is straight up and you trust him or her, then you have the right foundation for building a world class team -- first you must trust the leadership. The teams have to believe that the person they are following has vision, morality, integrity, and the best interest of the company and teams in mind. When teams trust leadership, they are foundationally equipped to rock the world. Teams rock as a reflection of their opinions of leadership.

On the other hand, if you think your leader is a flake, idiot or you basically just don't respect him or her, should you choose it this will impact your attitude and outlook on life, your productivity and your contribution to the team. In fact, an absence of respect will eventually contribute to individualism and subsequently...chaos. As individualism leads to chaos, do not overlook the impact that one or more negative attitude type individuals may have on a team. In the event you have not given thought to how leadership and attitude impacts team mates, think through it a bit. Study the leadership of any team and you'll see into the future of that team.


What do we say here? People with a poor or non-existent work ethic will always suck wind until they choose otherwise. People with poor attitudes who only see through a glass-half-full lens will always suck the wind out of a good team. Accountability, responsibility, transparency, integrity and commitment aren't just words in the dictionary -- they are characteristics of good people, and in particular, good team-mates. And creativity, positivism, other-centeredness and the pursuit of knowledge are the added strengths that differentiate the teams experienced by most companies and teams composed of rock-stars.

Companies can hire from the best colleges and other perceived great companies and still fail to build the team with good people. Let's face it - it is pretty tough to create great teams.

Teams fail because someone chooses self-centeredness rather than other-centeredness. Teams fail because someone chooses mediocrity over excellence. Teams fail because someone chooses to focus on the reason why something cannot be done, rather than the reasons it can. And teams fails because someone chooses to not only see, but communicate the negative in everything that life has to offer, rather than not only seeing the positive, but being positive as well.

Teams succeed and fail due to the choices of individuals.

What To Do

In both cases of poor leadership and poor teaming, the solution is the same -- sit down and talk through the situation with whomever it is you need to confront. This doesn't need to be a high ceremony, high impact argumentative confrontation, but rather one where you simply state what you are thinking and seek to find a mutual resolution.

In the case of having a poor leader, sit down with this person and just plain tell them that you are struggling with motivation, attitude. or commitment as a result of not believing the leader has vision, integrity or whatever the problem is perceived to be. Pending your ability to constructively communicate a problem statement, said leader will show what kind of person they are immediately by how they react. If they disregard the information and turn the conversation on you, one possibility is that they are not mature enough to lead due to expending most of their energy defending their self-image to themselves. Conversely, if they take it in, ask for examples and earnestly and constructively analyze the situation for nuggets of gold it may suggest they are analytical and desirous of understanding and addressing fact. What is most important in this conversation with your upline leadership is discovering how they process potentially distasteful information - emotionally or analytically - and what they do with it thereafter. This leader's reaction may give you insight into your future under this person's leadership. If it appears change will happen, you're likely on the right team. If it appears change has no hope (and you yourself are not inherently negative), perhaps you should move on to another situation with higher success probability.

In the case of having a poor team mate...same conversation. Being kind, direct and honest is the shortest distance between dissatisfaction and resolution. And just as your transparency will bring out the true character of the aforementioned leader, so will it be with the team mate. Positive, honest reaction suggests a willingness to be transparent, understand and resolve the items in question; negativity, defensiveness or an unwillingness to acknowledge your words and feelings suggests that your assessment of this person and situation may be correct. Either way, learning how this person processes distasteful data will provide insight into how he/she will or will not be a productive team member into the future. If this person chooses the low road, it will be up to you to determine your next steps.

Closing Thought

And why, after all that schooling, training and effort put forth, does that team suck wind and look like it will die? It is someone's attitude, which turned into someone else's attitude, which then permeated the team to the point that it no longer looks like a team, but a collection of co-located people. Expensive training, great schools and great companies all have one thing in common - they are only as good as each individual composing the whole first chooses to become.

You, as an individual contributor to a team, have a choice to make - what will your team become as a result of your choices?

Wolves and Teams

Today's software vending and services companies have it wrong.

Many of today's companies, in the interest of competition, pit one employee against another with the goal of gleaning the best and brightest, or sharpening one with another. Sounds good if we're discussing evolutionary principles of natural selection, adaptation, or survival of the fittest. Even sounds idyllically like gladiator battles of yore. Oh, the ego boost to be characterized as a gladiator fit for war by peers and upline leadership. However, if our goal is to create a team which creates a company, we're failing with this mentality and model. Teams are not composed of a collection of self-preservationist rogues. What individual trusts a collection of people measured independently from one another? Who willingly turns their back to someone, who in the interest of self-preservation and advancement, may later be subversive? We already know the answer: no one.

Sometimes we hear individuals characterized as a 'lone wolf' or people are sent out in teams and characterized as 'wolf packs' as if these are good characteristics to be emulated by people and teams. Ironically, these are gross mis-characterizations and insults to, of all things, the wolf.

We know that:

  • wolves usually live and hunt in packs;
  • that packs are literally 'everything' to a wolf, in fact their identity;
  • packs are ordinarily led by the alpha-pair (male and female);
  • packs have distinct hierarchies; and
  • packs are in constant variable form communication such as howling, growling, and so on contextual to the situation and need (IWC)(PBS).

And most interestingly for the purposes of this writing, wolves communicate with each other during a hunt. Wolves go out and scout for food independently on behalf of and for the pack, but one wolf never benefits at a loss to the others unless he/she is seeking expulsion, damage or death (IWC)(PBS).

Quite frankly, if you are characterized as a lone wolf, it suggests you have a history of putting yourself before your team. This isn't a compliment. And if your team is characterized as a wolf pack, this is only a compliment in as much as you communicate and work together for the mutual benefit of the team. If you're team is just a collection of rogue dogs circling the kill where there will soon be a clear dominant winner, it is a mis-characterization of the idea.

What's interesting and implied here is the presence of trust. Each wolf knows his or her role within the pack, will do their job or be expelled, maimed or killed, and trusts all of the other pack members to fulfill their roles as well. Independent, yet one. No trust, no pack or pack benefits.

In 2002, Patrick M. Lencioni wrote a book titled, The Five Dysfunctions of a Team: A Leadership Fable, discussing the pertinent characteristics of successful teams, with special focus paid to exemplifying the anti-pattern. In this book, illustrated by a "completely fictitious narrative", Lencioni discussed five critical components (dysfunctions) which preclude building teams:

  • First and foremost, there is an absence of trust
  • Second to this, there exists a fear of conflict
  • Thirdly, there is a lack of commitment
  • Fourth, there is an avoidance of accountability
  • And finally, there is thereafter an inattention to results (Lencioni, 2002).

The book is a short read packed full of nuggets from which to learn. Please note that 'team' is really a metaphor for any group of people allegedly working 'together' for a common goal - thereby making this apply to executive teams, management, delivery teams, etc. The book transcends social hierarchy and is equally valuable to a President/CEO/Chairman as it is an entry-level developer, sales person or customer support team member. No trust, no team.

Interestingly, wolf packs seem to already know the content of this book. No trust, no pack.

So in your company, who is the pack? Is it the sales group only? Is it testing? Development? Interestingly, as per the wolf metaphor, if each individual group in the company is its own pack, then the ordinary behavior of one pack to another is to hunt them down and kill them (PBS). My assertion to you is that the pack ... is your company, not some sub-group within the collective. Dividing companies into multiple packs sets the company up for self-destruction by design. There can be no grand references to intelligent design here.

For example, sales groups. Visualize a sales group responsible for selling a product and/or service. Each sales person is individually measured based upon the gross revenue booked per quarter, and paid a small base with a variable percentage profit per sale contingent upon booked value. The bigger the deal right now, the bigger the cut right now. Demo made, sale locked, contract signed, up front fees paid by customer, and profit slice delivered to sales person. Game over and move on to the next kill. Seems like a very tight, clean process loop less the minor problem... this is lone wolf syndrome.

Sales groups are often measured based upon revenue, not profitability. Rewards are given to individuals. Individual sales people get the privilege of keeping their jobs or even earning a bigger cut of sales in the future based upon past performance history at the individual level. There is no incentive to benefit the team or the company since the sales person is rewarded by the company for thinking like a loner. Where this shows itself as a problem is during delivery and support thereafter.

During delivery we often discover the estimated cost of doing things measured against the actual cost doing things. In the event the estimates which stimulated a contract do not match the actualities of delivering, it eats into margins and impacts customer perception and satisfaction. The lone wolf that created the arrangement is not addressed, remember they are rewarded for bringing in the sale. It is the group unable to deliver according to contracted time, definition and cost that is deemed as the issue or bottleneck. Interesting isn't it? In the wild, the loner would be reprimanded or expelled. In business, we call it business. So later, when someone is trying to determine why their operational costs eat so far into their margins, it is assumed the operations group is incompetent and inefficient without consideration as to whether the contract was in the best interest of the corporate pack.


  1. Packs are built upon trust.
  2. Packs take care of their own, putting the needs of the pack before the needs of the one.
  3. Packs hunt members of other packs and kill them when they can.
  4. Members of differing packs do not work together.
Should corporations be created as a collection of packs? Or one pack with many members?

I wonder ... if I have a team of self-preservationist, independently assessed, rogue players in my house who I pay to do whatever it takes to get a signed contract, will their actions and decisions always be in the best interest of the company? We already know the answer.

The model is broken.


Lencioni, Patrick M. The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass. 1st Edition. March 19, 2002.

(IWC) International Wolf Center.

PBS. Nova Online. "Wild Wolves"

Good Enough, Lean, and User Stories

This article discusses two subject groupings:

a) current definitions and examples of 'Good Enough' software and 'Lean' software;

b) how by eliminating wasteful efforts using lean concepts like value stream mapping, coupled with using the idea of user stories and acceptance criteria, any issues regarding the subjective use of 'good enough' becomes objective.

Good Enough Logic

For years the idea of good enough software has stoked many a disagreement between people suggesting that even using such a phrase may license people to do less than their best, or even do less than is necessary for a complete deliverable. To some, good enough seems to suggest sub-standard work. Good enough merely suggests when to say 'when'.

Exemplified, you may hear as I do, developers and testers arguing that good enough logic is simply unprofessional and irresponsible. And business folks, sometimes customers and customer proxies, arguing that if someone on the delivery team is using the term good enough, they are likely cutting corners. So people tend to rebound from this concept by uttering such phraseology as 100% test coverage from testers, requiring onerous low-level designs and inspections, or arduous detail and alignment with project schedules and Gantt charts forecasting the future...all due to the knee-jerk reaction of not wanting to be good enough practitioners. Understanding test coverage is good. Understanding design and inspection is good. Over-use of these behaviors due to fear of the unknown or inexperience is an uneducated bludgeoning resulting in over-engineering. Later, people appear confounded as to what takes so long to fix a 'simple' defect in the system.

While this article is neither intended, nor crafted to discuss software testing in specific, it is a low-hanging, good example of the mis-characterized battle between good (do it all) and evil (do what is good enough) in the software systems realm. Exactly how much testing is enough, let alone good enough? A 2001 book that stimulates interesting conversation, Lessons Learned in Software Testing, published by Cem Kaner, James Bach, and Brett Pettichord, offered up experiential context driven thinking to help individuals and teams responsible for testing systems discuss and determine what makes sense for the problem being solved. Hence, a conversation of good enough for the situation.

"Furthermore, we think it's better to live with uncertainty about testing than to embrace false certainty. A good decision about how much testing is enough is necessarily based on your skill and judgment, ..." (Kaner, Bach, Pettichord, 2001, p.171).

What is quite positive about this statement is the encouragement to make a good decision based upon customer expectation, business and technical risk, coupled with one's individual experience and context. Ironically and unfortunately, people yet seem to want someone else to prescribe 'exactly' the way things should be anyway and it simply cannot be responsibly so; hence, the conflict with good enough thinking. Good enough decisioning is relative, often subjective, and is not just about testing, but rather about making decisions in general. To further explore context-driven good enough efforts with regards to testing, consider the 1999 book titled, Testing Computer Software. Said idea is discussed quite thoroughly with regards to test coverage and is fundamental to maturing one's ability to decision effort versus return comparisons. Pay particular attention to Chapter 3 titled, "Test types and their place in the software development process".

A single, minute example of good enough testing is evidenced by the below matrices showing a number of possible variable combinations that could be tested, and which ones common-sensically will be tested right now through redundancy elimination and prioritization. The cross-pollinization of this concept to other work is limited by one's mind, only.

Oh, should testing any system be so simple. When we add dynamically generated screens, conditional business workflows, multiple statemachines and sub-statemachines, variable user level permissions, integrations, third-party content, government and private sector regulations and security, multiple languages, and things with and without specifications or customer declaration - we have a bit more to code and test. Good enough conversations come into play when we have three days, three people, and a system too big to fully verify in arrears.

Choosing what we will and will not code, what we will and will not test, and what we will and will not deliver given time, risk, and value is not a conversation of good enough, it is specifically and directly a conversation of do what is necessary to meet the expectations of the customer - no more, no less. In fact, the balance of doing no more or less than is required harkens to lean logic doesn't it? Waste elimination sound familiar?

Someone always has to decide what will and will not be addressed right now, in what order and to what extent. In order to do it right, it must always include the customer, else we're simply gambling - which, if we don't understand the math and probability behind gambling, is waste also.

Lean Logic

With regards to lean logic, let's focus on one very simple, very powerful concept - value stream mapping. Any company, in any situation, will benefit by understanding and using this very simple concept on a frequent and continual basis. Take a look at the below diagram for explanation and consider its use. Take the time to look to Mary and Tom Poppendieck's book, Implementing Lean Software Development: From Concept to Cash, which discusses the ideas of eliminating waste for anyone, including particularly those people in the software and systems business.

Consider the following behavioral steps when trying to determine what is required and what is waste in terms of adding value to your business and customer:

Step 1: Lay out the primary sequential horizontal steps for any process in question. One can always be more detailed and analyze process, sub-process and the like; but concentrate on understanding the primary path of activity first as it usually points out wasteful activity with near immediacy.

Step 2: Within each box, identify 'how long' each step takes to be executed, and the number of people, forms, tools and repositories required therein.

Step 3: Between each box, identify 'how long' each step waits between execution.

Step 4: Add up the execution time identified in Step 2 and put it out to the side. Thereafter add up the wait time identified in Step 3 and put it out to the side.

Step 5: Add up the wait time and execution time which gives us total investment time to execute said process. Then take the total execution time and divide it by the total investment time to discover what % efficiency this process truly is for your organization.

Simple, true? Think about lean concepts like this:

Anything that does not contribute to cash in the pocket may very well be waste. Identify it, isolate it, ensure you're not overlooking something important, then eliminate it - mercilessly and without fanfare.

During this experience, take special time to consider how one could reduce and eliminate wait time (which is also known as waste); reduce the number of steps, people, tools and time taken to execute the 'execution' path, and so on. We're discussing the window between when a company has a contract, concept, service or product, and when a company will be delivery done and enabled to put cash in their pocket.

And a bonus feature, this idea works seemingly all over the company across multiple mediums. For example, using logic like this helps minimize key strokes and screens necessary to accomplish a task or set of tasks. How many clicks to get to the end of my workflow? How many screens? How many people across how many screens and key-clicks? This conversation is not about what is good enough, though it plays an embedded role in conversation and behavior; but rather understanding what directly contributes and what does not. What contributes is useful; what does not is waste.

Let me take a moment here to differentiate something that I perceive some still struggle to understand based upon those believing a CMM 5 certification or Six Sigma Blackbelt means the same thing no matter the application...just because something works in one company does not mean it will work in another. Similarly, just because something works in the manufacturing industry, does not mean it will work in the software industry. The process dissension between manufacturing and software delivery paths are voluminous given the differences between hardline assembly streams (hardware) versus softline construction, configuration activity paths (software), and the speed at which logarithmic change can be experienced. However, one very same application of an idea between the two unlike industries is the need to understand what is minimally required to be successful and eliminate associative waste. Manufacturing is in many cases, better at it. The exercise we just discussed is precisely the activity to be pursued...understand the time it takes to execute and wait; eliminate wait time, compress execution time, and perform this exercise continually, often and frequently.

We've lightly touched the ideas of good enough and lean so far. The next section discusses the idea of user stories and acceptance criteria to be used as the juxtaposition of doing good enough work, in as lean a manner as possible, all defined and managed by the customer.

User Stories and Acceptance Criteria

If you're new to the idea of a user story, and you serve customers - consider the following ideas:

  • Customers know their problems better than vendors know the solutions
  • Customers know what they want and will get it, with or without the vendor
  • Customers don't speak industry or vendor jargon; they speak native to their own culture and personal lives

In a previous post titled, Simplifying Test Construction, the article discussed the role and value of User Stories and Acceptance criteria and how they help define 'done'. If you are familiar with requirement specifications articulated as "shall" statements or use cases, they tend to work in context-driven situations ... though both require their own level of detail, weight and grid-iron for a 'delivery framework'. User Stories provide a clear definition of the problem a customer is attempting to solve and succinct acceptance criteria by which the the customer will discern 'done' in a light-weight format that is not too big and not too little ironically (or not) designed to mitigate waste collection.

An example user story and acceptance criteria format is:

As a <>, I would like to perform <> so that I can accomplish <>.

An example of the story statement in use is:

As a banking customer, I would like to deposit money into my account so that I can later access it if and when needed.

Example Acceptance Criteria that you and I would likely use to define "done" or "success" are:

  1. The ATM machine should take my cash, checks, deposit slip
  2. Whatever I deposit should not get mangled, ripped or stuck
  3. I should have sufficient time to deposit whatever it is I'm depositing
  4. The ATM screen should reflect my successful deposit transaction
  5. The ATM screen should reflect my increased account balance after the deposit

We can easily polish up these statements to be more consistent with each other and consistent with anything else we capture from the customer at a later time. For now, recognize the following:

We know who wants to accomplish what action for what goal
we know what criteria the end-user will use to determine success and done-ness.

What do we have here? The observation that the pursuit of good enough software systems is actually achieved by applying lean concepts with user stories and acceptance criteria as the medium.

In other words,

  • STOP discussing good enough software as it only contributes to confusion;
  • CONTINUE pursuing lean software systems implementations using value stream mapping; and
  • START leveraging the simplicity of User Stories and Acceptance Criteria to understand and define 'done' using the language of your customer, not your template.

There is an inherent relationship between those who practice lean implementations of anything, those who pursue good enough solutions to anything, and those who practice user stories and acceptance criteria in the fields of Agile/XP software system solutions - simplicity. What's missing is the ability for many to recognize when their US$10k certification, current classwork, company or university reputation is irrelevant.

Hard-core capitalists would articulate the goal to be 'achieving the highest return for the least investment in the shortest time possible'. Since I tend to favor the inclusion of people in these conversations, I reword it a bit.

"If you're not a little embarrassed about how simple your solution to the problem is, it likely isn't simple enough."

Note: If you want to study history with regards to successful lean implementation, study Toyota. Should you want specific coaching, education and application of lean logic to software, see Mary and Tom Poppendieck.

(Kaner, Bach, Pettichord) Kaner, Cem. Bach, James. Pettichord, Brett. Lessons Learned in Software Testing. Wiley. 1st Edition. 2001.

(Kaner, Falk, Nguyen) Kaner, Cem. Falk, Jack. Nguyen, Hung Q. Testing Computer Software. Wiley. 2nd Edition. 1999.

Poppendieck, Mary. Poppendieck, Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley Professional. 1st edition. 2006.