Posts Tagged kanban

Kanban for a week?

Starting this month, the development budget for my current project has run out. Our last sprint ended little over a week earlier, and with two-week sprints, we did not feel comfortable planning and starting a new, much shorter sprint. Instead, we switched to a different mode of operation, working in a Kanban-like fashion, fixing minor annoyances and small bugs all around.

For our team, the transition was remarkably smooth. We did away with planning, story points and committing to sprint goals, and replaced it with a list of issues (each roughly the same size that we had in our sprints) and a priority set by the product owner. All the practices we already had in place have stayed the same: we still use pair programming, have an interaction designer on board, and only declare an issue closed when at least one other pair of eyes has looked at it. We did not even have to alter our scrum board, we just removed the headings we used for sprint goals.

With the fixed deadline coming up, we do not plan big features, and keep the product continuously in a shippable state: each issue we handle is one in and of its own, and not part of a bigger feature. If we cannot finish an issue, we just don’t, and nothing gets hurt. This allows us to cope with the interruptions that such a last week brings, without having to worry about leaving the product in an inconsistent state.

All in all, it has worked out perfectly for us. If you are looking at a fixed deadline, and have a few days left that don’t make up an entire sprint, you should try it!

, ,

No Comments

Issue driven kanban standup

Our daily standup is in need of refactoring…recent standup meetings are kind of boring. Each team member does his or her daily blah blah. Time for a change. To tackle this problem, one of the “try this” ideas resulting from our retrospective was to have an issue driven standup. Recently we switched to a more kanban-like process with focus on issues. Therefore the amount of WIP is limited, so going through the work should be doable within the 15m time box we usually need for the standup.

We tried this:

The last question Q3: “when will the issue move to the next lane?”,  is important for the member working in the next column. i.e. a system tester. The tester will know what to expect in his column and he can anticipate on this.

The team reacted enthusiastically to the new style.  Another positive effect was that some blocked issues were picked up and finished rapidly. A fresh approach! Maybe we need to change the  standup pattern every couple of iterations, just to keep the juice flowing.

, , , ,

1 Comment

Scrum to Kanban: what happened to planning?

First thing to do when switching from scrum to kanban: abolish anything remotely related to planning or planning day or planning morning.  We planned a short iteration (a.k.a. sprint) kickoff meeting which ended up in being nearly a planning session. Because of the clear scrum way of planning and ‘the deal’ with the product owner, the team held really tight on to “but we must do planning” – Nope, we are going to start at the top of the selected issues and we’re not going to spend our time on team-wide planning. But if planning helps you in getting the solution more clear, please do so. Next iteration, I’m thinking of having an iteration start in front of the board, standup style to keep it ‘light’.

Whereas scrum is organising the chaos, kanban makes you pick one issue from the chaos and just get it done. Anna Forss expressed it nicely on twitter: “It feels like embracing chaos instead of fighting it.”

, , ,

1 Comment