Showing posts from 2010

An idea for a release Retro

An idea for a release Retro
Simon Bristow, my fellow engineering manager, and I sat down yesterday to brainstorm how to run a cross-organisational retro for a major release. This release was 8 development sprints and 2 Regression sprints long, a total of 20 weeks.

Here is what we dreamt up, I'll follow up with a post on how it all went:


Representatives from the various areas of the organization (no more than say 25 in total) – Suggestions of key people welcomed, but at a minimum:

Prod Ops, at least one member of each Sprint team, COPS (Client operations), Helpdesk, Triage, Marketing, UX


Rather than asking the groups to come up with Themes, we propose that S, H and I look through related Retro notes, information on the Sprint notes (from our Wiki) and canvass you other people in the organisation for Themes to pre-populate on the day. We’ll discuss and get say 8-10 themes for the day and place them around the room on butchers paper prior to folk coming in. These themes should b…

The problem with ‘Commitment’ and using velocity as a measure of success (pt1)

Using an agile storyboard as a scale of certainty

As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate.

Scene setting
We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts.

Our story wall (in ugly table form)
The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are o…

A kanban experiment with a feature development team

The what and the whyThe team I am Scrum Master on at Aconex, Extensions,  has been moving further away from Scrum 101, and towards a version of Kanban over the last few sprints. We have also inherited a new Product Owner/BA and this led me to decide to attempt to document our process.I say attempt, because the longer it takes me to document, the less like the process the document becomes, not because I am rubbish at documenting, but because our process evolves constantly (as it should)But, I’ll give it a go anyway, and in the process, there should at least be some truths in what I record, as well as an insight to someone new to the Agile process/experience.
What is “Extensions”Extensions is a agile development team within Aconex that deals primarily with the add on modules to the main Aconex application.  The team consists of Product Owner, Java engineers, UI engineers as well as QA engineers.
Over the last few sprints, the Extensions team have noticed a lot more issues from Triage ente…

A presentation on Kanban

Following on from my original post about Kanban I went on to 'horror of horrors' put together a slideshow on the topic for my new workplace. This was presented to a new team as an introduction. The team than went on and started a Kanban process to manage their work. They are still using a derivation of this process today, 8 months later, to mixed success.

Here is the slideshow on Slideshare, I havent looked at this since I placed it up there in February, but once again I'll use the 'historical context' disclaimer here:

My first ever post about Kanban (January 2010)

This post originally appeared on the Kanbandev group on Yahoo groups here:
I thought in the spirit of aggregation I would cut n paste it here to this collection of posts. Big thanks to Simon Harris for the first summary of what we did in this project.

Please note, I haven't changed anything in this post to preserve its historical accuracy. Maybe I'll review it someday and write how I feel/what I've learnt since about mistakes and other things I've learnt since, perhaps not.

I have since moved on from Lonely Planet, and we have run a number of Kanban (esque) projects here at my new place of employ (Aconex). I'll write those up soon and get them up here.

Hi all,
Long time reader / First time poster
Just thought I'd share with you our implementation of Kanban work process at Lonely Planet in one of the teams we have here;

Here's how I recently "summarised" our development process as it has evolved…

A retro recipe

I call this retro the "Post It Note and Vote" retroTime needed: 1 hourFor: Small teams and best used as an end of iteration retro.Props:4 Sheets of butchers paper,lots of post-it notes,List of retro actions from the last retro if availableSharpies (or similar marker pens for writing on the post-it's so people can read them)White board markers (so you don't accidentally use the sharpies on the white board)Index cards (for writing actions on)A watch to time the retroPrint out of the "Prime Directive "Timing:Intro: 5 minutesSet up: 5 minutesPost it phase: 10 minutesDiscussion 10 minutes (includes grouping)Voting: 5 minutesFinal discussion: 30 minutes - includes agreed actionsWrap up: 5 minutesIntroThank everyone for attending the retro and read out the Prime Directive, making sure everyone hears and understands the principles.Review any retro actions from last sprint and briefly discuss whether they were carried out, and to what result. This is not the time to…

A rant on estimation

This is a transcript of a team discussion we had around 'estimation', why we do it, what its for etc. The format for estimation is 'Relative Effort' using a fibonacci scale (1,2,3,5,8 etc). We had a team meeting to go over our estimation after we had 2 sprints with wildly different points delivered.

Transcript and outcomes we summarised by me, below (in a team Skype session)

Yes, the decision yesterday was to continue estimating, we just use certain estimates as triggers for further action, i.e. 5/8's are indicators that the story needs to either be preceeded by a spike, [Ed's note - this is a team decision, we have agreed within the team to try to standardise card sizes as much as possilbe, and our team standard was a '3'] or broken down if possible, we will try to get stories to be round about the same size wherever possible

No 2's as per current (team chose to drop 2's as they spent too long quibbling about whether somehting was a 2 or a 3, and …

Hello World

I was about to start recording some observations on Agile in a word document to transpose later into a company blog, when I realised I might just be better off doing it here. So this 'Hello World' post is really to get me over the dreaded first post phase.