Skip to main content

Buy vs. Build Decisions & User Stories

Where does the typical engineering Buy vs. Build decision making process happen within Agile software development?  How does Agile's User Stories help us with this decision making process?



Case Study
In the late 1990s I worked with a talented group of people creating a product to deliver high speed Internet service via satellite download links.  The version 1.0 product was done and functioning well, venture capital was secure for version 2.0.  There was a window of opportunity to release a 2.0 product into the market place and we were racing to that market place with a competitor.

Although we were not using any formal Agile process (the term had yet to be coined in Snowbird, UT), we were like many start-up companies using such a lightweight process that it had no name.  It is best to describe the development process as "just make good decision - and do it fast."

One of the features for the 2.0 version was greatly enhanced product licensing.  The new licensing feature wish list from Marketing had these desires:
  • license codes easily generated & transmitted to customers
  • demo license & timed trial licenses expire
  • annual licenses managed & easily renewed
  • perpetual licenses
  • add-on product features individually licensed
The existing 1.0 licensing algorithms were hand made by the company and known to have  some defects.  It was a much simplified and last minute design that allowed simple on/off behavior based on some hash-key techniques.

We were not using Agile User Stories and we were not estimating in relative story points and deriving duration.  However, we had experienced developers working in a known domain.  We estimated the License Management feature to be about 2 man-months of work for the team.  We had the "What" of the story - the "How" was up to the team.

Doing some initial design investigation, there appeared to be significant risk in designing our own solution for this complex problem space.  I had previous experience with many product's license management tools, and recommended we investigate a buy vs. build decision.  Our 2 man month estimate gave us a starting point for the data going into the decision.  In rough terms that would be $200,000 of development time.  Along with the opportunity cost of not doing other core competency development on the satellite networking code.  What would our alternatives cost?

An alternative solution was FlexLM - a best of breed license management solution that ran on all of our target platforms, except one.  That one missing platform was in development and could be considered functional beta on Novell's Netware.  It provided all of the features desired by our marketing group and provided an easy to integrate API for the development team.  This solution was going to reduce our work load to a week, and cost and upfront investment with recurring annual fees.

Working on our BATNA (Best Alternative To a Negotiated Agreement) with the FlexLM company we expanded our offering by agreeing to use our core competency, Novell Netware development, to help them with their Novell beta of FlexLM in exchange for waving the initiation fees.  This required about a week of consultation time, sharing code bases and cross-compiling and debugging techniques on Netware, which was our forte.

Our solution then was to use the FlexLM product, integrate into our code base their simple API for license management and pay the annual fees, in exchange we consulted with their development team on their code port to Novell.

Application of User Story model
Given that this case study took place before the advent of Agile User Stories, one must make some assumptions to draw conclusion on the usefulness of User Stories to the Buy vs. Build decision.  The decision is an economic model based upon the scarcity of capital, and the trade-offs of opportunity cost.  The inputs for the decision are monetary amounts, however, Agile User Story units of Story Points for effort don't compute.

Can one derive the necessary dollar amounts from the Story Points on an Epic feature to use in a buy vs build decision.  Yes, using a team's known Velocity (Story Points completed per Sprint) and team cost per Sprint (typically about $100,000 for a 7 person team) the cost of a feature may be derived - do the math.  The assumption is that a known velocity is applicable to the domain.

In the case of the license management this might not be true.  There were known risk associated with developing outside the core competency of the team.  These risk would tend to increase (not decrease) the cost of in-house development.  In the case study these risk were mitigated by the purchase decision and the partnering agreement.



Futher reading:

Using Agile for Buy Vs. Build Decisions - IEEE Xplore Digital Library - Agile 2008 Conference


Post a Comment

Most Popular on Agile Complexification Inverter

Innovation in the Automobile Industry

In the 1900s the automobile industry was the most important and innovation industry in the USA.  But one could question if this was good for our society in the long run.  And one could question if they actually innovated.

In the early 1900s there were few automobiles, very little infrastructure created to support the industry.  For example the road system was still designed for horse drawn wagons and the wagon wheel (remember a steal rim and wooden compression spoke wheel).  The future US Highways, or the 1950s Interstate Highway System at the cost of $425 billion were decades and many innovations away. There was no gas service station, there were however horse stables, farriers, and blacksmiths in each town along the roads.  There was no real "road map", there was no road naming system, like was created in 1926 - the United States Numbered Highway System.

The industry employees millions of people, and was a large factor in the economy of the USA.  It created or was created b…

Software Development terms applied to Home Construction

Let's Invert the typically wrong headed view of Software Development project management as a construction project.  We can map it the other way just to see if it works... to have some fun, to explore the meaning of phrases we toss around quite frequently.


Normally Project Management terms come from a construction domain.  We are going to apply the lexicon of modern software to the construction of a home.  We will follow the construction project and meet some of the people doing the work.

This is a very small (8 homes from $600,000 skyward) program in my 30-40 year old neighborhood.

About 6 months ago I saw the programs landing page go up.  It gives casual observers and some of the stakeholders a general idea of the intent of the program.  And most importantly who to contact for additional information if you happen to be interested in their products.

The Refuge program has 8 product projects and has them running independently.  Yet much of their DevOps infrastructure has already b…

Timeline of Social Networks -or- the Long Haul

I was listening to KERA's Think and they mentioned the concept of social networks.  It got me think...

But the book Long Haul, is its own interesting story - A Million Miles and Counting - A Trucker's Tale.

“The Long Haul: A Trucker’s Tales of Life on the Road”
Did you know 41 million people move in the US a year?  Having moved a few times in my life, sometime with the Bed-Bugger's help, this book is a great insight into that life.
Author: Finn Murphy's CB handle - "U-Turn" The radio interview noted the concept of social networks in the 21st century.  What is a highway - but a manifestation of a social network - a trail across the land.

a timeline using the Knight Lab Timeline JS tool kit.

See Also:

Social Media - Tracking its Exponential Growth video
Social media has overtaken porn as the #1 activity on the Web
List of social networking websites - Wikipedia

The World's 21 Most Important Social Media Sites and Apps in 2015



The Growth of Social Media - infog…

David's notes on "Drive"

- "The Surprising Truth about what Motivates Us" by Dan Pink.

Amazon book order
What I notice first and really like is the subtle implication in the shadow of the "i" in Drive is a person taking one step in a running motion.  This brings to mind the old saying - "there is no I in TEAM".  There is however a ME in TEAM, and there is an I in DRIVE.  And when one talks about motivating a team or an individual - it all starts with - what's in it for me.

Introduction

Pink starts with an early experiment with monkeys on problem solving.  Seems the monkeys were much better problem solver's than the scientist thought they should be.  This 1949 experiment is explained as the early understanding of motivation.  At the time there were two main drivers of motivation:  biological & external influences.  Harry F. Harlow defines the third drive in a novel theory:  "The performance of the task provided intrinsic reward" (p 3).  This is Dan Pink's M…

One Dark and Stormy during a Hurricane

I'm from the Carolina's where legend has it that our family commonly just hunkered down in the home on the coast and waterways than to head for inland shelter. Now that's from the old school days of barely improved (read paved) roads. They counted a storms severity by how high on the back porch steps (about 15 - top to ground) the water reached.  I don't recommend this action in todays world of long range forecast and transportation options.

I do recommend a drink or two in a hotel bar, far far away.

This is the week that Harvey came ashore in Texas.  I live on a hill in the little old town of Grapevine outside Dallas and Fort Worth.  And thank you all for letting me know that a storm is coming... I didn't get out and walk Malibu before the rain hit, so I grabbed a hat and we went anyway.  Much nicer walk with the drizzle, I'd say.

I'll raise a glass to you - if you were not smart enough to do the responsible thing, at the last responsible moment.

I do re…