Motivated Individuals – Great Teams


Getting up at 4:30am in the morning on your holiday may seem like a bit of a daft thing to be doing; in the end holidays are meant to be relaxing and a time to unwind.  Some people enjoy lazing on a beach.  Unfortunately, that’s not my idea of a holiday – my ideal holiday is cramming as much “stuff” in to the shortest possible time.  “Stuff” is defined as ski touring (where I’ve been), ice climbing, rock climbing, skiing.

So what’s the reason for getting up so early and how does this relate to anything at all!!!

Well the reason for getting up early (especially in huts) – is because the hut guardians generally want you on the hill early so you can be back early.  The reasons are probably three fold:

  • In winter the afternoons bring a greater chance of avalanches.
  • In summer the afternoon brings the possibility of thunderstorms.
  • It also gives you the most amount of time to achieve your goal – i.e. go up a hill/mountain!

I’m not one for getting up early, however, on holiday it seems even easier to get up than it does on a work day.  It is quite simple go to bed a lot earlier than normal so that you can ensure that you are fresh in the morning – there is also not much to do in a hut after dinner!

When you get up in the morning at “silly o’clock”, there is an enviable buzz around the hut – people are psyched for the day ahead.  This energy is really amazing, you can feel it flowing through the building. 

This is the perfect example of building teams around motivated individuals (read principle 5), if a software team had the same buzz as my fellow mountaineers/hut goers then it would probably build kick-ass software.  Quite assumptive I know!

My mind now ponders at how to get this motivation flowing through everyone in a team; is getting people up at 4:30am in the morning reasonable!!!

Having a shared goal would be a good start, and finding out what motivates each individual in the team…

Kanban – Retrospective – Categories for Improvement

We keep having weekly retrospectives about the Kanban board.

Last week’s retrospective probably went a tad off target, or maybe it produced ideas which don’t improve the process of our team, rather than general ideas about the board. Note: no idea is wrong or right during these retrospectives – it’s just the focus might have been lost on the purpose of Kanban.

Last week we looked at things that “went well”, things that “went wrong” and things that we wanted to “improve”. We then voted on which improvement ideas we wanted to implement. You can see what we implemented in my last blog post.
This week we invited Andy (our very own Lean/Agile samurai) to the retrospective, partly to see how we should run a retrospective, and partly to get some focus back on Kanban.

The following was the rough structure of the retrospective. The first was a discussion between pairs about “Why we wanted to do Kanban?” and also “What we wanted to change?” These where put on post it’s and stuck to the wall randomly.


We silently organised as a team the post-it’s into groups. I found it especially interesting the commonality between the post-it’s that each of the pairs came up with – probably not very interesting since we all share the same goals & grievances!

The team then came up with the following list of categories for each of the groups of the post-its (in no particular order – I just wrote them down this way!!):

  • Teamwork
  • Customer Satisfaction
  • Problem Identification
  • Prioritisation
  • Predictability
  • Speed
  • Transparency


The team scored each of these with either an “x” “–“ or “tick” depending on how we felt things were currently. We scored the majority with a “-“on some categorices and “x”’s on other categories – as you would expect. None we scored with a “tick” – we had some small ticks though!!!


We then paired again (with different pairs) and asked each other how we could improve the process targeting the above categories.

We fed this all back in to a whiteboard – and came up with a list of things to improve. We each had 3 votes again and got to vote on an idea we’d like to implement. The ideas we are going to implement are as follows:
  1. Measure cycle time overall and between different work types & stages.
  2. Limit number of items coming in to the start of the workflow & each stage.
  3. Cut things down into smaller chunks of highest value.
We are going to try to implement these this coming week, to see if it improves parts of the process. The impact might not be immediate but Rome wasn’t built in a day (I’ve used that quote too often recently!).

An important thing for me is that we start to get some stats about the work we do in our “development system” – i.e. how long it takes for us to complete different work – what is the cycle time for a specific type of work?