• All
  • Agile
  • Agile Adoption
  • Agile Organisations
  • Coaching
  • JAFAC
  • KanbanFor1
  • Product Development
  • Product Owner
  • Retrospectives
  • Scrum Master
  • Self-Selection
  • User stories

Utilisation, Teams and “Resources”

In many companies, especially those who provide services to external clients, the main focus from a project management perspective seems to be on resource allocation and utilisation. People are viewed as individual “resources” and an important goal is to maximise people’s utilisation (Before you say this is not true, think about how important this metric is at your company and that people tend to optimise what is being measured).
 
I know that especially for vendors who often charge by the hour or have to keep cost down in a fixed price and scope scenario, utilisation is hugely important. That’s fair enough. However, making utilisation the main driving factor, will backfire and ultimately lower utilisation. 
 

Why is this a problem?

 
By foregoing the team approach, aiming to maximise utilisation and piecing together projects through dynamically allocating and re-allocating people we:

Read More

When the coach needs to go

“When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.”
— Nanny McPhee (via Lyssa Adkins

I am an Agile coach and the goal of my job is to put myself out of a job. 

My mission is to teach people Agile and to make sure they understand and correctly apply Agile values, principles, frameworks and techniques. This is quite a big deal as Agile often forces us to change the way we work on a daily basis; how we organise our work, how we collaborate, which tasks we perform and how we communicate with each other and the rest of the organisation.

Visual Workspaces: Kanban for one

One of the things that immediately caught on when we started our journey towards being Agile at Snapper was the use of visual workspaces. The team loved the sense of achievement of moving a task from “In Progress” to “Done” and found the board helped them stay focused and co-ordinated. Everyone from team member to operations to management appreciated the level of visibility and transparency. Even my partner’s 11-year old daughter thought my work place was the coolest ever as we had covered the walls in colourful sticky notes and Simpsons characters.

Read More

A 5-why root cause analysis retrospective

The idea

For quite a while I have been waiting for an opportunity to try a 5-why root cause analysis in a sprint retrospective. 

The 5-why analysis has its origins within Toyota and lean manufacturing and is used to find the root cause of a problem through identifying a symptom and then repeating the question “Why?” five times. General wisdom and experience state that the nature of a problem and its solution usually become clear after 5 iterations of asking “Why?”.

Here’s an example from wikipedia: 

Problem: My car won’t start.

  • Why? – The battery is dead.
  • Why? – The alternator is not functioning.
  • Why? – The alternator belt has broken.
  • Why? – The alternator belt was well beyond its useful service life and has never been replaced.
  • Why? – I have not been maintaining my car according to the recommended service schedule.

Solution: I will start maintaining my car according to the recommended service schedule.

The plan

I have found 5-why root cause analysis very useful in the past but had never tried it with a group of people or a software development team. 

I “conspired” with our very talented Scrum Master and the plan was to share data from previous sprints, analyse the data as a team and see if we could identify a problem. If so, we would suggest a 5-why analysis to see whether it would point us towards a root cause and a solution.

The execution

1) We started by presenting velocity data:

The chart shows our planned (blue) and achieved (red) velocity over the last 10 sprints.