ingvald

First and foremost:

Focus on work items, not people.

Then:

Finishing is more important than starting.

Practical tip: start to the right/ at the end of your board, and identify impediments to finishing tasks as you go upstream on the board.

Only two questions are really necessary in the actual standup if the team’s real process is reflected on the board:

 The team will be asked if the board accurately reflects what is being worked upon. The team will be asked if there is anything that is slowing down or stopping throughput. After these two questions are answered by the team, the stand-up is over.

(Karl Scotland via @dpjoyce.)

The goal is to enable you to be more agile, i.e., to improve your ability to change and adjust.

Here’s what I think:

• Goals: rapid feedback, fail fast, always releasable, simple (i.e., easy to use)
• Visibility is important here, too: Everyone can see what’s happening

Mainline and CI

• There should be a mainline – Everyone Commits To the Mainline Every Day
• IMO, the mainline – i.e., what you are working on every day – should be ready to release from at almost any time. This implies low technical debt, and little difference between mainline and a release branch (if you use that) – i.e., less work in progress at any time.
• Maybe a release branch is a good idea - where you actually can release from at any time

• Beware of feature branches, and kill them as soon as you can if you do use them. (One tip: feature toggle)
• Branches: Merge from mainline every day if you have them.
• Good naming goes for build code and infrastructure, too, so I’d prefer branch names like mainline, release, featureA, fixB
• Limit branches agressively – they represent more work in progress (and you want less work in progress) including risk of big merges
• 

  Illustration from Henrik's article

  Merging: merge down, copy up – always accept stabilizing changes, never impose destabilizing changes.

Inspiration:

Martin Fowler: articles on continuous integration

Henrik Kniberg: Agile version control with multiple teams

Last week I looked at my overgrown todo list, or rather several lists, and preparation for a demo at work was coming up, and I have a long trip to prepare for…

So I simply had to create a personal kanban on the cupboard behind me:

Collaboration on the demo preparation led to tasks on the board, and I took the most important and urgent tasks from my todo lists onto the board.

I used a form of priority filter, with a generic todo column to the left, then a “soon”/today column, then the usual doing and done columns.

It worked really well to let tasks float up and to the right in the todo columns, kind of like bubbles. I got an immediate impression of relative urgency (more to the right) and relative importance (upwards), making it very easy to decide what the next task should be when I finished a task.

Monday February 7 I talked about Kanban at Trondheim XP & Agile Meetup.

I think it went well, even if I made a few presenter mistakes, based on feedback and the great questions and discussions.

Here’s the presentation with a few adjustments, like a few additional links for further reading.