Ones and Threes

I discovered recently that some team members had never heard of the retrospective prime directive or it’s essential concept of ‘no blame’. To me and the facilitators of our retros the idea was implicit, and never stated so I introduced the concept at the next retrospective.

While doing that, I found myself apologising for the wording of the prime directive, which I found slightly patronising.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

It turns out I’m not alone in having a problem with the current wording. There’s plenty of discussion and some alternatives here and here but I didn’t find any alternatives the really hit the spot for me.

For me the essential driver in this is that we should be able to talk about anything in the retrospective, but that idea could lead directly worries about a blame-fest. So here’s the wording I came up with.

We should be able to talk about anything that happened, even the bad stuff, in a blame-free environment.

We shouldn’t get blamed as a result.

We shouldn’t need to blame anyone. Anything that we saw happening that we didn’t like, happened because somebody had good reasons to do something, that seemed right at the time, given the context.

I’m sure that could be tweaked some more, but that’s what we’re using for now.

Technorati Tags: agile, lean, prime directive, retrospective

I’ve been meaning to write for some time about the way we handle the feedback loop normally known as ‘retrospective’, and I’ve finally been spurred into action by a similarly themed blog post. Here’s how we do it.

At our daily ’standup’ one of the steps (after we’ve reviewed the Kanban board) is that I ask if we’ve got any ‘wishlist’ items. This is the shorthand we’ve adopted for anything we wish would happen to make things better or anything that regularly gives us pain that needs to be addressed. Anything we come up with goes on the ‘wishlist’ which in our case is an AgileZen board with columns for each team member.

Also, if anything arises during normal work that’s an issue that can’t be resolved without deep discussion, that too goes on the wishlist.

Each team member looks after their own wishlist column and keeps the most important stuff at the top.

Then once a week at our regular team meeting we review the top items from each list. We have a small team so there’s no defined process for item selection. Sometimes I pick one that looks important to me, often I ask the team (since we’re all looking at the same board) what’s the next most important item. The ‘product owner’ is part of this meeting, and as a result if we come up with an item that needs a fair amount of work, he can decide if it’s something that goes straight onto our Kanban board, or whether it’s an item that is put back to the product backlog to compete for priority with other work items.

We address ‘wishlist’ items in under a week typically, and if items do get passed over in the team meeting, that’s fine, there was obviously more important stuff to be done. We don’t use the wishlist for true impediments or blockages, those are treated in a stop-the-line fashion, either fix on the spot or at the very least, escalate to the product owner during the daily standup. And any issues that come up during the week that we can resolve within the team with a few minutes chat or perhaps up to an hours action obviously don’t make it to the wishlist board either.

This is working fine for us in our context, closing the loop in a week usually. I hope that gives a few ideas if your own ‘retrospective’ process isn’t working so well.

Technorati Tags: agile, kanban, lean, retrospective

I’ve been nominated to contribute to Agile Retroflection Of the Day 2.0 by Levent. Todays subject is

What Do You Do When You Don’t Know What To Do?

So here goes …

Don’t Know What To Do because there’s nothing demanding my attention ? I take a step back. What was I doing last ? Is it truly finished ? Could it be made better ? What about the thing I did before that ? And before that ? What about the skills I use to do all these things, could they be improved ? Would I get better results if I studied some more or practised some more ? What has gone wrong recently ? Is there a pattern to those things ? If there’s a repeating pattern, maybe there’s something that can be done to prevent the problem recurring ?

Don’t Know What To Do because I’m stuck on, or confused about, my current task ? I take a step back. What is it I’m trying to do ? Not the immediate thing I’m working on but the underlying purpose of that task. If the task came to me from someone else, I talk to them. And in any case, I try to work out the the real boundaries of the problem and see if there’s a different approach that may yield results. If it still looks hard, is it worth digging deeper for another purpose underlying the one I’ve already found. And of course, what about other people who’ve attempted the same task, colleagues, friends, family or people like me who are online ?

There you go. Nothing earth-shattering, you’d think, but I know from personal experience not everyone explores all those avenues. And I’m sure there are more that I don’t do that I should. You’ll detect the technical angle in the above (not surprising, since I’m a Developer and a Dev Team Leader) but I think the principles are broader than that.

Thanks for the opportunity Yves and Levent.

Technorati Tags: agile, Coding

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