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.