We Built It, They Didn't Come at Agile Tour Bangkok 2016

Yesterday I spoke at Agile Tour Bangkok 2016 presenting a post-mortem of a project I had worked on.  What was unusual about my presentation was that this was not a success story, it was the story of a failed project and an examination of how to prevent such failures in future.

To the casual observer it would have appeared that the project had in place what appeared to be all the trappings of a successful agile development project for at least most of its lifecycle:

• a product owner – who was really a project manager and not a domain expert, but he knew the product vision… and there were Subject Matter Experts to support the Product Owner
• a prioritised backlog – maintained by a product owner… though the product backlog was a bit of a secret for several months early in the lifetime of this project
• daily stand-up scrums
• a scrum board with Post-It notes
• a burn-down chart
• regular sprints – with sprint planning and estimation
• reviews – where the sprint’s results would be demonstrated; and sprint retrospectives where the scrum teams would reflect on what went wrong, what went right and how to do things better
• a scrum master, and
  
• an actual product – under development with Letters of Intent to purchase.

Despite those agile ingredients, the body of this project was riddled with diseases. Some of these diseases were known at the time. Other diseases only became apparent afterwards.

• an organisation inexperienced in software development – inexperienced in identifying good quality people to recruit
• poor quality staff – but they thought they were good; resistant to improvement, and resistance to removing them
• poor attention to quality – must go fast and ignore quality; lack of appreciation for what quality meant
• poor communication within the team – secret chats for requirements, etc; cliques (sub-groups) existed
• mismatched expectations – what the product could do vs what its people thought it could do; how good people were vs how they actually performed
• cancerous growth rate – particularly in the early part of the project there was rapid recruitment; rapid recruitment without establishing how to get good quality staff; rapid recruitment before working out how to manage the numbers; rapid recruitment while still “having to go fast and ignore quality”
• limited customer input – there were Subject Matter Experts, but no real-life customer who was actually using the product and giving in-depth feedback
• unverified customer input – proxy customer input from Subject Matter Experts was unchallenged and there was a divergence of opinions amongst the Subject Matter Experts

Meanwhile, there were no retained customers who would pay for the product.

A handful did pay some money and receive the product. Those customers were only interested in a small sub-set of the features and they were interested in having more features related to only the sub-set they were interested in. Relationships soured, and the customers did not stay for long, partly because of the poor quality of the product and the slower than expected/desired time to develop the requested features/enhancements.

Our highest objective is to satisfy the customer through early and continuous delivery of valuable software. (Manifesto for Agile Software Development)

The project team failed to observe the primary objectiveof commercial software development - not just to write software; not just to provide software to a customer but to provide a solution to a customer's problem.  Few potential customers saw the product vision as a valuable solution to their problems.

The product tried to provide a common solution for different customer segments.  Some features were only potentially valuable to certain potential customer segments, so other potential customers would question who the product was aimed at.  The product tried to solve a problem that either did not exist or was not sufficiently great a problem for people

Most importantly, the project team failed to react to this information - the project persisted in the face of this negative information.

The project failed to learn early and often, so in order to have stood a chance of succeeding it needed to have been learning early and learning often.  If you find that the product does not fit the market, either: find or create a better market, or create a different product.

How to identify if a product solves a problem worth solving?  Create a hypothesis and test it!  This is fundamental practice behind Lean Startup.

Asking people if they think something is a good idea is not enough.  Letters of Intent are worthless.  Software Requirements Specifications did nothing to tell the team if something was a good idea.  The Advisory Board did nothing to tell the team if something provided a solution to a sufficiently valuable problem.

The internal users cropped up in the story of this product, but they appeared late in the story, and then they were neglected – they were a captive market that was not exploited.  Subject Matter Experts provided guidance and conducted demonstrations, but did not use the product as part of their normal day-to-day work.  Input from SMEs and (later) beta testers was not structured/coordinated.

One needed to get detailed input from people actually using the product to find out how they used it and whether it helped them in their work...business analysis methods should have been used: observing users in action, deliberately questioning users on their actions, thoughts and attitudes.  Input from SMEs alone is not enough.

Finally, in the Q&A at the end Kiro Harada pointed out that the project had really died a long time ago.  The project had been kept "alive" by the project's sponsor, so in effect it was really a zombie project.

Here are my slides:
 https://www.slideshare.net/DuncanCampbell5/we-built-it-they-didnt-come-67963609