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.

Normalisation of Deviance

Piers Bizony's article "Challenging the Establishment" in the 6th September edition of Engineering and Technology introduced me to the phrase "normalisation of deviance"

Essentially, when there is normalisation of deviance people accept the current practice (regard it as normal) despite it deviating from best practice, or they may not realise what best practice is.

If anyone then comes along to change anything, the practitioners of the normalised deviance question the need for change.

"We've been doing this for so long and nothing has broken, so why change?"

Then something catastrophic happens such as the Challenger shuttle exploding because of frozen rubber O-rings causing a leak in the solid fuel booster rockets.

Normalisation of deviance also applies to poor software engineering.

"I've never had to refactor code/write shorter methods/use descriptive names/etc before, so why should I start now?"

"This code was written before and accepted, so why should I change it now?"

It become acceptable that code is hard to maintain because "that's just the way it is".

In software engineering this deviance will manifest itself in high rates of bugs and increased development costs as software maintenance becomes increasingly costly - not as dramatic as a space shuttle exploding.

MIET

I'm now officially a Member of the Institution of Engineering and Technology (IET) after an application process with rather a lot of unexpected to-ing and fro-ing from communications between my sponsor and the IET getting lost. So, I now have another group of letters to put after my name.

The biggest difference between the British Computer Society (BCS) and the IET is in their publications. The IET website and members journal (E&T) are a lot more engaging than the BCS website and its members journal (ITNow) - though ITNow has featured some passionate engagement recently (but I'm still waiting for my copy to arrive). E&T features engaging articles that go into depth, whilst ITNow articles often appear to be lightweight puffs for products and services by their authors. Also, at around 70,000 members, the BCS can only manage to produce a journal with a handfull of pages, whilst the IET with 150,000 members produces a monthly journal with much more than twice as many pages.

Whilst at university I had the choice between the BCS and the Institution of Electrical Engineers (IEE) (who would later merge to form the IET). At that time I considered myself very much to be a computer scientist, not an electrical engineer.

After graduating (a few times) I saw no value in being a BCS member so I resigned.

After a few years I began to see myself as a software engineer, and that what I was doing was engineering. Since the BCS was a member of the Engineering Council I rejoined the BCS and eventually attained Chartered Engineer status. Unfortunately, I see less and less evidence of engineering in the BCS, whilst the IET certainly maintains its engineering face.

Wise Customer went to the house of Proud Businessman

Wise Customer greeted Proud Businessman, "Greetings Proud Businessman, I wish to purchase a service from you, but I must first ask a question."

Proud Businessman replied, "Greetings Wise Customer, my heart is gladdened that you wish to purchase a service. But do tell me what question troubles you"

Wise Customer asked, "Proud Businessman, with your service I hope to increase the quantity of gold flowing into my chest, but the cost of your service will take a great deal of gold from my chest. How do I know that the service you provide will be good?"

Proud Businessman opened the door to a storage room and bade Wise Customer to enter. Proud Businessman pointed to a stack of parchment at the back of the room bearing the legend ISO 9001 and said, "Behold Wise Customer, do not be afraid of the quality of my service, for we have a quality process."

Wise Customer brushed a cobweb from his eyes and said, "Proud Businessman my eyes clearly see that there is much dust gathered on these parchments. How can that be so?"

"The lines on my face and the greyness of my hair show you my age, just as the thickness of the dust shows that I have had a quality process for many years." replied Proud Businessman

Wise Customer thanked Proud Businessman saying that he must visit his apothecary for he had developed an irritation from the dust and must seek an ointment to provide relief.

Proud Businessman was happy for he had just received a wealthy government contract that morning.

Agile Success

I'm always interested in project success, so I was drawn to this article in CIO.com: "5 Principles for Reducing IT Project Failure"

Rather than being IT-specific I would say that these are simply 5 principles for reducing project failure:

1. Communicate: If everyone involved in your IT project doesn’t know what they’re working on, when it’s due, how to get it done and who the audience is, how can you possibly expect your project to succeed?

The aim is to ensure that everyone in the project knows what is going on, what is expected, when it's expected, for whom it's expected, etc. Nobody is then treated like a mushroom kept in the dark and fed fertiliser.

2. Consolidate: We’re talking about information and tasks here.

If you can't find the right information for what you're working on, or it takes you a long time to find it, you are wasting time and effort that can be better spent working constructively towards your project goals. Reduce bureaucracy, cut through the red tape and put information within easy reach so everyone can do the job that they are supposed to be doing.

3. Prioritize: Issues come in, bugs are discovered, and new application features are conceived of every day.

Dropping everything to work on a just-reported bug, or to do a "quick job" for someone is probably not the best use of someone's time. The bug may be of lower priority than what you are currently working on. The "quick job" is a distraction where your time can be better spent working on something delivering higher value.

4. Requirements: In ALM and your SDLC, before you can do anything else, you need to identify, prioritize and agree on application (and project) requirements.

It is fundamental that you need to know what the requirements are before you work on something. Once requirements are elicited, they can be analysed and prioritised. Misunderstandings can be removed to ensure that the project team and stakeholders are of one view as to what the requirements are. Understood requirements mean that something can be designed and built. Understood requirements mean that a plan can be made to test them.

5. Manage Time: As management, it’s up to you to take the first step in setting reasonable deadlines and milestones for your team throughout the project.

Knowing where you are in a project, where you should be and how fast you are delivering are vital pieces of information in determining what will be delivered by when.

Alternatively, these are just, 5 Agile/Scrum principles.


1. Communicate

Scrum revolves around a cross-functional, self-organising Scrum Team that has a daily stand-up meeting where every team member communicates what he did the previous day, what he is committing to do today and if he has any blockages or impediments.

Developers, testers, DBAs, designers, BAs are all kept informed of what all the other members of the Scrum Team are doing.

Scrum also involves the whole Scrum Team being involved in the Sprint Planning.

The Scrum Board and Burndown Chart should be visible to all, so everybody can see what the Scrum Team is working on, and what their progress is - instant reporting!

2. Consolidate

Agility is about individuals and interactions being valued more than processes and tools, and about working code being valued more than comprehensive documentation. "Muda", one of the Toyota Principles, is focused on removing waste, where waste means wasted materials but also means wasted time and effort.

Agile practices refer to doing "just enough" or doing what is "sufficient and necessary". Agile teams commonly use wikis to document information, they record requirements on cards or Post It notes which are kept on the Scrum Board (or Kanban Board).

3. Prioritise

Scrum requires the Product Owner to prioritise work. The Scrum Team only works on what is currently the highest priority collection of requirements. Requirements should be prioritised so that the ones delivering the highest business value are delivered first. Also, those requirements which eliminate the most risk should also be prioritised highest.

Considering simply high and low business value and risk, the best order in which to prioritise requirements according to their business value and risk is:

1. High risk, High business value
2. Low risk, High business value
3. Low risk, Low business value
4. High risk, Low business value

The aim is to eliminate as much risk and deliver as much business value as early as possible, overall delivering a high ROI. Risk can also be categorised as uncertainty - the uncertainty that something is feasible.

Bugs, new requirements, existing requirements all go on the backlog and are prioritised accordingly.


4. Requirements

Scrum can not proceed without requirements.

The list of requirements is maintained in a Product Backlog, in priority order (c.f. Prioritise)


5. Manage Time

Scrum sets regular deadlines for the Scrum Team to commit itself to delivering working software satisfying the requirements.

Progress is visible on the Scrum Board - which presents a snapshot of progress in terms of what's Done, what the team are Doing and what's still To Do. Progress is also visible in the Burndown Chart which shows the rate of progress.

Requirements and tasks are estimated by the people who will do the work - acknowledged to be more accurate than estimates by people who do not do the work - and that knowledge is used to set realistic expectations.

Daily reporting in the Daily Scrum means that people are held accountable to the whole Scrum Team for the commitments they make each day.


So, 5 principles for reducing IT project failure are satisfied by Agile practices. Though I often remark that what are often regarded as Agile practices (coding standards, continuous integration, etc.) are just good engineering practices. So, Alistair Cockburn is right that Agile is the norm - it's just good practice.

Software Development is not a Production Line

I was discussing the software development process with one of the architects in my team this afternoon. The key observation was that software development is not a production line; the only production line in software development is when you're stamping out the media once the software has been developed.

Software development, by the very nature of software, suffers from maleability. Because it is relatively easy to change software, change ensues.

Walter Vincenti in "What Engineers know and how they know it" coined the terms "normal design" and "radical design".

Normal design is when "...the engineer knows at the outset how the device works, customary features, and if you design it properly along such lines, good likelihood of accomplishing the desired task".

Radical design is where you are doing something new and innovative and you don’t know how it should be arranged, you don’t know how it works, you’ve never really seen anything quite like this before and you have no presumption of success.

Microprocessor Development

Microprocessor development is comparable to software development: there is lots of design work and experimentation, then the resulting microprocessor is stamped out on a production line.

The environments in which microprocessors find themselves deployed are a lot more controlled than software, the microprocessor's interface to the circuit board on which it is mounted is well defined, the strength, potential, frequency and shape of the signals the microprocessor receives is fairly well defined.

Software, particularly when used by humans (or other software created by humans), deals with a vastly more complex environment.

Craftsmen

Rather than production line workers the people involved in producing software are like a collection of craftsmen.

Like a craftsman, whenever working on a problem, each one will:

• analyse the problem to some degree
  (the stone sculptor will observe and feel the stone)
• design a solution, or a sufficient first step
  (the stone sculptor will decide where the first major cuts will be)
• implement a solution
  (the stone sculptor will start hammering and chiseling at the stone based on his design)
• test the solution
  (the sculptor will look at the carved stone to decide whether it matches the subject)

The State of Agile in 2009

VersionOne have released their fourth annual State of Agile Development Survey results for 2009

I still find it odd that people regard things like coding standards, refactoring and unit testing, as agile techniques; even continuous integration and automated builds. These techniques are just good software engineering practice and should be used everywhere, irrespective of whether you are trying to be agile or not.

Lack of experience with agile methods was the largest reported cause of failed agile projects. Though it's not clear whether the report means failed projects that were supposed to be agile or projects where the agility failed.

Would you Employ only a Certified Software Engineer?

I posted the following in a group on LinkedIn after a question in the group asking what the focus of the BCS should be in 2010:

Would you employ an amateur, DIY bricklayer to build your wall?
Would you employ someone who's read a couple of accountancy books to be your accountant?

Chances are you answer is "no".

Would you employ an amateur hobbyist coder?

Chances are, the answer is "yes".

Would you build a brick wall for yourself, or would you help do the books for your club?

Chances are, the answer is "yes"

Computer programming (and that's my background) is an area where everybody feels that they can do a bit of DIY bricklaying - especially with some scripts and a spreadsheet which then becomes a business-critical application.

Professional accreditation is all well and good, but there is no difference (from employers' perspectives) between a hobbyist coder and a CITP-holder.

Other professions (law, accountancy, medicine) require their professionals to have some professional training as well as their basic qualifications. It's also difficult to be an un-registered lawyer, accountant, doctor, etc. So there is a consequence for not being professionally recognised.

Maybe we need a new CSE for the 21st century, a Certified Software Engineer. The holder of such a certification would have to demonstrate good software engineering skills: requirements elicitation, requirements modelling, solution design, coding standards, testing, source control, documentation, maintenance, etc.

Experience Counts for Less?

The Wall Street Journal article "Dangers of Clinging to Solutions of the Past" illustrates the value of challenging assumptions and the inspect-and-adapt cycle. Whilst the article boldly asserts that increased experience leads to increased project failures, this is attributed to an increased confidence on behalf of the project managers concerned.

I would like to add that it is of little use to know that a practice worked previously without knowing why it actually worked, and conversely one should also know why something did not work in a particular situation. By knowing the "why" one is able to apply the experience to the appropriate situation.

We can only discover the reasons by taking the time to ask ourselves what those reasons are. Scrum's retrospective meeting (a post-iteration review) generally poses 3 questions:

• What went well?
• What went wrong?
• What to do better, and how?

I would now say that the 3 questions should be posed as:

• What went well, and why?
• What went wrong, and why?
• What to do better, and how?

Peopleware: you must read this book!

Many people have heard the quote that the best software developers are 10 times more productive than the worst. Whilst I was reading the course material for my course in project management I came across the source for this statistic:

"Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister, 2nd edition, Dorset House, 1999

Reading this book you get to see the rest of the results:

• the best developers are 2.5 times more productive than the average - so there are a lot of very unproductive developers out there
• the best developers are in development teams that are 10 times more productive than the worst teams - it's not just about individuals, but who they work with, who they work for and in what kind of environment they work
• people are more productive when they have fewer distractions - obvious, but lost on many managers
• Parkinson's Law was a joke about a bureaucracy, not a general observation
• higher pressure does not improve productivity and/or quality

After just reading a couple of pages I came to the conclusion that this book should be made a mandatory read before anyone takes on a new position as a manager - including, or especially, several of my previous managers!

I've only read a few chapters, but my enthusiam shows no bounds.

Nam et ipsa scientia potestas est

At a reception for us fresh-faced (well, maybe more like spotty-faced) computer science freshers in 1987 I was asked by a fellow student what I thought the best computer was. My answer was, "Orac from Blake's 7"

Thinking back it may not have been such a facetious answer.

Orac was powerful because it networked with other computers, not just sitting there on its own like the traditional super-computer of science fiction (and super-computers 30 years ago). Orac had the ability to communicate with all other computers that carry tarriel cells - the basic component of all computer systems in the Blake's 7 future, designed by Ensor (Orac's creator) at a young age.

Able to mine any data on any computer system it had a vast wealth of raw data at its disposal that it could process into useful information. Thirty years on from the creation of Blake's 7 we are beginning to see the wealth of information that can be provided by the Internet and the beginnings of practical distributed computing in the form of cloud computing.

As Sun Microsystems says: the network is the computer