Death March

15 June 2010 by Stuart Cam
Death March - Edward Yourdon
Death March - Edward Yourdon
  1. Customer's requirements are captured in written form
  2. Requirements are transformed into further written documentation
  3. Timescales are predicted using guesswork and multiplication
  4. Invariably this process always results in a bid for work
  5. Cost is calcuated as a function of timescales and resources
  6. The statement of work is drawn up to include as many get-out-of-jail-free loopholes as possible
  7. The schedule is unveiled, all hail the schedule
  8. Developer units are hired to work to the schedule
  9. Requirements and specifications are buried in word documents and spreadsheets
  10. Key knowledge held by people who are disconnected from development
  11. Distributed teams make communication difficult
  12. Development derives additional requirements during the solution process
  13. Customer changes requirements
  14. Cycles of rework begin
  15. Plan starts to slip
  16. Management become unhappy
  17. Pressure begins to mount and quality begins to suffer
  18. Developers suggest solutions, but these are stifled or trivialised
  19. Retrospectives are conducted behind closed doors
  20. A new schedule is drawn up, goto 7.
  21. Morale plummets
  22. Self-preservation begins to take over
  23. The development team starts to dissolve

I wonder what the outcome will be?

Tags: ,

Categories: Management

Kanban Experiment

27 February 2010 by Stuart Cam


What do you do when your development process is in pieces, hundreds of defects are being raised against your code, ad-hoc work requests are piling up, the developers are groaning 'if we only had the time to make these improvements life would be easier' whilst the fixed deadline is looming.

If you find yourself in this situation the simplest and easiest thing to do is walk out the door.

It may be that the project you are working on is so fundamentally broken that even the most talented development team in the world still has no chance of succeeding. Hundreds of decisions are made during the project inception stage and each one can affect the overall chances of success. By the time the developers arrive the problems have solidified, and given their nature (financial, contractual, resourcing, managerial) the developers are, for political reasons or otherwise, unable to tackle them. Another death march begins.

Adding developers to a project with fixed deadlines, fixed deliverables in a fixed price contract rarely produces good software and in the worst case can leave the company responsible for delivery in ruins, perhaps even bankrupt.

I've been contracting long enough to realise that the majority of the problems I face as a software developer are not software development related, but both project management and business related. I'm not saying that all companies are like this, but that some companies are more deadly than others.


If you find yourself on a challenged project and are courageous enough to go the extra mile you can try and introduce some order onto the chaos, patching up the major holes as best you can. A do-it-or-die attitude is required because you'll probably ruffle somebody's feathers in the process.

Given the above situation, I decided go back first principles and implement a Kanban system with the help of my team, in the face of some serious project challenges.


First, you'll need a large wall space, some marker pens, coloured tape, sticky dots and post-its. If walls with whiteboards are in short supply then the back of some borrowed cupboards will suffice.

We loaded the Kanban with our backlog, giving each type of work a different coloured post-it:

Use Case

A large chunk of work which needs to be broken down into smaller tasks. Many tasks go together to form a complete Use Case.


A task for a particular Use Case of sufficient size to be estimated and worked on by a developer(s).


Improvements are internally generated within the development team. An example may be a largish refactoring opportunity, automated process or tools upgrade. The point here is that time spent on an improvement will increase the flow of other post-its across the board.


Raised by the test team on the current release of code. These defects are raised and entered through an external system, the post-its are placed on the Kanban to track the work in progress.


Externally generated work, perhaps as a result of a customer demonstration.


Can be placed on any other post-it to denote that there is an outstanding issue, complete with a description of the problem.

As well as colour coding each card contained the following information:

  • Date the post-it arrived on the board.
  • A description of the work item.
  • Priority denoted with a coloured sticky dot, for defects this dot represented severity.
  • Initials of the current owner.
  • Time spent on the work item. We would dot all items that were in progress every half day.
  • Optional. Date the post-it needs to be completed by.
  • Optional. Identifier from the external system, e.g. Defect Id.

The team were educated on the system in under half a day and by week 4 our Kanban had grown to incorporate another cupboard and many more modifications:

Kanban - Week 4

We cleared the finished section of the board (far right) every week. The board above is telling us that we spent a lot of our time addressing failure demand in the form of defects. The concern here is that the actual estimated and paid for work is represented by the pink post-its on the far left and they didn't move for over a month!


The Good

  • The teams focus was aligned to completing work.
  • Encourages the team to recognise, record and make improvements.
  • Anybody can write up a post-it and add to the backlog, I'd often say "don't tell me, tell the board".
  • Single visualisation of the work backlog, work in progress and work completed.
  • See different types of work at a glance.
  • The team has autonomy over pulling new work, creating a sense of ownership which is lost when work is assigned.
  • Managers can prioritise work in the backlog.
  • Colourful and tactile, giving a sense of fun to the project.
  • Flexible and adoptable. We altered the board as our understanding improved.
  • Simple and cheap. The total cost of implementation was less than £30.
  • Easy to gather metrics about how much work the team can get done.
  • The simplicity of the solution promotes the idea that it is easy to change and customise.

The Bad

  • Doesn't work with distributed development teams for obvious reasons.
  • It's simplicity can be interpreted as amateurish which results in the idea being written off.
  • Easy to forget to mark post-its with key information, particularly dates and owner information.
  • Can be difficult to find a particular post-it, the problem somewhat compounded by using identifiers from external tools.
  • No backup, although conversely it's less likely to crash and lose your data!

The Impact

  • The board showed us that there was more work that needed doing than was planned or imagined.
  • The previous development approach had led to a lot of defects.
  • Developers can self-organise and work honestly if they are given the chance.
  • The role of management is to remove problems (purple post-its) and to optimise the system to improve the flow of work through it.

The Kanban board provided us with a greater level of insight into what was happening on our project. The visualisation of work enabled us to make better decisions about how to utilise our time. By recognising that we have a finite number of resources and a large amount of work, we can make team decisions about how best to proceed.

In some ways the Kanban board affirmed what we already knew, that our project was seriously challenged, but it also gave us a framework to work within. Understanding and learning about your situation is simply the first step in escaping it, without walking through the door!

Tags: , , ,

Categories: Agile | Management

© Codebrain 2021. All Rights Reserved. Registered in England: 07744920. VAT: GB 119 4078 13