There’s a follow-on to the objective of improvement too. The question “Do we need to do retrospectives ?” becomes “Can we improve ?” and I think the answer to that is almost always yes. Granted, I guess there will be some teams for whom this kind of inspect/adapt cycle happens spontaneously without the formality of a retrospective, but for the vast majority of teams, retrospectives pay dividends.

So anyway, I tried to sum this up in a statement which could be read out with the prime directive, or rolled into working practices, or whatever.

We would like to think we could be the perfect team, but we accept that almost nothing is perfect, and we can improve how we work.

Since the last retrospective, we did lots of things, and lots of things happened. Some were good, and maybe some were bad.

Let’s look at the most significant of those things, and see what we can learn about improving how we work as a team.

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

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

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

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

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

Some intial thoughts: Some of the deep detail may go too far. For example my reading of the model is that stories are always subordinate to a higher level feature, and similarly features are always part of a release. For the perspective of a team working on a product that has matured somewhat, we find ourselves working on a mix of both large features and small enhancements to existing functionality. Should we consider those small enhancements as features in their own right in this model, or create artificial features to encapsulate them ? Neither I think, the small enhancements exist as stories in their own right, without an encapsulating feature.

I find it interesting to compare this model with that advocated in the Open Agile process. This also extends the concept of a backlog item beyond a mere story, but the extension there encompasses Quality Items (bugs), Obstacles (impediments) and Calendar Items. Again I find this relevant to my own situation where working with a relatively mature product entails more than just dealing with new functionality neatly boxed as user stories.

I look forward to further developments towards a ubiquitous language (if not a ubiquitous model) suitable for all flavours of Agile.

Technorati Tags: agile, model, openagile, scrum

We’ve reached a point where, for a variety of reasons, that doesn’t feel right anymore. Reasons include:

• The product is released and fairly mature. Coding work includes a lot of tweaks, enhancements, bug-fixes in addition to new development.
• Planning and estimation feel rushed. Applying arbitrary time-boxing to these activities doesn’t feel right when a little extra chat / research can prevent nasty surprises during the sprint.
• We don’t seem to have any proper time or place to help stakeholders develop simple requests for functionality into reasonable user stories that can be estimated.

So we’ve adopted a new practice: A week between 2-week sprints that we’ve called (after going through some flippant alternatives) jog week.

So now the pattern is something like this:

• Product owner meeting works on the backlog every Tuesday. (During sprint weeks this is mostly adding and reviewing new stories with stakeholders, during jog week it’s primarily prioritisation)
• Developers do estimation on every Wednesday (jog or sprint) for an hour. We seem to get through maybe 8-12 stories in that time.
• Planning (including tasking user stories) takes place on Thursday of jog week.
• Sprint Review takes place on the last day of the sprint
• Besides the above, the rest of jog week is taken up with bugfixes and ad-hoc technical requests, helping stakeholders develop user stories to the point where they can be estimated, refactoring, reading coding/agile blogs, etc.

We’ve still got to work on the details, but based on the two jog weeks so far, we’ve got more than enough to fill up that third week.

Technorati Tags: agile, bugs, estimation, jog, planning, scrum, sprint

Technorati Tags: wisdomofcrowds

Feeling pretty chuffed, actually

Technorati Tags: bass, eub