Showing posts from 2011

Skillus interruptus, being interrupted and loving it...a key skill for agile people

At work today, we had a series of case studies delivered on UX and agile. The premise of the morning was to discover whether UX people could work within the dynamic agile team environment. Lots of good stuff in there, but one thing really stood out. Tref, one of our UX team and an Aconex stalwart offered this gem.

I'm going to paraphrase him here as I cant quite remember word for word:
"To really work well within a small team, one needs to be collaborative, to be collaborative, one needs to deal with and actually like constant interruptions." This is so true, in small collaborative teams, interruptions are a constant, as you share and seek advice from team mates.

Of course a key part of skillus interruptus was knowing when, and how to interrupt others. The ability to switch focus but stay calm is tricky, some people hate it and I've seen them crack under just this pressure. Retro notes are littered with "Constant Interruptions" in the "what didn't …

A simple visualisation technique to manage multiple releases in a sprint.

One of the teams I work in is a new product development team. Up until recently we have been working on a minimum viable product feature set. We work in 2 week sprints and at the end of each sprint we did a demo and deployment to a demo environment. We got very used to having this release bus style process and planned our sprints accordingly, what can we release in 2 weeks.

However, recently we went 'live' to a limited Beta release and the dynamic changed. We had our minimum feature set being used by customers, and they were giving us daily feedback. There were features we could get them in 2 days development but hadnt really visualised our information so that we could see the Tree's for the forest.

In an hours discussion with my accomplice Yoram, we came up with a colourful, yet simple way of visualising all the little featuresets and prioritising them. People do variations of this, hell they've probably already done what we do, but I kinda like itso I thought I'd …

Burn ups - a follow up

In a follow up to my previous post on burn up charts, I sent an email this is adapted from to members of the team. In it I expanded on the use of Burn up charts in tracking progress on multiple release projects. All names have been changed to protect the innocent.

First burn up chart for Project X Vers 1.0.
Interesting information we can glean from this very early chart;
- We can say, with what we know so far, the likely release dates is sometime between Sprint 7 and Sprint 16.
- To increase the accuracy of our forecast release date, we need to spend more time doing workshops to breakdown the epics. This will reduce the gap between “Known scope and “Known worst case”
- More workshops to determine scope means less time to do actual work. (Catch 22)
- This range is due to large number of Epics (proportionally) still to be broken down to stories (8)
- 9 stories delivered is based on Tablet stories so far completed in this sprint of which most were carry overs from last sprint

There are s…

The band of uncertainty – A burn up chart story.

The problem
With most agile projects, change is one of the few constants, its this paradox that makes traditional project management forecasting tools obsolete (if they ever actually worked in the first place). Gantt charts react poorly to change if it happens every day, chucking hissy fits and requiring far too much time to maintain. There is still a need however to be able to track project progress towards a goal, especially projects of many sprint lengths.I have started using Burn up charts as part of my end of sprint reports which are sent out to all the interested parties on a project including team members and other stakeholders.

Setting up the chart
There are some tools that have come into vogue for measuring agile project progress, of which the burn up chart is one of these. I first came into contact with burn up charts a few years ago. We had a very basic chart introduced towards the end of a large project by the amazing Angela Ferguson of Thoughtworks. This stuck with me and …

The challenge of running an agile project with an annual funding model

In my last role in my former life as an employee at Lonely Planet, I was Project Manager on one of the major projects running in Product/IT for that year. I understand that the funding process has changed a lot since then, and I like to think I and my colleagues helped contribute to that with our actions.

As part of our reporting responsibilities we were required to do a breakdown on project spend, feature completeness and time remaining. All standard stuff, with the aim of retaining tight governance on a fairly large project with a substantial budget.

There were however, a number of factors that made this a rather painful process.
1) The project had gotten its funding from a number of sources, both print and digital, as well as external clients. In memory, there were at least 6-8 buckets of money contributing to the overall project budget, and each of these expected something for their dollars. This was/is a fairly standard way to fund projects in organizations and wasn't …