The Value of Values

It’s not immediately obvious why values are important to success. To me, it at first seems like the process dictates values and principles attached to them. To some extent this is true. A waterfall process, by its nature dictates that planning and control are important values. Agile dictates that adaptation is key. But neither process gives insight into how team members will interact. Will they collaborate to solve problems among themselves and with their business sponsors and customers? Can they openly raise issues? How will they even involve the customer? More in depth shared understanding is needed to bring success.

I have seen how the values implemented with a process can make all the difference in ultimate success. As Dee Hock, the founder of Visa once said:

Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior.

Insuring that the values are explicit, clear and agreed to among and across participants allows for better interaction and has a large impact on success. It supports an environment for innovation and creativity by providing a touch stone to ensure that motivations are healthy and collaboration productive throughout any process. It allows the process to evolve and deal with complexities that may not have even been envisioned when originally conceived.

So, where should we look to define values that are central to success in development? In my last post Agile on a Single Page, I suggested we start with the agile poster from VersionOne, the Agile Manifesto and the Declaration of Interdependence. Finding common ground across these sources is a good starting point for the discussion. Mapping affinity from these three sources, I get:

Agile Poster	Agile Manifesto	Declaration of Interdependence
Adaptability	Responding to change over following a planWelcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.	We expect uncertainty and manage for it through iterations, anticipation, and adaptationWe improve effectiveness and reliability through situationally specific strategies, processes and practices
Transparency	Customer collaboration over contract negotiationWorking software over comprehensive documentationWorking software is the primary measure of progress.	We deliver reliable results by engaging customers in frequent interactions and shared ownership
Simplicity	Simplicity–the art of maximizing the amount of work not done–is essential
Unity	Individuals and interactions over processes and toolsBusiness people and developers must work together daily throughout the project.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation	We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference
New Term
Customer Value	Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	We increase return on investment by making continuous flow of value our focus
Cadence	Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Accountability	Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The best architectures, requirements, and designs emerge from self-organizing teams.	We boost performance through group accountability for results and shared responsibility for team effectiveness
Quality	Continuous attention to technical excellence and good design enhances agility.

I see utility in giving single word labels to the similar concepts and have added them where the agile poster did not apply. Short labels allow complex thoughts to be communicated in a short hand and give teams the ability to quickly call forth values in discussions. There is also a need to spell out in more detail what is meant by these simple terms to promote understanding.

Your organization is not required to have this same set of values. I would, for example add the need for simple, timely, shared metrics to the Transparency value statement. I might add a social aspect to it as well and change the title of Unity to Collaboration. You may also add to, delete modify or enhance these values to fit unique aspects of your team or organization. The important point is that values should be stated, understood and used through the course of normal interactions across the execution of a development process. Make them part of charter creation and use them to guide productive interaction and decision making.

Technorati Tags: Values,Principles,Agile

Agile on a Single Page

I like the one page agile poster from VersionOne (click it to enlarge). It conveys principles and execution concepts that are central to agile development and it gives sequence to their relevance. It captures the essentials that help ensure success regardless of any specific methodology that a team or organization adopts. In a single view, it sequences agile development across its stages from product concept to delivery. Teams would do well to check their practices against the concepts it depicts.

It also comes without any explanation of its terms or meaning around its values. I will be exploring some core values of agile in the next post from this poster, and two other one page summaries of agile: the Agile Manifesto and the Declaration of Interdependence. In preparation for analysis, these two statements are also presented here with some background about their creation.

Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The team further identified 12 principles agile methods should follow:

·         Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

·         Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

·         Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

·         Business people and developers must work together daily throughout the project.

·         Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

·         The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

·         Working software is the primary measure of progress.

·         Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

·         Continuous attention to technical excellence and good design enhances agility.

·         Simplicity–the art of maximizing the amount of work not done–is essential.

·         The best architectures, requirements, and designs emerge from self-organizing teams.

·         At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These statements were formulated in early 2001, by seventeen representatives from Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others. This statement represents the group’s finding of common ground in what they saw as a shared desire communicate to the need and support for an alternative to documentation driven, heavyweight software development processes.  This manifesto has since been adopted by the Agile Alliance.

Declaration of Interdependence:

Agile and adaptive approaches for linking people, projects and value

We are a community of project leaders that are highly successful at delivering results. To achieve these results:

·         We increase return on investment by making continuous flow of value our focus.

·         We deliver reliable results by engaging customers in frequent interactions and shared ownership.

·         We expect uncertainty and manage for it through iterations, anticipation, and adaptation.

·         We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.

·         We boost performance through group accountability for results and shared responsibility for team effectiveness.

·         We improve effectiveness and reliability through situationally specific strategies, processes and practices.

This statement was formulated in 2005 by the founding members of ALPN, an organization dedicated to “making people great project leaders.” Each of the value statements conveys what this group thinks are the most important aspects of modern project management, and they also attempt to differentiate an agile-adaptive style of project management. Two of the fifteen authors of this statement also participated in the creation of the Agile Manifesto four years earlier.

Eliminate Variability

The first law of development, dictates the basic relationship between burn down rate, iteration time and number of story points being processed.

I start this post with the fourth “law of development physics:” Increasing variability in the development process always increases iteration time and reduces burn down rates. Which modifies the first law in a simplified model to approximately:

Iteration Time = Story Points in Progress / Burn Down Rate + n s

Where s (sigma) is an absolute measure of standard deviation of the iteration time
and n normalizes the variability relative to the best case performance at a given story point level: n = (story points in progress – 1)/(story points in progress * burn down rate)

The effect of variability then is to push iteration time above its best case possibility and decrease the burn down rate of otherwise equivalent processes. Using the first law scenario, impacts are easily in the range shown below:

Also, the magnitude of variability relative to the best case iteration time, will greatly impact the resulting iteration times from the process:
And, simulation shows that variability itself often grows as the number of story points in a process gets larger making the impact even more pronounced in large iterations:

Variability is inevitable.  The ability to understand, control and strive to eliminate variability is essential to maintaining a healthy development process. This is the focus of six sigma initiatives – when processes operate at a six sigma level of control, there is less than 1 defect in 3 million iterations of the process.  So, let’s define the causes of variability and assess ways to limit the impact of each.  Causes of variability in a development processes are generally from:

• Natural Variability
• Road Blocks
• Re-work or Quality
• Setup
• Availability
• Bottlenecks

These are discussed separately below.

Natural Variability – this is a catchall bucket that includes variability due to normal human behavior.  Included in this category are inherent differences in the nature of completing similar tasks, differences in skills and capabilities, differences in the time to problem solve, and other random impacts. I include in this category both variability between different people doing similar activities and between different activities for a single person. 

Probability theory shows that breaking work into smaller independent elements reduces the impact of natural variability.  Without all the math, consider that there is a greater chance of a large task that completes in 1 hour on average to grow to 100 minutes (15% probability*) than for say 10 smaller 6 minute tasks with the same distribution all to grow by the same percent (0.1% probability.)   By breaking a big job into smaller pieces, we reduce the overall variability by orders of magnitude and make the development process more predictable. 

Iterative agile development then, by its nature, helps reduce natural variability by forcing larger projects to be delivered in smaller pieces.  Other ways to reduce natural variability include skills training, modular design, and use of standards and templates.

Road Blocks – this category is the equivalent of machine breakdowns in manufacturing and can have a large impact on process times.  The development process can stop because tools break (a computer crashes,) but more often they are blocked because critical problems and issues cannot be quickly resolved.  Unlike natural variability where the longer one works, the more likely they are to limit impact, road blocks can grow large and out of control quickly. 

It is important to note that a few big road blocks can have a greater impact on project burn down rates than an equivalent number of smaller ones.  A two day road block yields the same availability as 8 two hour road blocks; however, the longer down-time from the first scenario has down stream impacts that are far greater.  Other activities dependent on the delayed work are likely to be stopped by the one larger road block, where multiple shorter roadblocks typically will allow other story point work to continue in downstream development.

So, identify road blocks early – preferably while they are still only risks – and implement mitigation approaches to keep them small.  Don’t just track risks, but actively manage them and implement strategies that eliminate them while alternatives are still available. The format of the daily stand up meetings also plays to limiting road blocks by having a daily forum where one key focus is on openly identifying them so that timely resolutions can be applied.  Close collaboration also helps limit variability from this cause by surfacing issues early. 

Re-work or Quality – To deliver quality, we look to the customer to understand what is required and we look to the development process to ensure it is delivered.  For the purpose of this discussion, let’s focus on quality as a measure of delivering features without the need for rework or fixes.  The critical thing to note here is that the impact of rework is highly non-linear to the fraction of work that is reworked.  With no rework, the impact is zero.  As we approach 100% rework, it grows to infinity and nothing can be completed.  For our forth law equation, the standard deviation of burn down rate can be significantly reduced as the rework percentages decrease (from 50% to 33%) in the example below:
The implication is that errors should be eliminated at the source.  Thus slogans like “build in quality” and “zero defects”.  Often the focus in agile is on mistake proofing the development and build activities using techniques like test driven development (TDD) and pair programming.  These help to build quality code, but used alone, they lose connection with the voice of the customer. 

Quality and mistake proofing need to spread across all activities of development: requirements, design, development, test and deployment.  Thus, we start and end with the voice of the customer in agile development.  They get the first word in iteration planning and the last word at closeout and retrospective meetings.  Customers typically only know whether you’ve met their requirements when they see the results, so create user stories to catalog requirements, grow them throughout the development process and validate them as soon as possible by releasing product to customers. In product design, the concepts of design for manufacturability ensure that the product designs can be built in a quality manner. In software development, where product manufacturing is the creation of new software, the concept translates to design for extensibility: using modular design, design patterns, coding standards, and comments to simplify maintaining, extending and refactoring code.  Quality testing begins with defining acceptance criteria before the build process and ends with user agreement that the criteria have been met. Acceptance and unit tests are automated whenever possible and the test base is grown throughout each iteration.  xUnit tools, page emulators and other test harnesses allow developers to literally “build in” testing and therefore quality.  Continuous integration, automated deployment and packaging product in each iteration limit variability in release activities.

Setup – this is delay or added work resulting from a team or an individual changing focus. It is also sometimes know as ramp-up.  Obviously, there is setup at the beginning of a project when new people are brought on and new tools are configured.  It is often overlooked within other development activities, but there are also setup delays any other time focus changes.  This happens between iterations, when switching between unrelated activities, when working on multiple projects, at handoffs and when there is task fragmentation.  Each of these requires time to physically and mentally prepare for the new focus.  There may be different tools and programming languages to use, different requirements to understand, different standards to apply, and other adjustments to be made before the new task can start.

The mitigation approach here perhaps differs from that used in manufacturing.  Flexible people, like machinery with short setups are essential to agile’s success. They are slightly faster in shifting focus and maintain better morale, but they have limited impact on maximizing burn down rates. And all people have a limited ability to flex. To maximize burn down, first focus on ensuring people are as fully dedicated to one project or initiative at a time as possible.  Plan each iteration based on priorities at the start, then do not change those priorities within an iteration. Maximize the span of control each person has in the development process so that story point features are delivered with few handoffs.  If multiple people are needed to deliver a feature, they should collaborate closely from the start to ensure understanding prior to any handoffs.  Finally, focus on keeping standards as similar between projects as possible so that transitioning, when needed, is less difficult.

Availability – variability in availability can be caused by vacation, sickness, not being able to concentrate, interruptions and by the timing and percentage of a person to a project.  The impact is similar to that of road blocks. Strategies to mitigate the impact should be fairly obvious.  Of note here is that we should strive to maximize the team or organizations availability, not each individual’s.  So, this should not be taken as justification for skipping daily stand-up or impromptu collaboration meetings in name of minimizing interruptions.

Bottlenecks – are typically caused because of a specialty skill that is in short supply or is over allocated.  Approvals also often fall into this category in development projects. The impact is effectively to reduce the team’s burn down rate to that of the bottleneck capacity.  Cross-training, Collaboration, and self-directed teams are proactive approaches to mitigate the impacts.

Credit: Again, this post is developed from Wallace Hopp’s and Mark Spearman’s great book Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996. 

* For finish rates in a process, an Erlang-2 distribution better approximates the variability than a normal distribution.  This distribution always has a coefficient of variation squared equal to 1/2.

Measure Outputs for Success

I’ve responded to comments from clients in the past asking why they did not see certain contractors on-site at their project as often as they expected. This even on fixed fee engagements. When pressed, the managers usually could site no direct impacts from the resources not being there.  At project retrospectives, all parties felt objectives of the project were fully met. So, why the complaint?

It’s just easier and more comfortable to measure inputs. This is a common theme and I think it is one reason time and material contracts continue to be a norm in consulting.  Employment is essentially an input measured profession. Short of major mistakes, most employees are paid for showing up. Thus the corollary, “I paid for the consultant, I want him/her here.” Having contractors work on site creates an input you can see and that seems real. It is also one of the least important measures of project success.

I know projects can be successful even when teams are fully distributed. In 2006, prior to the Sun acquisition, MySQL employed 320 workers in 25 countries, 70 percent of whom worked from home. Even the company holiday party was held online. I’ve personally delivered successful projects where in the course of a 6 month engagement, consultants were on site with the client only a few scattered weeks for critical touch points. In these cases, the focus is more squarely on measures that ensure success.

If you want to ensure success in any endevor, focus on measuring outputs. Track deliverables completed or burndown. Measure quality. Ensure risks are being mitigated. Measure tangible impacts to ensure value is being delivered. Measure stakeholder confidence and user satisfaction.

Contractors and consultants that are billing by the hour would do well to use contribution to output measures as a yardstick for whether any hour is billable. They would do even better to tie their compensation more directly to a value proposition and bill according to an output measurement.

Tell Me a (Short) Story

There’s an implied assumption in waterfall methodologies that there is value in creating requirement specifications for development. 

Aside from the already discussed costs associated with delay, there are a few inherent flaws in assuming that dedicating time early in the development process to detailed requirements adds value:

1)       We must know who the users are

2)       Users must know what they want

3)       Users must be able to communicate what they want

I challenge each of these underlying assumptions.  The first difficulty is one that all projects must overcome to find success.  Chapters could be written on how to find and involve your users.  I’d maintain, however, that nothing brings out users like releasing a product into the wild.  Wrap a beta release with a forum or wiki and you’ll soon discover users you never considered. 

The second is another where whole books are written about how to “elicit” or “capture” requirements from users.  It sounds, perhaps appropriately, as if we are trying to coax them like a shy kitten from the corners of users minds.  In my experience, unless you are porting an existing application to a new platform, users will only have a notion of what they need to be successful.  Show them something that they can use, and they start to understand the possibilities.

Finally, how many times have we heard, “but, that’s not what I meant.”  Even if users had a clear vision of their needs they may not communicate it clearly with words.  Even if they communicated clearly, a product owner or business analyst may not understand it.  Even if they understood it, the developer may not interpret it correctly. And so on, like the childhood game of telephone.

So, what’s a product owner to do:  Collect stores like a good investigative reporter.  Stories are the voice of your customers. Use stories to help define the product vision.  Use them to define the product’s value and to give it a personality.  Use stories to define who will use your product.  Create personas for each user role – give them names, add pictures and a life and spell out why they love the product.  Use stories to create initial estimates of how big the effort is.  Use stories to determine priorities – absolute priorities about what is critical for the users to gain value and relative priorities to help plan releases.  Use stories as a reminder to have another conversation when it is time to develop how a feature will work.

Use the format from Mike Cohn’s book User Stories Applied:

As a <role>, I want to <goal> in order to <value>

But, only gather enough stories with just enough detail to accomplish the above tasks.  Stories are the raw materials of development.  They should stay high-level and short until they are released into an iteration.  After stories are released, develop them to gain abundant detail.  Only then should you add the details: how will they look, how will they integrate with already created features, what architecture is needed to support them, what tasks must be done to create them, what acceptance criteria and test scenarios are needed to error proof them, and what as-built and user documentation is needed to support them. 

Thus, my third “law of development physics”:  The value of requirements increases as its production release becomes imminent. Or, you know what you need when you see it, until then, make up a good story.

The First Law of Development

In my post, What’s so Wrong with Pushing, I showed by analogy how Time Blocked Iterations, Story Points and Burn Down Rate enabled a superior pull mechanism over traditional management for development teams.  In this post, I’ll develop how to maximize results from that pull system.

There are three, sometimes opposing objectives in maximizing the effectiveness of development teams.  We want to maximize the throughput or story points delivered from a team.  This gives us more features – an obvious benefit.  We also want to minimize the cycle time to create those features so that we build them quickly – another obvious benefit.  But, we also want to minimize the work in process or features being developed at any given time.  This is a less obvious, but equally important objective.  Benefits of minimizing the work in process are that it:

·         Ensures the team is fully focused on the most valuable features
·         Clarifies requirements and acceptance criteria
·         Allows more flexibility by delaying decisions until facts are most clear
·         Simplifies communication
·         Minimizes the impact of defects
·         Minimizes impact of changes or new understanding

This applies to all activities of an iteration for each feature: requirements, design, build, test, deploy. 

Let’s use desks to represent those activities and imagine a development process where features go sequentially through the five activities.  The desks don’t represent number of people on the team, just iteration activities. Each feature has some value of effort assigned to it or number of story points.  We’ll use pennies to represent the number of story points being worked.  If our objective is to maximize burn down rate and minimize the iteration time, what number of story points should the team have in process at once?  

In manufacturing workshops, I’ve run this setup as a simulation with three scenarios, where the number of pennies is 2, 5, and 8.  For simplicity, we assume each activity takes the same amount of time, say half an hour (simulated in minutes) per story point, and only one story point can be processed in each activity at a time.  New story points can only enter after another one has finished all activities. After running this for 8 simulated hours, which scenario delivers the most story points fastest?  Actual results closely follow the graph below:  

From this graph, it should be obvious that at some critical number of story points being worked (5 for the simulation,) the team’s productivity (burn down rate) is no better, but they will work longer to complete each story point (Iteration time grows longer.)  In fact, there is a physical relationship between these elements which creates my First Law of Development Physics:

            Iteration Time = Story Points in Progress / Burn Down Rate

This relationship will be obvious to agile managers and teams. It is fundamental to the process of pulling work into agile teams. Perhaps not as obvious, is the important inflection point in this relationship which defines a needed optimization:

            Burn Down Rate_best = Iteration Time / Story Points in Progress_critical 

  and     Iteration Time_optimal =  Burn Down Rate / Story Points in Progress_critical 

In practice, there are no story points sitting in developer’s inboxes, so the components of this equation are measured empirically in the first few iterations of development.  Philosophically, it is important that the concept is kept at top of mind so that the three components are always being balanced for maximum overall benefit by releasing as close as possible to the crucial number of story points into each iteration and monitoring burn down rates closely.

Credit: Again, this post is developed from Wallace Hopp’s and Mark Spearman’s great book Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996.  Manufacturing students will recognize this as a derivative of Little’s Law (CT = WIP / TH.)  I have a couple more laws to develop from the book before moving on to more generic principles of development physics.

 

 

Getting Real from 37Signals

If you have not already read the philosophies of 37Signals’ development, it is time well spent.  You can read Getting Real on-line.  It overviews the software development ideas that created such programs such as Ruby on Rails and Basecamp.   Using simple language and numerous case studies, they layout understanding that agile advocates should have as background.  Here’s a teaser from their introduction: 

Want to build a successful web app? Then it’s time to Get Real. Getting Real is a smaller, faster, better way to build software.

·     Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.

·     Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential (and most of what you think is essential actually isn’t).

·     Getting Real is staying small and being agile.

·     Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.

·     Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.

·     Getting Real delivers just what customers need and eliminates anything they don’t.

Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.

More information and downloadable samples are available from their blog.

What’s so Wrong with Pushing

In agile development, much emphasis is rightfully placed on burn down rate, the number of story points completed within an iteration of development. I’ve never been fully satisfied with explanations for why this measure and control of it is so critical. To develop my perspective, let me step back and use analogy from manufacturing. I promise it all comes together in the end. For now, a SAT question:

     Push Planning is to Traditional Management as Kanban or Pull System is to
          a) Time Blocked Iterations
          b) Story Points
          c) Burn Down Rate

When computer software started managing factories in the 60’s, a team of IBM analysts developed Materials Requirements Planning (MRP or Push contorl system). The idea was that you could break down any manufactured assembly into its component parts, assign lead times to each for how long it needed processing before it was joined to a larger assembly and have the system release or Push parts to work stations for construction at the appropriate time. MRP became a hit in the US and Europe. By some estimates sales of MRP systems reached almost 1/3 of all software sold in the US in the late 1980’s.

Then along came Toyota. As MRP’s popularity crested, Toyota was out manufacturing the US and took a large part of the rap for the decline of American manufacturing. Their secret weapon: Kanban. In Japanese, Kanban simply means “card.” Here the idea was that when a work station was ready for more parts, they sent authorization or a card to request it. The amount requested was a fixed amount determined by the cycle time of manufacturing and rate of processing. This rippled back through the process to Pull work along each step of production.
 

Comparison of push to pull manufacturing control systems. Adapted from Hopp and Spearman, Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996, p 163.

How could a simple card take down the computing power of IBM? In looking for the answer to why Push did not work, pundits, and scholars of the 1980’s used similar arguments that we hear today for why traditional project management does not yield better results: The parts data needs to be more accurate. Master production schedules needed to be more realistic. More training is required to teach the concepts. Top management needs to be more involved.

Eventually, most agreed that the true fundamental problem was that Push is based on a flawed model. Lead times for Push calculations are attached to parts that have no awareness of what is actually happening at their work stations. If the work stations are idle, the same amount of work is scheduled as if they are working overtime. This problem is complicated by the fear that a late start for a part can cause it to miss final assembly which encourages inflated lead times and even more work to get scheduled for already backed up work stations. Now, change your mindset to development, and re-read this paragraph replacing “push” with “traditional management”, “lead time” with “work estimates”, “parts” with “requirements”, “work stations” with “development teams” and “final assembly” with “project.” Does it bother anyone that manufacturing figured this out before development managers?

Pull systems solved this flaw by using the card as a signal to indicate the state of the work station. Only when a work station is able to take on more work, is it requested. And, then, only for an amount that can be processed quickly while maximizing throughput. If you picked “all of the above” to the SAT question, give yourself a gold star. Those three components work together to enable development teams to Pull work – thus, the focus on burn down rate. Along with time blocked iterations and story points, it enables maximizing team and project performance. How to apply them and the Fist “law of development physics” are coming up next.

Credits: Much of what is covered in this post is directly or by analogy credited to Wallace Hopp’s and Mark Spearman’s great book Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996 and the application of its principles while working at George Group. I pulled my original edition off the shelf last week. A 3rd edition has since been released. So much of what they discuss in this book has application to all development processes and I encourage anyone searching for fundamental principles to dig into it. I’ll be referring to it as I further develop some of my “laws of development physics.”

Cost of Software Defects

I recall from my early consulting days a graphic that was often hauled out at management meetings and retrospectives. It looked something like this:

I’ve often wondered the source of this wisdom and discovered after some research that it comes from Capers Jones, Software Assessments, Benchmarks, and Best Practices, Addison-Wesley, 2000. Yep, Capers calculated this out to the dollar for us; although, in my memory similar graphics have been used at least since 1990.

In pondering the graph, what should one conclude? Search Google, and top results use it to justify the investment of extra time, effort, and capital in fixing errors during the early tasks of requirements, design, and coding. Spend enough in these tasks and a reasonable conclusion is a savings of $2,276,700 on a typical project.

What if, though, we assumed instead of phases on the horizontal axis, it merely represented time? The conclusion would be quite different. If we could complete requirements, design, coding, testing and acceptance in the time typically taken for requirements alone, we would never pay 10 times the starting cost to fix a defect. Instead of saving money, added investment in a single early task almost guarantees higher costs of correcting defects later in the time line.

I’d like to do the scholarly research of Capers around this to get empirical data. In the absence of that, using anecdotal evidence from applying agile to software development for the last eight years, I feel much more comfortable with this model. I’ve been on very long projects where early assumptions proved wrong or changed because different interest groups looked at them later. I’ve experienced long requirements cycles that delayed introduction of software only to find out that key features were missing. With agile, development happens across all phases more quickly and these problems are largely alleviated.

Thus, my second “law of development physics”: The cost of correcting a defect rises exponentially with the time taken to identify the defect. Or more generally, bad news does not age well. (The first law is coming next.)

Call for Panelists

I am moderating a panel discussion in June and am looking for panelists interested in participating.  It is for a BusinessAnalystWorld Symposium Conference and is titled The Role of the BA in an Agile Environment on June 9, 2008 from 9:45-11:00am in Denver. I would like to get perspective from practitioners in organizations of different sizes and experience levels on the road to Agile Software Development.  If interested leave me a comment or message.  I am also giving a talk later that afternoon if you want to attend or send representatives:  Agile Thoughts – Exploring the Philosophy and Mechanics that Make Agile Work on June 9, 2008 from 1:45-3:00pm.  I will be exploring some of those topics in a series of upcoming posts.