Sunday, February 22, 2015

Triage may seem cruel, but it could save your product

Triage is a term from the battlefield. To be more specific from the battlefield mobile hospitals.

So triage should not have a place in the – comparatively peaceful – world of software development. Or should it?

Sometimes you can’t get them all

It’s all about the question of how to make the best use of your resources in times when the demand exceeds the resources.

The original idea behind triage was to categorize the wounded into three categories (as described more closely in the wikipedia article on triage)

  • Those who are likely to live, regardless of what care they receive
  • Those who are likely to die, regardless of what care they receive
  • Those who would die if they did not receive immediate care but are likely to live if the do get immediate care

and then concentrate your resources on the category where your effort really makes a difference. In the original case this means to start with the third category – cruel though it may seem for the other two categories.

Over the course of time the rationale and theory behind triage have evolved immensely, as can be seen in the article. Both the ethics and the practical application have been refined, but the basic idea is stimm the same. Don’t waste your energy on “lost causes” when that would lead to loosing causes you have a chance of rescuing.

What’s that got to do with software development?

In our day to day work we’re often confronted with situations where the requirements exceed our capacity.

If we try to do everything, even if we dynamically reschedule according to priority, some things won’t get done. That is exactly what “requirements exceed capacity” means. And this is exactly where triage fit’s into the model. If only 4 of 11 requirements will “survive” make sure not to waste any effort on those, that will never see the light of day anyway. Put them in a separate “folder” and once you’ve got discretionary time on your hands revisit that folder and check which of the requirements would still provide value.

If we concentrate on the 4 most important requirements first – the amount we can expect to complete – we end up wit only 36% (4/11) of the requirements fulfilled, but the features for those four requirements can be shipped.

But it is never a good idea to try to fulfill all 11 requirements with only enough resources for 4 – we would end up with 11 requirements fulfilled to 36%. And because a feature that is only 36% complete in most cases is not shippable we would end up with zero deliverable features.

No, it does not mean you can skip tests or refactoring

So if we have to cut functionality can’t we go faster by skipping unit test, documentation or refactoring? That would be just silly – just as if the doctors in the battlefield hospital would omit washing their hands as Uncle Bob would probably remark. On the contrary. Applying triage on a requirement level should give you the time and space to work at your optimum on those requirements that can survive.

till next time
  Michael Mahlberg

Tuesday, February 10, 2015

Yes, you do need a “Dashboard” (a.k.a. Andon - Board)

And no, I don‘t like the terms “Project Dashboard”, “Lean Dashboard” or “Agile Dashboard”. I do like the concept of the andon-boards

But what is a(n agile) dashboard, and why do you need it?

Speed is nothing without control

Most lean and agile approaches include some kind of feedback mechanism to enable informed decisions. In Scrum for example some information is fed back into the loop in the sprint planning as the capacity for the next sprint. In flow based approaches the feedback is often build into the work organization. When a kanban approach to process control is in place it can at least be found in the capacity of the stations (a.k.a. WIP-Limits per column).

This may be enough for a while, but it is not enough for the long run.

How often is an autopilot ‘on course’?

Actually not much at all - if it would be possible to set the course once and then ‘just let go’ you wouldn’t need an autopilot. The main reason to have an autopilot is to counteract the little deviations off the course caused by internal or external disturbances. So the autopilot constantly correct to the target, but the target is only reached for very short periods of time.

You’ve got to know that you’re off course to make adjustments

To be able to auto-correct your course, you have to know wether you’re on or off course. And that is what a dashboard can tell you. By making the actual ‘course’ visible as early as possible. On a dashboard. That is updated as soon as the information is available. And this is where an automated dashboard can come in handy.

What should go on the dashboard?

Whatever you’re aiming for!

  • You want to spend a certain amount of your capacity on a specific project? Then the actually spent time per project has to go on the dashboard.
  • You want to increase the test coverage? Then the current test coverage has to be displayed.
  • You want to spend at least x% of your time on improvements? Then the time spent on diferent types of work has to go on the dash.
  • etc.

So, how do you navigate your project?

’till next time
  Michael Mahlberg