Cost Justifying Good Ideas

I'm currently re-reading Mary and Tom Poppendieck's 2007 book titled, Implementing Lean Software Development: From Concept to Cash, and I find it to be fascinating as if reading it for the first time - again. I think there are three fundamental and significant concepts that evolve around each other, intertwined, separate, but alike:

  • team structures should be of hybrid composition and small;
  • the cost of complexity can be managed through purposeful simplicity; and
  • cost justifying 'new' things/ideas should be a requirement, not a talking point.

Regarding team structures

The idea discussed around team structures challenges current organizational practices (prefaced by some very necessary conversation on 'project' versus 'product' funding models in organizations) suggesting they simply do not make sense. The book's assertion more explicitly? Build cross-functional teams, led by the Business (not IT), that are responsible for defining the target, defending and justifying the value, delivering and thereafter supporting the solution. Furthermore, change the team reward system to one based upon profitability of the feature or delivery element in question; not something more superfluous such as a passing contract that was signed in the 1st quarter of some year or the fact that a team delivered something at all (Poppendieck, 2007, pp. 62-65).

Many times, organizations are structured around what makes the most sense for the management and HR staff, as well as, the cost center logic used by Finance. In other words, people get organized based upon many different factors that make the most sense to those who are not actually doing or benefiting from the work; very few of these factors have or provide any merit to delivering value to the business. If the purpose of all organizations is to deliver, why not construct their existence into one elucidating delivery?

This stated, we already know from much of management theory and experiences today that most people manage 8-12 people well (8-12 direct reports); and having more direct reports than that ... effectiveness degrades. We know from personal home experiences in the US that the more times Cable Internet bandwidth is split in our neighborhoods due to concurrent usage, the less bandwidth there is for everyone. Likewise in software product development, we know that teams of 8-12 are just about the right size for synergistic teaming, effective communication, and competent value-driven delivery (this assumes a customer or customer-proxy is a part of said team to provide iterative 'value based' focus). As teams grow larger thereafter, it becomes more and more difficult to keep control, let alone lead and deliver effectively. Is it any wonder companies cancel project after project that have 50, 100, 200 and 2000 people on them that simply do not deliver?

Even the U.S. Military 'anonymously' asserted in a December 7, 2007 MSNBC article titled, "The Army's $200 billion makeover", that when a project grows so large, encompassing so much money and so many people in such a geographically distributed fashion, "you can't kill it" - suggesting it takes on a life of its own. The question thereafter begs an answer: "If a project is so big and distributed that it can't be easily killed, can it actually deliver something the customer wants at all, let alone within a reasonable cost of acquisition, ownership and return paradigm?" Seems like we collectively have a hard time managing size, let alone scope and effectiveness. Mary and Tom Poppendieck very simply asserted that not only do we need smaller teams that answer directly to the business, but they should be cross-functional (hybrid) teams responsible for proposing and defending the value of an idea. Thereafter, said team should be responsible for defending and justifying the idea (feature) through the various stages of its life on into production implementation and evolution. And this constant justification of any idea from a value and financial perspective circles back on the argument the Poppendieck's make just earlier in the book that most software companies should likely be funded and managed using product management paradigms, not project management ideologies.

When looking at the idea of small, hybrid teams, an example would be to construct each team to be self-encapsulated/solving by containing the following roles or something like it: {business proxy, developer, tester, database administrator, usability/human factors designer}. Were you to break it down lower? A business person, developer and tester can often make very significant progress as a team. The business person is the 'go-to', the developer is the 'do-er', and the tester is the 'validator' (which is often a developer or technical tester or some sort capable of development pairing, evaluating unit/functional tests, etc.). The idea of small, hybrid, self-encapsulated teams is covered quite well in nearly all Agile discussions and resources and is hard to miss if you're on the prowl for new methods/thoughts.

Make the teams small. Make the teams hybrid. Always include a business person inside the team.

Regarding the cost of complexity

The idea discussed around the cost of complexity is really best illustrated by a diagram contained in the book (which I do not currently have permission to re-illustrate here).

Textually, the cost of complexity is illustrated by having a Y-axis labeled 'Cost', and X-axis labeled 'Time'. There are two rays illustrated in the diagram. One is labeled 'Essential Features' and the other 'Complexity'. The purpose of the diagram is to show the {Cost to Time} comparison of putting essential features into software versus falling prey to the requests to put complex and difficult features into software (which happens to many of us at some point or other). As you can visualize perhaps, the 'Essential Features' ray begins at ~X,Y (2,0.5) and heads to right to Infinity ... just barely containing a rising arc. Conversely, we see the 'Complexity' ray begins also at ~X,Y (2,0.5), but quite drastically inclines while heading to the right and into Infinity suggesting that as time progresses, the complexity of doing, managing and supporting work, in addition to pain, toil, labor of existence and the search for resumes and jobs, all increase exponentially. The summary: Complexity kills. So, "Write less code!" (Poppendieck, 2007, p.67).

Note special behaviors here ... if there is a concern by a musician that many notes, high technical difficulty and speed exemplify mastery of music and the earn the utmost respect of other musicians, it is a mistaken belief. Else, how could beautiful music ever be written other than to be mind-numbing to play and process? Likewise, if there is concern by a writer that a message cannot be delivered other than through voluminous verbosity - it is again a mistaken belief, else how could children's books ever be written? And again, if there are technologists who believe the complexity and verbosity of design, code and test suggests supreme super architect intellect, it is yet again a misnomer and falsity. Complexity in music prevents other musicians from enjoying the music through performance and lay-people from actually understanding its contribution or value to the music realm. Complexity in literature reduces readership and application of what may be gold nuggets of wisdom due to the overbearing feel of the material. And lastly, complexity of code and technical solutions prevents other technologists from being a part of the team, from supporting, refactoring and/or extending the solution on into the future.

Complexity is an enemy, not a shrine to intelligence.

Of course, writing less code, while a needed behavior, is not the only behavior required in any organization evolving a software product. As discussed throughout the book, as well as this entry, managing a company's predilection to keep adding new stuff is imperative as well. One without the other is quite obviously an unbalanced existence. How many companies out there actually have a stated corporate goal of being simple? Going forward, when you hear about this or that company being short on cash, performing lay-offs, firings or 'displacements', ask yourself ... "How much of their problem is due to unnecessary complexity?" Clearly more here to discuss.

Regarding cost justifying 'new' things

And very interestingly, the idea of cost justifying 'new' things quite healthily suggests that we should put upon those people petitioning, lobbying or otherwise demanding new things/features in our software products (particularly internal team members versus customers themselves) that they do the math before, during and after the implementation of a new feature or widget to a product. Seems like it should be an 'old news' type of snippet, but alas, companies still fail to require the proper math it seems. Emotion and the silver tongue of Marcus Tullius Cicero being present in someone's office unfortunately carries more weight than hard math quite often.

More explicitly, reward cross-functional (hybrid) teams for cost to value returned for each feature effort, not simply because product was delivered to production, but in an incremental assessment framework through time. Let's explore this a bit.

Let's assume we already have a hybrid/cross-functional team in place composed of a business person (actual customer desirably, but customer proxy if necessary), two developers who share the responsibility of coding and testing in a paired manner, and an implementation/sales support person. This particular team eventually comes to believe that the company must absolutely have Feature123 added to their software product in order to compete in the industry or all is lost - heavily implying that demos will not lead to sales, and/or long-term support costs will go up, implementation times will lengthen, and so on.

Step 1: This hybrid team defines an epic describing what Feature123 is, who cares and why it is important to the vendor and the customer base (in free-form, conversational text).

Step 2: Same hybrid team decomposes the epic down into N user stories so they can understand what it really means to do Feature123 by using statements such as, "As a user [type], I would like to perform [this action/activity] so that I can accomplish [this goal]".

Step 3 -99: Same team associates each user story with acceptance criteria that essentially define when something is 'done' from the perspective of a customer (hence, the customer or customer proxy present on the team). User stories are prioritized and relative sized; the highest risk, highest return story is chosen; tasks are constructed and effort hours associatively .... until we have a work set.

The goal of the exercise is to understand what it will cost the company to implement one user story (COA), what it will cost to own it (COO), and how soon the company will make money back on said user story (ROI). In the Poppendieck model, it is not enough to have an idea ... the teams need to collectively understand what it is, what it will take to do it and own it, and when they company will get money back. And there's a critical element in here ... the comparison or project based versus product based funding.

In many environments today, companies seem to apply the idea of "project management" to everything that requires an effort, scope, budget, etc. Unfortunately in many of those situations, the request is to 'get it done' and funding is either ignored until the corporation is bleeding at a later date, or all funding for the project is provided up front thereby relieving everyone of the responsibility to be financially responsible. Ironically enough, when the project doesn't deliver and gets canceled and the company is out of money, people still get upset about not getting raises.

The to cost-justify effort works hand in hand with funding a product delivery stage by stage by stage. At every stage of an effort should the sponsoring team with the idea need to argue:

a) what it was projected to cost for user story 1
b) what is actually cost for user story 1
c) what monies, if any, have been made as a result of user story 1

d) what it will cost for user story 2
e) what it cost to date for user story 2
f) what is project ROI for user story 2

and so on.

What different behavior would be exhibited by a corporation requiring gated or phase based product delivery accountability to finances - performed by teams (the money spenders)? And what more financially responsible decisioning and implementation may occur if teams were rewarded purely based upon the profitability of their implemented ideas?

We need to constantly strive for simplifying the idea, cost justifying the idea, using a hybrid team to birth, defend, implement, support and evolve the idea, and ensuring that the idea is considered a critical, foundational feature immediately contributing to the financial integrity of the product. And very importantly, we not only need to be simple, but to simplify every time we revisit the ideas in the future. Otherwise, we'll find our companies are more likely coding to the emotional whim of the few while increasing the complexity, technical debt, minimized margins, and future pain for us all.

We go fastest by being lean. And being lean, while being constantly pursued, is only attained by being the simplest in all possible forms.


(Poppendeick) Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley Signature Series. September 2007. pp. 50-74.