Ones and Threes

I’ve achieved two of my objectives in implementing Kanban, and they’re both down to the visualisation of workflow.

The products stakeholders were introduced to the Kanban board yesterday.

All I had to say was “pink and purple are emergencies and support tickets, yellow is the coding you want us to do, and the flow is left to right” and they got it. They got a message that coders have been trying (unsuccessfully) to convey to them for many years. Yes, ad hoc stuff gets in the way of scheduled development. (The green, by the way, is tasks the team has found they need to do to facilitate other work)

The second success came at the end of the stakeholder meeting when they spontaneously decided (no prompting from me) that they needed to prioritise the ad hoc stuff against the scheduled stuff, and we walked over to the Kanban board to do it.

The power of visualisation.

Technorati Tags: agile, kanban, lean, visualisation, workflow

We’re a small scrum team. Very small. Temporarily down to 2 developers, one of whom is part-time scrummaster, plus one product owner. The developers are responsible for not only new development, but also function as 2nd-level production support and helping stakeholders develop their user stories into a do-able form (acceptance criteria, etc).

This leads to conflicts of priorities. 2nd-level support can be hugely disruptive, taking out one developer from a half-day to 2 full days for some issues, which has the effect of stopping the sprint if one developer is on holiday. Partially complete sprints are a too-regular ocurrence therefore.

We’ve attempted to ring-fence the two non-sprint activities. Support work goes to the ‘duty developer’ (a role that rotates between the two developers) and should be time-boxed to no more than 2/3 of a working day in total. And story development should take place only in ‘jog week‘ (a week between two week sprints).

In practice, both non-sprint activities break out of their respective constraints. E.g. when the business decides an unhappy customer needs placating NOW, the team has to do it, and the scheduled sprint work suffers, and of course some user stories are therefore delayed by a full sprint cycle.

Essentially, it’s a combination of

• a team with a responsibility for both development and an unpredictable support workload
• a team too small to absorb workload fluctuations easily

that means that scrum is not working well for us.

So Kanban looks like a solution for two reasons.

Firstly, no timeboxed iterations should mean that if there’s a change in priorities (insertion of an urgent workitem), then less urgent items move back one place in the queue, not a full 3 weeks.

Secondly, the business will need to weigh priorities between regular development and must-do items arriving via production support. I think the whole process will become much more transparent, in contrast to the current situation.

The details of our implementation need still need sorting out, but the idea is building momentum and it seems likely we’ll go for it.

Looking forward to it.

Technorati Tags: agile, kanban, lean, scrum