Tag Archives: lean

Is There a Better Way to Estimate Capital Projects?

Posted on by
5

Introduction

“I don’t understand why you keep asking us to estimate the work. With all the time we’ve spent estimating we probably could have completed the first few requirements already. This is a waste of time!!” Ever heard something like this before? It comes across a little naive with regard to capital budgeting.  But there’s a good point in the vehemence…. Waste.

In this article we’ll rethink estimation.  We’re going to look at the machinery above estimation that catalyzes the need to predict effort and then propose a different way to target capital funding for projects.

Backgrounder

I don’t want to lose anyone here so I’m going to go over some basics of capital budgeting for internal use software projects and how that relates to estimating.  If you know SOP98-1 already then skip to the next section. Estimating can seem like a game.  At best it’s an educated attempt to predict the future using formulas and experience.  At worst its a W.A.G.  So why do we do it?  It all starts with how we account for the expense of developing internal use software. Internally used software is classified, for accounting purposes, as a fixed, long term asset.  In accounting speak: a capital expense.  That means it can be purchased for a set price and has a useful life greater than 2 years.  Capital expenses, like internally used software, can have their cost depreciated ( amortized ) over the useful life of the asset.  What does that mean?  It means that instead of realizing the entire cost of the custom software effort in one year…..you realize it over the useful life of the asset.  So if we intended some custom built workflow system to last 5 years and the entire cost of the initial development effort was $312,333.04 then we’d ( in a simplistic amortization schedule ) realize, report $62,466.61 in expenses per year for 5 years on each annual income statement.  Further the software’s depreciated cost would be listed as an asset on the corporate balance sheet each year until the full value had be amortized. The ying to the capital expenditure yang is the operating expenditure.  Operating expenditures are incurred, realized as they are spent.  There is no depreciation of cost.  If I have $125,000.00 in operating expenditures this year then $125,000 in expenses shows up in the income statement.  Operating expenditures are not considered assets and companies routinely seek to minimize their cost and flatten their growth.  How do they do this? Well….one way is by investing in capital assets that can help increase productivity.  So if I invest in some custom workflow system that will reduce the number of FTEs ( full time employees ) I need by 10% then that’s a potential long term realized gain in operating expense reduction: a.k.a. more profit for shareholders. Capital expense accounting can seem like magic if you’ve never heard of it before.  But there’s a very real justification behind it. What is that?  Simply put: if you’re capital asset increases profits each year after it’s implemented then those profits should be offset each year by the cost to develop that asset. Fundamentally, capitalization of IT expenses is an immense part of why companies invest so much in new technology.  The accounting allows us to derive value from capital investments.  Yes, technology is wonderful, but if internally used software expenses weren’t capitalized you’d see IT budgets shrink drastically.

Estimating

Awesome.  So how does this relate to estimating the effort on a software project.  Remember this line from above: That means it can be purchased for a set price and has a useful life greater than 2 years?  A capital project is an investment or a series of investments.  Knowing the price up front each year creates two things:

  • The funds needed to purchase that investment.
  • The cost basis to use in constructing a model of investment return.

Each of these capital investments are compared against each other using a % return ( IRR ) or more commonly using NPV ( Net Present Value ).  Some are required and ‘must be done’.  But the rest are optional.  So leadership uses the projected investment return to determine which ones will benefit the company most.  That becomes a short list of capital projects to fund for the fiscal year. Now, when these projects are initially compared developers may have been involved in the estimation process or they may not have been.  But regardless the estimate is usually classified as a ROM ( Rough Order of Magnitude ).  Once the project is funded another round of more detailed estimating occurs with the development team for the strict purpose of validating the ROM.  If our detailed estimation shows we have inadequate funds then we need to make a decision:  cancel the project or increase the investment.  But if we increase the investment…how does that affect our return?  Should we do a different project instead?  You see where it’s going.   Estimation is a fundamental part of determining the capital project landscape.  It’s the basis for determining the initial and subsequent investment to achieve an estimated return.  Software is just a means to the real end: increasing organizational productivity.

Capital Budgeting Hasn’t Kept up With Agile Practices 

The astute among you will recognize how this financial model of capital budgeting doesn’t fit what you’re actually doing in agile software development.  Big shock…right?  Agile techniques are operational practices.  They aren’t financial, business practices.  Estimating each iteration using planning poker or whatever method has no applicability or affect on the overall investment.  Just because the development team boosted the number of story points in the release…doesn’t mean someone magically added more money.  Capital budgeting doesn’t take place every 2 weeks.  It’s usually an annual event in corporations, although some companies will extend their capital planning for longer horizons ( 2 or 3 years ).  Accounting is the architectural tool that builds business models.  It runs in annual and quarterly cycles.

But It’s Wasteful

Ok, so back to the top.  It may be fundamental to determining the annual capital project garden for XYZ Inc., but the estimates are usually inaccurate and they waste precious time in construction.  Regardless of method…capital projects rarely hit their exact mark.  This pushes many companies to see IT as a money pit to minimize.  Isn’t there a better way for determining our cost basis for capital projects?  Maybe one that doesn’t require us to estimate anything? Everything about capital budgeting is hard to change because it isn’t up to the company.  It’s regulated by FASB.  They define all these rules, and help to police them.  The government recognizes FASB’s standards in lawsuits and for that reason they have the affect of law.   Creative experimentation with accounting standards inside companies is something that people go to jail for. So change in accounting practices and standards is slow and carefully considered.  After all you’re monkeying with the monetary machinery of global industry.  There had better be a good reason for any change. So the next section proposes an idea for change to FASB’s capital budgeting rules.  Do NOT exercise this idea in your company.  There is no provision for this idea in FASB’s standards to my knowledge.  I offer it up simply for conversation and debate….not actual practice.

Relative Targets

When we’re looking at capital projects we need to know the expected revenue ( or savings ) generated by the project after completion and the expenses ( investment ).  Estimating, at least in IT land, deals mostly with the expense side. This is usually done in a very detailed fashion, but with relative targets I’m proposing we skip the estimation and just come up with a tolerance level.  How does it work?

1. Determine your expected revenues ( or savings ) if the project is implemented.

2. Determine your return thresholds.  There should be three.  You could do this with NPV or IRR.

  • The return you’d ideally like to get.
  • The worst return you’d tolerate ( yes it can be negative ).
  • The middle ground between these.

3.  Once you have these 3 thresholds you can then back calculate the capital requirements necessary to fulfill these return levels.  We’ll work through an example in a moment.  But here is the formula we’d use:

Formula to calculate investment for targeted NPV

C = NPV – ∑ R / ( 1 + r )

where

  • NPV = Targeted NPV
  • C = Investment required to reach targeted NPV
  • R = Revenue realized in each period
  • r = discount rate

4. Next you’d do a gut check.  Can we really do this project for anyone of the calculated capital thresholds identified?  If we can’t…then we shelve the project.  If we can then we would setup 3 tranches of capital per project correlating to the thresholds.  You’d start off by shooting for the ideal return scenario.  If that didn’t work…you’d make a decision to move on to the middle ground threshold or cancel the project and expense the loss.  The same would occur for the worst case return.

Example

So let’s say we have a project that we know will generate the following savings in years 1, 2 and 3.  Year 0 is our capital investment and what we’re trying to solve for.

Year             Cash Flow
0                 $???,???
1                  $200,000
2                  $300,000
3                  $200,000

Ok, so we know our estimated benefits from doing this project.  Now we need to figure our our three thresholds for year 0 capital funding.   Ideally we want to maximize our benefit.  So let’s say in consultation with the business we determine that these are our NPV thresholds:

  • The return you’d ideally like to get:  The most ideal return would be one that requires no investment at all and we receive the present value of the expected benefits – $580,015.02.  But this is unrealistic.  It does, however, give us an upper boundary to our ideal return.  So we’ll say that a more realistic ideal scenario is $400,000.00 in NPV.
  • The worst return you’d tolerate:  This could be negative.  Maybe you’re willing to lose money to get this software project completed. Good examples would be where there is a regulatory requirement associated with completing the project.  In this example we’ll say that the worst return we’re willing to tolerate is $100.000.00.  This is above zero, but shows that we’re looking for some monetary benefit.
  • The middle ground between these: I’ll just take the average between these two…..$250,000.00.

Great…now we just plug these values back into our formula to derive the initial maximum investment allowed to hit each threshold. We’ll use 10% as our discount rate.

Ideal Investment:

$400,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$180,015.02

This says that the most ideal return would require for our investment to not exceed $180,015.02.

Worst Case

$100,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$480,015.02.

This says that to achieve the worst investment return tolerable the investment must not exceed $480,015.02.

Middle Ground:

$250,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$330,015.02

Here we believe that to get a return of $250,000 we’ll need to make sure our investment does not exceed $330,015.02.

Now that we have our tolerances we can do a gut check and see how realistic it is to complete the project based on each level of funding:  $180,015.02, $330,015.02, and $480,015.02….or anywhere between them.

If our gut check tells us we can complete this project then we’d fund the tranches and start on the project.  If not then we’d drop this project altogether.

Summary

Relative targets take us out of the game of detailed estimating and instead push us to delivery within some tolerances.  This is a more natural way to manage a risky endeavour and affords us some built in cushion that everyone agrees is acceptable to the business’ needs.  We also pre-build fault tolerances, trigger points that force us to reflect on the project’s viability.  Here I suggest that there should be three of these tolerances, but there’s nothing preventing a company from setting up 4,5, or 10.

Advertisement

Santa’s Workshop Goes Agile!

Posted on by
2

Among the aroma of fruit cake, hot cider, and sub-zero temperatures Santa Claus announced today that his North Pole Workshop would switch to using agile practices in toy production.  Santa sighted a number of reasons for the change, among them:

  • Increasing need to be first to market against growing competition.
  • Better collaboration between kids’ toy lists and toy developers.
  • Reducing the risk that kids don’t get what they want.
  • Increasing quality and accountability in toy development and delivery.

According to Santa, “We’ve analyzed this decision for some time and  it became clear that change was needed after re-reading little Timmy Todsnockerdellturtlefoof’s complaint letter from last year.  Instead of receiving a bicycle, as stipulated in his toy list; he got two fake icicles.”

The well publicized failure last year to meet the requirements of Timmy’s wish list was not the first time Santa’s North Pole Workshop hadn’t delivered, but in this day of social media and instant updates; the story took on a vicious viral characteristic….hitting #1 in the tweetosphere for a full month with the hash tag: #TimmyTodsnockerdellturtlefoofGotIcedBySanta.

When asked what type of agile practice the workshop would be adopting, Santa replied: “Scrum.  It’s well known, proven, and being used in some isolated corners of our workshop today.”  Some muted ‘boos’ could be heard from the audience.

Santa went on to say that Rudolph The Red Nosed Raindeer would head up the agile transformation of the North Pole Workshop in conjunction with an outside agile consulting firm to be named later.  That development confirmed for some that Rudolph was next in line to take over The North Pole.  Rudolph was on hand to comment to reporters after the announcement:

“We’re looking at one of the big 5 consulting firms, but we haven’t ruled out the smaller players.  Look, what’s important here is that we get to done. I have a nose for this kind of thing.  I’m not a dreamer..I’ve been a servant leader for a long time…I realize this transformation isn’t going to happen overnight, there will be pain and there’s a lot of existing process and procedure that will have to….well, frankly….go away.  But, one step at a time. I expect we’ll have a more detailed plan in May or April.  Talk to me then.”

Reactions among the North Pole elves was varied.  One older elf man pointed out that Santa had to be dragged “kicking and screaming to the decision.  He wasn’t on board at all.  Rudolph, Frosty, Mrs Claus and the Yeti really had to sell him on it.  When they broke out Timmy’s letter to remind Santa of the increasing defect rates in his shop….he went ballistic. I mean he really lost his cookies.  Then the Yeti put his foot down.  I think Santa knew what that meant.”

Others, like a younger elf woman, had a different opinion on the switch to agile:  “I’m fine with the whole agile thing, but I guess I don’t understand why they chose Scrum?  I mean….from what I read XP is way better and more applicable to our environment.  I really don’t think the elves, particularly the older ones, will like daily stand-ups. I mean most of them can barely wake up every day….let alone stand up.”

Still another view was held by Donner, “What about Kanban?  No one’s talking about Kanban, but in the reindeer house we use it all the time to limit HIP ( hooves in process). I bet Rudolph moves us there.  I think there’s going to be a power play here between Santa and Rudolph.  It’s a battle that’s been brewing for centuries.”

“Give me a break. Agile?  Really, let’s knock off the buzz and hype.   So we goof up on a few thousand toys out of the billions we make a year.  How’s agile gonna solve that?  I don’t get it.  I guess I’ll ride it out and see where this goes.  But limiting HIP in the reindeer house has done nothing but give some of us more time on our hands.  I don’t think that’s what Santa wants.”  said Blitzen.

Frosty, while at the announcement, declined to make any official comment but did say that he favored a balanced, pragmatic approach, one that would focus on the workshop’s needs rather than a dogmatic approach.

Mrs. Claus had this to say: “Rudolph is very bright.  I know he’ll make this work.  He knows where he’s going.”

Strangely, the Yeti, was not present.  But his footprint could be found in the comments that others made.

Outsiders also came to hear the announcement.  The Easter Bunny had this to say: “I understand what Santa’s doing and to be perfectly frank he’s in a different position from us in Easter Hollow.  He’s facing some real time to market issues and competition with Mom & Dad, Grandpa & Grandma, and others.  His competitors have real advantages in local sourcing, customer relationship management, and technology.  Santa just hasn’t kept up and now it’s time for a radical change.   I don’t think anything he’s doing is going to change our approach.  We pride ourselves on stability of delivery and with a 98.2% market share on Easter…we’re just not facing the same issues.”

The Easter Goose has the other 1.8% of the Easter market.

Merry Christmas agile community.  Enjoy your holidays, stay safe, and as always….take care. 😉

KanBan: Limiting WIP….But To What End?

Posted on by
6

Introduction

The Kanban technique is popular within software development circles.  It borrows from the world of manufacturing where the original Kanban method is used to govern and regulate the production by any one operation so that it works in tandem with the overall production process and plan.  This article looks at how Kanban limits work in process inventory in software development and seeks to understand the value of doing this.

Work in Process in Manufacturing

In manufacturing Kanban is used to limit WIP inventory in manufacturing processes. But why is this done?  What’s the problem with WIP inventory in manufacturing? Isn’t having enough work and supplies for the next operation in line a good thing?

The answer centers on cost.  Excessive amounts of WIP inventory in manufacturing cost money.  Kanban isn’t about getting faster, or delivering a better quality product…it’s about not wasting materials, machine cycles and time creating something that won’t be needed. Overproduction of WIP inventory creates these costs:

1. Spoilage – too much work in process inventory can result in wasted goods ( especially food production ) because the downstream operation doesn’t need all the WIP inventory that was produced.

2. Overproduction / over purchasing of a part – If an operation in a manufacturing plant routinely produced more widgets than were needed by the next operation using them then the purchasing department is probably acquiring more raw material for that one operation than is actually needed by the overall production schedule.  This would result in the company having extra raw materials, which are often ordered in large lots for price optimization.

3. Wasted Operator Time  – This cost is a bit of a paradox.  Look at an operation that overproduces and it may appear in isolation that it is productive by a simple ratio of units produced/hours worked.  But, in truth the operation is just wasting the operator’s time because what he/she is creating isn’t needed.  The operator could be used elsewhere in the plant doing other productive work or even be sent home to help reduce labor costs ( assuming they are paid by the hour or unit produced ).  The wasted operator time may actually cause overstaffing as well.

4. Wear and Tear / Unecessary Maintenance on Machinery. – overproduction means we use our machinery unnecessarily for anything over the necessary production level.  The additional maintenance and wear and tear on the machinery can get expensive depending on the operation.

5. Increased Storage Costs – Excessive WIP inventory may need to be stored somewhere beyond the immediate operating space for a particular operation.  This usually means stocking the excessive WIP in a warehouse.  Warehouses cost money to build, operate and maintain.  By limiting WIP and adjusting cycle time and throughput through a plant you can eliminate the need for a warehouse and move toward a JIT system with your suppliers.

Does Limiting WIP inventory in Software Have a Similar Corolary?

First, what is WIP inventory in software development?  In a very thorough article on InfoQ WIP for software development is considered to be “tasks actively being worked on”.  It’s interesting to note how Kanban flips scrum upside down.  In Scrum we size the work to fit a time-boxed iteration.  In Kanban we size the time to fit a work-boxed unit.

But what are the costs associated with overproduction of WIP inventory in software development?  Are there any?  Let’s model this from the manufacturing world first and then see if we can find other costs that may be unique to the application development space:

1. Spoilage – It’s hard to say a requirement, feature, task, or idea would ever become ‘spoiled’ in the strict definition of that word.  You might be able to say that a requirement is no longer relevant or needed.  So perhaps there is some cost associated with the business analyst over-soliciting enhancement requests that will never be built.  But most new software development efforts have some baseline set of requirements that must be produced for the system to be coherent.  So letting the Business Analyst work ahead to get those nailed down in an efficient and comprehensive way that speaks to designing a ‘whole system’ is probably worth the expense.  Further, software development is not manufacturing.  It’s new product development and has an element of creativity.  This element of creativity requires some waste.  All creative efforts do.

2. Overproduction / over purchasing – If the developers over produce on tasks, resulting in a large WIP for the QA team, does this in turn cause a business analyst to generate even more requirements?  Maybe. If you’re Facebook and you’re always adding new features to your product then software development can be seen as a production line.  It’s a never ending stream of work for Facebook which probably requires some regulation of workflow to balance necessary resources.  But if you’re Pepsi and you have a simple capital project that will end when the funding runs out…then there is probably a finite set of requirements and you run no risk of overproducing on those requirements.

3. Wasted Operator time – There may be cost here if the business analyst, programmer, or QA professional are working on requirements of no real value or the requirement is not needed.  Does this happen?  Sure.  But I don’t see how Kanban prevents this from occurring.  Sometimes low value or worthless features are requested, everyone agrees they should be built, and it doesn’t become obvious until after completion that the feature should never have been added.

4. Wear and Tear / Unecessary Maintenance on Machinery –  This cost is hard to visualize for software development.  What would be the equivalent? Too much pounding on the keyboard?  Too much use of the CPUs?  Given that the computer would probably be used for something else if it were not being used by the developer/qa professional in association with their direct work; it seems there is a very minute wear and tear cost.

5. Increased Storage Costs – I can’t think of any storage costs that would be born with tasks that are not completed.  It costs virtually nothing to save these on whatever storage device houses them.  In fact the cost of storing anything in memory has been going down for decades.  Further, it’s likely the storage costs are spread across many budgets as more than one system probably shares the storage space.

So, some minor cost savings may come from limiting WIP in software development, but what should be very clear to any business professional is that Kanban in software development isn’t focused on achieving the same goals it achieves in manufacturing.

Kanban in manufacturing is seeking to limit the costs associated with overproduction of WIP.  Inventory costs are significant in manufacturing and need to be controlled, managed to limit their cost in the final product.  Kanban is a proven technique for this.

Kanban in software is seeking to limit WIP, but not for cost reasons.  The major cost in software development isn’t inventory.  It’s hours worked by people.  That cost comprises 90-95% of the cost for a finished software product.  So does Kanban in software limit hours worked?

Continuous Flow?

Software Kanban models the production flow of tasks associated with a software development effort.  Rules are established for production.  As an example:  the development team might set a limit of 3 done tasks as their kanban.  In other words they won’t produce any more tasks until at least one of the 3 done tasks is taken by the QA team for review.  This is a pull system.  Downstream processes determine the production of the upstream processes.

What makes this model successful in manufacturing is something called ‘cycle time’.  Cycle time is the normalized time required to produce a widget.  In most manufacturing processes cycle time for any one operation is well known.  This makes a pull process ideal.

In software development cycle time for any one task is variable.  This means setting a work in process limit on tasks will not necessarily guarantee continuous flow.  Further, in manufacturing a widget sent to a downstream operation is ‘complete’.  It’s not waiting on any further refining by the upstream process or any additional widgets.  In software development a task that is done isn’t necessarily testable.  It may require execution of a 2, 5, or 10 tasks for a piece of work to be testable.  So even though the QA team accepts additional work tasks from development, they may not be able to do anything with them.

Thinking through those points, it doesn’t appear that Kanban would limit hours worked by anyone.  In fact, it may actually do the opposite and increase the cost of the software development process as upstream operations wait until the downstream process completes work.  This idle time, might be seen as valuable in  allowing a team of developers, business analysts, or testers to switch to another project while waiting for completion of downstream tasks on an existing project.  But this then brings up the question of context switching and introduces even deeper complexities, entanglements into the production process.

Visibility of Workflow…the Real Value

So if Kanban doesn’t necessarily yield a more efficient development effort then what is the value?  Is there any?  The Kanban board is used to model the production flow of software development through its major person roles:   business analysis, development, QA, acceptance testing, and release management.  This board is visual and if kept up to date gives an interesting view for anyone hoping to manage the software development process.   At a quick glance the team can easily see where things are potentially bottle-necked and begin to focus on how best to free up that bottleneck.  This is the strongest value Kanban offers to software development: kaizen on the flow of tasks.

Summary

Does this article suggest Kanban is misguided in its implementation in software development?  Not at all.  Attempting to borrow techniques from other industries that have been successful is a useful, pragmatic approach.  Modeling the flow of tasks between processes has value in just opening up questions about why something isn’t done and what’s blocking completion.  However, this article does suggest that hoping to see significant, immediate cost savings in your development process using Kanban may be a false hope.  The true value will be unlocked by continually focusing on how best to increase the number of requirements produced per hour by the team.

Stop Agilizing Everything

Posted on by
14

Introduction

Agile universities, certifications, agile consulting, traveling coaches, planning poker card sets, agile software products, agile modeling, agile arm bands, countless agile books and the crazed cycle of agile conferences.

WTF????

The buzz cycle is in overdrive and it’s electrocuted the business world with the promise of faster, better and cheaper.  This article is a plea to stop.  Stop all the hype, the opportunistic profiting, and the marketing.

Good Intentions Turned Ugly

What started out as a challenge to the software development community to think outside the box ( invent, create ), abandon a one size fits all model to approaching software development and execute your projects in a pragmatic fashion that takes account of the context you’re working in….has turned into a marketing machine of horrible dimensions.

There was a time when people talked agile and you knew they were on the vanguard; trying to solve the real problems.  They cared.  They were passionate, deliberate, and informed.  Now, when you hear a colleague professing agile…they’re most likely drinking the kool-aid poured by the snake-oil agile coach from Denver or San Fran.  The formulaic response to the core problems is all too familiar and draining:

  • Poor Requirements – You need user stories and iterations.
  • Defects in Software – Continuous integration and TDD will solve that.
  • Bad estimation – Use planning poker.  It always works.
  • Change Management – Break it up into iterations and embrace the changes given in iteration reviews.

I’m not knocking these techniques.  Many are novel inventions that do have their place in SD/AD.  But instead of being offered as potential options, patterns, techniques to solving a problem among many other potential solutions; they have become a sales pitch by the opportunist preying on desperate CIOs.  Buyer beware.  Bubbles pop and my gut says the needle to prick this balloon is getting very sharp and close.

Let’s stop agilizing everything. Good ideas, tools, and techniques don’t need the word ‘agile’ pre or post fixed to be worthwhile.

Come Back Home

So turn off the scrum-o-matic. Wipe the agile makeup from your face, and put the kanban sequin dress away. There are still problems to solve.  We haven’t unraveled this thing called software development.  It’s devilishly vexing and we need good minds focused on it.  Become neo-software-amish, come back home to the forest of software trolls and invent/create again.

NEWS ITEMS: Knowing the Solution & Risk Management in Software Development

Posted on by
Reply

Some of my recent news items on InfoQ……..check them out

Decline of Written Requirements

Posted on by
4
Introduction
Requirements managers, project managers, and business analysts will find the most interest in this article. Developers will find a nice challenge at the end.  🙂   In this article, I attempt to show that written requirements are no longer necessary….and a new tool, using new media….is necessary.
Why did written requirements fail us?

Requirements gathering, analysis and management has never been easy.  It’s hard work filled with nuance, half-truths, mis-interpretations, ulterior motives, impressions, imagination, emotion and misunderstanding.  It’s vision crafting.
Getting everyone on the same page to a clear and sufficiently detailed model of the proposed system requires a conductor with the right skills.  Too critical to be ignored, a lack of depth in this area can doom a project.
To help codify that vision the software industry quickly turned to documentation and documentation standards.  But, written requirements have proven to  be an inadequate fit with the abstract nature of software and these flaws became apparent:
  • “That’s not how I read it”
  • Versioning Changes
  • Big complex software = big complex requirements = never read/hardly understood
It was realized by a myriad of software professionals that relying exclusively on the documents and omitting en
gaged conversations to clarify the written word was a mistake. But….spoken requirements and conversations have these flaws:
  • “That’s not what I heard or understood.  That’s not what I remember.
  • Hallway conversations, informal clarifications that aren’t heard by all parties.
  • Complex requirements can’t easily be remembered, conveyed through conversation alone.
  • Change management is non-existent.
User stories attempt to blend the spoken and written worlds and emphasize the continuous interaction between customer and software development team.  They rightfully restored the need for conversations and engaged business domain involvement and got us away from the never ending refinement or versioned requirements books.  They get us closer to where we need to be.  But, they still miss the mark.  Some flaws of user stories and their crafting are becoming apparent:
  • Software and business teams change…..leading to a loss of highly valued historical domain knowledge that may or may not be documented in the code or the story.
  • An awful lot of time is wasted writing these down, editing them, and then clarifying the exact meaning.
  • It’s a fine line.  How much to write?  How much to discuss?  Too little and the story is worthless.  Too much and we’re back to writing all our requirements.
  • Complex business domains and logic need to be documented in detail.  A simple story ( or many simple stories ) with acceptance criteria may not be enough.  Think about requirements for the Boeing 787 flight control system.
  • User stories assume the business owner will be available ( static ) for clarification during much of the project: not a safe bet.
Where are we headed?

With the proliferation of digital video, cell phone cameras, webinars, social media, and whiteboards we have a new set of building  blocks to create the 21st century requirements management tool.  And that is my challenge to the community.  Build it.  Use these pieces to create a new tool for managing requirements that further reduces the risk of interpretation.  Here are some advantages I see:
  • The historical integrity of that requirement conversation ( and its vision ) would be preserved for any future teams to review and understand it….nuance and all.
  • Verbal as well as non-verbal communication would be preserved and could be analyzed later for better realization of the requirement.
  • Whiteboarded artifacts could easily be recorded and saved along with the video.  Adding to a thorough documentation of the conversation.
  • While this wouldn’t completely eliminate the need for clarification of requirements; it could sharply reduce it.
  • Productivity in requirements gathering  and recording could potentially jump helping out the entire software development process.
If you feel you’re up to the challenge…:)….then contact me ( chris@effectivelogic.biz ) and I’ll give you further guidance requirements.

About the Author

Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager  throughout his career.  Chris writes on his experiences and ideas at his blog: http://www.anagilestory.com.