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

Why Wait to Test or Deploy?

As a result of certain management decisions the development of my company's software product has been forced into "maintenance mode".  As there's no further development of the product's features then this has meant the elimination of my development team.

"Maintenance mode" does not mean that absolutely no development work is required to be done and that I'm now sat twiddling my thumbs all day with only one other colleague to keep me company.  For the software product to remain useful to its current set of users (yes, there are still some users) it needs to be actively maintained - fixing bugs, making minor enhancements, etc. This drastic shift has forced me into a very lean way developing, testing and deploying - one which we should probably have been following previously.

I am now the only one doing any of the maintenance development work, while my sole remaining colleague handles the testing and support activities. With nobody else doing any other development, there is nobody else's code to wait for.  So the question naturally arises:

Why wait for another piece of development from me before testing and deploying?

The only reason I could think of for holding back on testing and/or deploying a piece of code was to do with the overhead of testing and/or deploying that piece of code.

If testing is related to just a single bug fix or feature enhancement then the scope of testing is limited, which reduces the overhead.  If a few related bugs can be fixed in the maintenance development then they can all be tested at the same time, further reducing testing overhead.

It was felt that deployment might be a significant overhead for the IT support doing the deployment, but checking with IT support revealed that there was no significant overhead, though there is scope for further automation.

The other deployment activities involve build creation (mostly automated, but there is scope for further automation), release notes generation (working from a template and mostly copying changeset comments) and demonstration/feedback meetings with users.  If the release is just bug fixes or minor behaviour enhancements then we don't see the need to have a demonstration/feedback meeting to show people that an error no longer occurs or that a selection is automatically population in response to a click elsewhere.  Demonstration/feedback meetings with users can wait until there is something of a more tangible difference to demonstrate.

So, we're down to the development, testing and deployment of a single feature at a time (plus a handful of related bug fixes and enhancements that are undertaken in the course of the feature development through the normal refactoring and fix-it-when-you-find-it approach).

The result: faster deployment, almost continuous deployment.

As each release now consists of a single feature another question naturally arises:

Why keep a backlog of other feature requests?

Each demonstration/feedback meeting with users finishes with asking them to vote for the feature which will be of most value to them.  Not the top 5 features, but just the single feature that will give them the most value.  With only one feature being worked on at any time there is no point in maintaining a list of any other features.  At each demonstration/feedback meeting new ideas may be discovered for something that will give the most value to the users, so keeping a record of the second most valuable feature request from some point in history is just administrative overhead.

So, there is now no backlog.

The result: no backlog maintenance is required.

If we had more staff why couldn't we continue doing the same?  Couldn't we have worked like this when there was a development team?  As each feature became ready, couldn't we have deployed it?

Big Backlogs: are they worth it?

Previously I'd written how I'd reorganised a 500+ line spreadsheet of backlog items.  The backlog had, if anything, grown rather than shrunk.  The question then naturally arises:

What is the point of maintaining the backlog if most of it is never used?

There is a sense that discussions around backlog items would be wasted if those items were not recorded and prioritised in some backlog.

Different potential customers had presented many features that they'd required, and all of those were recorded.  Though customers and potential users carried on without those items as the sales were not secured.

(Maybe a better sales approach was required: get agreement on purchase of the core product then provide incremental delivery?)

A similar question can be raised regarding large bug lists:

What is the point of maintaining a backlog of hundreds of bugs?

If users can continue quite happily using the product then what is the point of maintaining a backlog of hundreds of bugs, particularly bugs which go back years?

This also raised the question:

Why is there such a large list of bugs in the first place?

If the first iteration of a product is poor there will be many bugs reported.
If the first iteration of a product is also large there will be many more places to find more bugs.
If the bugs are not addressed in the next iteration but more features are added then they will remain.
If development continues with the same level of quality then more bugs will be produced for the new features.
Result: even more bugs.

So, how to stop having and ever-increasing number of bugs?

You can stop the flood of bugs by:

1. starting with a small set of features in the first iteration, so there are fewer places for bugs to lurk
2. building quality in from the start, by not attracting bugs in the first place
3. continuing in future iterations with few features and high quality

But what about a big backlog?

If you start off with a small set of features aren't people still going to ask for many more features?
Yes, but you still have to prioritise which ones you're going to do in the next iteration.

Should the features not implemented in the next iteration continue to be recorded?
If after iteration #1 feature X is requested, but it's not implemented in iteration #2, it may no longer be relevant when it comes to iteration #3, other feature requests may be made as a result of viewing and interacting with the product produced in iteration #2.

Therefore, features that are not implemented should be aged and eventually dropped from the backlog, thus keeping it small.

Backlog (Lack of) Management

To be honest I've been very negligent in not properly managing our product's backlog.  I'd been able to get away with it because I'd not been under much scrutiny, I'd been able to manage it mostly from my head and an e-mailshot, and I'd had other things to do that had been more important (or at least I claimed they were more important and I had to be the one to do them).

Our product's backlog is enormous.  Over 500 lines in a spreadsheet.  Trying to prioritise that and ensure that there is no duplication was going to be a futile task.  So, I decided to adopt a principle from kanban and "start with what I have".  Given the reference to kanban it should not be so surprising to learn that what I had to start with included a kanban board which indicated exactly what was being worked on at what stage and what was to be worked on next.

The first step was to synchronise the kanban board and the backlog.  This may seem like duplication - because it is - but it allows anyone looking at the backlog to see the current context and how it fits into the rest of the backlog without looking at two different media (a board and a spreadsheet).  Anyone can now look at the backlog spreadsheet and see what's been delivered recently, what's being implemented, what's a prototype, and what's to be done next.

The next step was to look at the 400+ other backlog lines.  These had been gathered over the years from various sources - developers and salespeople's whims, prospective customers' whims, customer complaints, etc.  Fortunately we'd recorded the source for each of these requests.  Unfortunately the person writing down or transcribing the requests had not always done a good job of ensuring that the request was understandable to other readers.  Trying to prioritise all of these individual requests would be pointless, but I could at least group them into related areas.

Grouping the backlog of requests then allowed me to get a picture of what had been requested in different areas, irrespective of who had requested it and when.  I could now identify duplicate entries and remove them.  I could also identify related requests and combine them.  The lack of grouping previously had also made the categorisaton of requests rather haphazard, further contributing to the difficulty of managing the requests.  A series of painstaking reviews have now imposed some consistency on the categorisation.  The result is that the reader can now find information more easily, which is a fundamental (yet often overlooked) requirement of any document.

Anyone working on a particular area can now see if there was a minor requests in that area or a refactoring suggestions in that area of the product and choose to incorporate that minor request or refactoring into their current feature development.

I've still to bring the backlog fully up to date, but now it is at least manageable.

Stop Appraising, Start Coaching

Staff appraisal is an existence-justifying HR procedure devised and administered by HR automata unable to think beyond their own desks, implemented in such a way as to create multiple obstacles to efficient operations in an organisation.  Mandated by HR managers and blindly implemented it is a fine example of the management team being typically the least team-like part of an organisation.

The dreaded staff review or appraisal - dreaded by the appraisers and appraised alike - whether it's conducted annually, quarterly or however often - though a frequent staff review system would push HR's existence-justifying bureaucracy to an extreme that even they might baulk at - is designed as an exercise in bureaucracy, conceived by HR personnel for their own self-serving benefit.  The bureaucratic products of staff appraisals might even be put to some other HR-determined process: allocation of bonuses, determination of salary raises, etc but all hidden behind HR's walls.

The senior echelons of management might even stick their fingers into the HR-mandated appraisal form so that appraisals are "aligned to the business" (or at least pluck phrases from the vacuous mission statement) but with little or no conception of what the appraised staff actually do, let alone whether such an appraisal might help those staff do what they do better or even if they could do things better for the business beyond their asserted (and thus untested) "alignments" to mission statements.

Indeed, no lesser figure than W Edwards Deming listed "Evaluation of performance, merit rating or annual review" as one of his "Seven Deadly Diseases of Western Management"

You might begin to think, dear reader, that I hold something against appraisals or reviews.  Quite to the contrary, for the act of appraising or reviewing against one or more objectives is not an inherently bad thing.  On its own it is neutral, but place it in different contexts and it takes on different properties.  Put it in the context of an exercise that seemingly benefits one party at the expense of another and it becomes a bad thing, at least from the perspective of the party who receives no or a negative benefit (while the one who seemingly benefits may perceive a benefit which in the greater scheme of things is again of no actual benefit).  In contrast, the act of appraising or reviewing against one or more objectives is a fundamental part of the plan-do-check-act cycle, or the inspect and adapt cycle, or any of the other iterative improvement practices.