Skip to main content

Case Studies: Software Systems Failure

Software nightmare stories are very common - but one thing I've learned by listening to these stories over the years is the technologist must be optimist at heart.  Why - because they deal constantly with tons of failure.  And out of those failures they create innovative disruptive new sectors of the world economy (sometimes, case in point the Apple Newton and then the iPod and iPhone).

Let's look at a few case studies.

Time has just published a look at the Obama Healthcare rescue team.  Code Red by Steven Brill

"What were the tech problems?  Where they beyond repair? Nothing I saw was beyond repair.  Yes, it was messed up.  Software wasn't built to talk to other software, stuff like that.  A lot of that,"  Abbott continues, "was because they had made the most basic mistake you can ever make.  The government is not used to shipping products to consumers.  You never open a service like this to everyone at once.  You open it in small concentric circles and expand" -- such as one state first, then a few more -- "so you can watch it, fix it and scale it."
What Abbott could not find, however, was leadership.  He says that to this day he cannot figure out who was supposed to have been in charge of the launch."

The Secret Startup That Saved the Worst Website in America  How a team of young people, living in a repurposed McMansion in Maryland, helped rebuild

Stock Options? Don’t Need ‘Em! I’m Coding For Uncle Sam! (Medium)
The people behind the new government agency that’s recruiting the nation’s best tech talent to reform its hideous computer systems.
"The experience shows how great the differences can be. In newly released figures, the government says that constructing the original enrollment system, known as the Federally Facilitated Marketplace operating system, cost $200 million and would have required $70 million a year to maintain. The new version of the site, revamped by USDS engineers from Google, Y Combinator startups and other commercial tech outposts, cost $4 million to produce, with annual maintenance costs also $4 million."
Or take a look at an Agile/Scrum successful rescue -- the FBI Sentinel case management system.
FBI's Sentinel Project: 5 Lessons Learned by InformationWeek's John Foley
Case Study of a Difficult Federal Government Scrum Project: FBI Sentinel by Michael James
DoD Goes Agile by Jeff Sutherland 
DOJ's Report on Sentinel Project by Inspector General - Dec. 2011
How the FBI Proves Agile Works for Gov. Agencies by CIO's Jason Bloomberg
"Wait, agile rescued a huge money-pit fiasco of a government project? You mean, iterative, skunkworks, put-the-customer-on-the-team, forget-the-plan agile? You betcha. Agile turned out to be the hero in the tights and cape, coming to save the day."

Effective Practices and Federal Challenges in Applying Agile Methods  GAO-12-681: Published: Jul 27, 2012
What can one make from failure? Well, author John Kotter of the airport best seller's shelf (Leading Change) created his 8 step model from investigating why companies consistently fail to institute the desired organizational changes that they assumed were mission critical. His conclusion, if they had just done eight things well then the organizational change would have succeeded.
So what can we learn from two of the US governments most recent software project failures?  I think it can be summarized in one phrase - the Big Bang model only works for universes (or God).  The rest of us better learn how to iterate, grow, and evolve systems.

See Also:
Before Scaling up, Consider...

Agile Failure Disrupting Organizational Performance - by Agilitrix

Agile Succeeds 3X more than Waterfall - CHAOS Report 2011 - MountainGoat Software
ObjectMentor success stories:
    Sabre takes extreme measures - ComputerWorld

"Led by IS&T’s vice president, John Charles, the ambitious reorganization began in February 2015 and aims to spur innovation through agile software development practices adopted from industry. Charles emphasizes that this is not a typical reorganization, but rather a complete transformation of MIT’s IT department."

The famous SalesForce all-in, one day transition
    Slideshare presentation   The Development Dilemma PDF

Scrum at Scale Keynote 2015 (Scrum Inc.) - has infographic from 2015 Chaos Report

A Case Study of SME Web Application Development Effectiveness via Agile Methods  by: Peter Clutterbuck, Terry Rowlands and Owen Seamons University of Queensland, Brisbane, Australia

Agile Delivery at British Telecom  by Ian Evans, British Telecom  (Methods and Tools)

Live from LA Success Tour: 5 Stories of Agile Success (RallyDev)

LeSS Case Studies (over a dozen, mostly European companies)

Microsoft's agile case study - would you believe it? by Steve Denning of Forbes

Whole Foods Market case study Home Grown Agile - An Agile journey with one of America’s most trusted brands.

In 2016 there is a preponderance of organizations stating they are doing Digital Transformation.  What could this term mean?  Are they changing from analog to digital systems -or- are they mutating all employee numbers from arabic to binary?

Southwest Airlines’ Digital Transformation Takes Off - FastCompany
Rolling out new software is hard in any company, but it’s even harder when your employees still send faxes.

David Anderson suggest Agile is Costing You Too Much - makes the case that there are few if any Agile Case studies and publishes 8 Kanban case studies.  I loved the Sabre story David tells of circa 2006 Sabre reboot of "agile", I lived through a 2011-2013 reboot at Sabre.  They are continually rebooting that initiative - pondering why?

Agile Fails by Teri Christian

Post a Comment

Most Popular on Agile Complexification Inverter

Exercise:: Definition of Ready & Done

Assuming you are on a Scrum/Agile software development team, then one of the first 'working agreements' you have created with your team is a 'Definition of Done' - right?

Oh - you don't have a definition of what aspects a user story that is done will exhibit. Well then, you need to create a list of attributes of a done story. One way to do this would be to Google 'definition of done' ... here let me do that for you: Then you could just use someone else's definition - there DONE!

But that would be cheating -- right? It is not the artifact - the list of done criteria, that is important for your team - it is the act of doing it for themselves, it is that shared understanding of having a debate over some of the gray areas that create a true working agreement. If some of the team believes that a story being done means that there can be no bugs found in the code - but some believe that there can be some minor issues - well, …

Elements of an Effective Scrum Task Board

What are the individual elements that make a Scrum task board effective for the team and the leadership of the team?  There are a few basic elements that are quite obvious when you have seen a few good Scrum boards... but there are some other elements that appear to elude even the most servant of leaders of Scrum teams.

In general I'm referring to a physical Scrum board.  Although software applications will replicated may of the elements of a good Scrum board there will be affordances that are not easily replicated.  And software applications offer features not easily implemented in the physical domain also.

Scrum Info Radiator Checklist (PDF) Basic Elements
Board Framework - columns and rows laid out in bold colors (blue tape works well)
Attributes:  space for the total number of stickies that will need to belong in each cell of the matrix;  lines that are not easy eroded, but are also easy to replace;  see Orientation.

Columns (or Rows) - labeled
    To Do
    Work In P…

Webinar: Collaboration at Scale: Defining Done, Ready, and NO.

I was invited to participate in a Scrum Alliance Webinar.  Maybe you would like to listen to us in a discussion of techniques to collaborate at scale (remotely and with many people).  The topic is one that I've got some experience in discussions - yet I never seem to get to done...
Collaboration at Scale: Defining Done and Ready and NO for Distributed Teams
With Joel Bancroft-Connors, Agile Organizational Coach; David A. Koontz, Agile Transition Guide; and Luke Hohmann, CEO and Founder of Conteneo, Inc.

14 February 2018 11 a.m. ET (USA).

The Scrum Guide is pretty clear on the criticality of the definition of Done: "When a Product Backlog item or an Increment is described as "Done," everyone must understand what "Done" means. However, the Scrum Guide ALSO says that the definition of Done can "vary significantly per Scrum Team." This leads us to examine when and how the definition of Done should vary, how distributed teams should cr…

A T-Shaped 21st Century Knowledge Worker

Knowledge workers in the 21st Century must have many areas of deep knowledge, while also be capable of collaboration across multiple other domains with dissimilar T-shaped individuals.  This description of a person is a metaphor.  Compare it to the shape of the "I" in the classic saying there is no "I" in Team.

I first read about Scott Ambler's term "Generalizing Specialist" - but it's so hard to remember the proper order of the words... get it backwards and it has an inverted meaning... T-Shaped is easier to remember. 
A generalizing specialist is someone who:
Has one or more technical specialties (e.g. Java programming, Project Management, Database Administration, ...). Has at least a general knowledge of software development. Has at least a general knowledge of the business domain in which they work. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.  General…

A FAILURE to Communicate

I was working with a failing team some time ago.  I use "failing" to describe the outcome of the team - not the people on the team.  Are you OK with that description?

An issue arrose in the stand up - a team member that was to verify the quality of a procedure did so and reported that there were a few records that didn't match expectation in the data set.  Upon inquire the number of records not matching was over 2000.  Most people acknowledged immediately the exaggeration - I could tell by the laughter.  After about 10 minutes of discussing the details of the problem - it appeared the team had a handle on the specific situation.

I stopped the discussion and inquired if they could name the impediment.  One team member did a great job of describing the impediment as a _communication gap_.  Wonderful - I could work with that - the problem had a name and it didn't include anyones Proper Name.

"If the problem has a first name; we are going to have a problem."