Tag Archives: system

Kanban learnings – Running multiple projects hides impediments

Posted on by

Basically the orgininal Kanban board:

Kanban with overcommit

Was reduced to:

Kanban checklists

Posted on by

Anytime
(Shall be visible with the glance of an eye)

  • Do we have a bottleneck? (look for congestion/queues)
  • Do we have an impediment not dealt with?
  • Are we keeping our work in progress limit (WiP)?
  • Are priorities clear?

Iteration planning (1/week or on need basis)

Expected outcome:

  • Prognosed delivery date given to PO if needed.
    (Use size/velocity or tasks * cycle time)
  • Stories is broken down and estimated

Schedule

  1. Update charts (velocity and cycle time)
  2. Remove done stories/tasks off kanban board
  3. Lookback last week [max 5 min]
    (What happened? Are we satisfied? Should we adjust WiP limit?)
  4. Team picks one thing to improve on for upcoming week [max 2 min]
  5. Write this down on top of Kanbanboard
  6. PO reads new stories to team
  7. Team breaks down and estimates stories [30 min]
  8. PO revises priorities and makes them visible

Checklist

  • Can all team members do the broken down tasks?
  • Is WiP limit visible on board?
  • Can we see if we exceed WiP limit at any time?

Daily standup

Expected outcome

  • Impediments are surfaced so we deal with them
  • Team members can share experience of problems earlier encountered
  • NEVER takes more than 5 min (takes some training but is doable)

Schedule

  1. What did I do yesterday
  2. What will I do today
  3. Do I have an impediment?
  4. As a team, do we need to act?

Rule:

  • "60sek rule", you have 60s to offer advice to other team members if you can help them
  • All other matter : face2face after daily standup

Doing 45 minute sprint planning

Posted on by

  1. Hand out the epics (we typically have 2-3 per week)
  2. Assign one senior and one junior for each epic
  3. Forming a group per epic by letting rest of team choose from interest, but allow no larger than four members in per group
  4. Let each epic team do breakdown and size estimation
  5. Swap epic between the teams and review (we typically let one person stay and explain)

45min sprint planning

This has worked out really well. The energy and intensity of the discussions was raised significally. So far we have managed to keep our 45 time window almost every time. .A bonus is that the review almost every time have results in an changed task or a reestimation.  Thereby showing the value of a second opinion with an outside angle.

Why we are better off monitor our queues

Posted on by

The other (not so obvious!) way is to look at the size of the queue in front of the process. Because if we know the work time and queue size, we can derive the rest.

Cycle time measurement

Apart from this, the queue can tell us a lot more which cycle time necessary don’t:

  • If we have a bottleneck our system
  • Disruptive flows such as bursts in arrival of work

The queues are simple easy visual ways of learning us about variance in our system. And variance eats predictability for breakfast.

The same fact is actually mathimatically demonstrated in Little’s Law:

Little's law

Number of things in process = sum of items in queue and process. So by eliminating the queues we get a faster cycle time.

Thus,

  • cycle time is a trailing indicator
  • queue utilization is a leading indicator

Unfortunately, we very seldom in monitor the latter!

Planning ahead in Scrum

Posted on by

In Toyota Production System (TPS) action takes place through the Plan-Do-Check-Act-Cycle

Plan-Do-Check-Act

If we relate this to Scrum we see a lot of emphasis on the Do, Check, Act part. But not as much on the plan part. Planning is usually explained as a an activity that takes place on sprint planning day where both team and product owner are participating.

However, how do we deal with situations like:

  • stories that require a multi team effort
  • interfaces to third party systems

..and given a definition of  done "running in production" are we answering questions like:

  • are we implementing the right solution to our problem?
  • is our delivery useful to our recipients?
  • have we got access to necessary resources?
  • can we test? can we deploy?

Basically we need continuously run a thought process in the sprint before we do the implementation. Typically a development team spend around 20% of their time planning for their implementation (Mary Poppendieck).

Thinking ahead
The deliverable for the thought process is "story has business value and is estimatable"
So how do we go about?

Option 1: Use scrum master as an analyst
Appoint the Scrum master as the responsible person for dealing with forward thinking.

Pro’s:

  • SM is already a contact point
  • He does not suffer as much from interupt control as other team members

Con’s

  • Not always the correct technical person for solutions
  • Team can feel overrun

Option 2: Use an external analyst
Get a dedicated analyst in the team that always looks forward.

Pro’s:

  • Releaves team from communication stress

Con’s

  • Adds an extra handover step (waste)
  • Needs to be a superb communicator with team.
  • Analysts tend to lean over to business focus
  • Communication issues remain hidden

Option 3: Assign a "look ahead" story for each sprint
Insert a story which makes next sprint stories estimatable.
Team can pick tasks from this story in same way as on normal stories.

Pro’s:

  • Team can choose among the stories in normal scrum way
  • Communication issues are surfaced
  • Bonding to outside parties is preserved in team

Con’s

  • Product owner needs to have a forward vision
  • Team members might need training in communication skills
  • Implementation might suffer if extensive travel is required

My personal preference is with the option #3. But I have also seen option #1working in Scrum teams. The bottom line is that you need to think this through or you might end up building software that does not deliver intended business value.