fe

This user hasn't shared any biographical information

When opportunity knocks…


I’ve talked about cards that are never going to get prioritised and should end up in the Dead Card Cemetery.  But what about small cards that are important enough to keep in the backlog, but that keep getting deprioritised behind other things in the backlog?  I’m talking about the really tiny ones, often bugs, no more than half an hour’s worth of work. Maybe you could try an opportunity bucket.

 

A purist might say that if a card is important enough to be worked on then it will be prioritised into the backlog.  But actually, there are always things that have too little value on their own to be prioritised.  The team I currently work with created a ‘bucket’ of these at the bottom of their board.  Cards get plucked from the bucket if it’s late in the day and not worth picking up a bigger card from the main backlog, or if they’re doing some work in that part of the code anyway and can fix something from the opportunity bucket while they’re in there.  It’s proved to be a great way to knock off tiny cards that would otherwise have languished in the backlog.

Spotted: LPOS development team

, , ,

Leave a comment

Who’s on fire?


Teams  get their best work done when they can concentrate and focus on the task at hand.  Switching back and forth between different tasks interrupts your train of thought and it can take a long while to get back on that train. Tom DeMarco recognised this more than a decade ago when he wrote “Peopleware“.

But of course sometimes interruptions are unavoidable. When we say we value conversations as the highest-bandwidth channel of communication teams can use, we are inviting interruption. Or someone from another team has a technical question. Or sometimes a production issue comes up that needs immediate attention, or a developer is the only person who can help unblock someone else’s work.

So how can we minimise these interruptions?  The team chose a ‘fireman’. Someone whose job it is to extinguish any of these fires as soon as they happen.  Team members take turns to be the fireman, and the fireman for the day is clearly shown on the team board so that everyone knows who they can tap on the shoulder to help them.  As well as keeping the rest of the team focused on their work, it means the people with the questions don’t feel guilty about interrupting someone.

Spotted: LPOS development team

, , , ,

Leave a comment

A card spike


Katie's unicorn spike.

Katie says: “There’s something really satisfying about spiking the completed cards at the end of each iteration”.

Here’s another take on what to do with the cards once the iteration is complete – stick them on a custom-made giant spike and top it off with a unicorn!

It’s important for a team to recognise the progress that they’ve made over a series of iterations.  Watching the cards rise higher and higher up the spike is satisfying and a visual indicator of how much work the team has done.

Spotted: lonelyplanet.com website development team

, , , ,

Leave a comment

Get on the Release Bus – you know you want to


The LPOS team's release bus starts to fill.

Team says: “That bus is getting full. Looks like it might be an Indian bus“.

Ok. You have achieved continuous delivery. You can now release your features whenever you like. But how do you know when it’s time for a release? You want to keep the value flowing out to your customers. How do you track which cards are going in the release?

One way is to use a release bus.

All the stories that will go out with the release are moved onto the bus as they are signed off. There are limited seats on the bus – when the seats are all full then it’s time for a release. There’s no reason to wait until all the seats are full though, a release should still happen whenever it’s required. On the other hand, a release bus that has run out of seats is a sure sign that there are getting to be too many stories in the release and that it might be a good idea to release in order to minimise complexity and risk.

Spotted: LPOS Team

, , ,

Leave a comment

If it’s a Release Bus, where does it stop?


The LP website team's release bus map.

Team Says: “We were sick of the confusion about which apps to deploy each release.  Our release manager knew the site backwards but as soon as he wasn’t around it all fell apart”.

The website is a large, complicated beast with many apps to be deployed behind the scenes to provide a single experience for the user.  A few times we forgot to release an app with the result that we broke something on the site. Also we needed everyone on the team to be aware of which parts of the system were going to change with each release.

The fix?  Since we already had a release bus, we made a bus route map.  Every app which runs the site is listed there, and a sticker gets placed over each app that the ‘bus’ needs to stop at during the release.  It’s a great visual that provides a checklist to use during the release, and also helps non-technical types understand how complex our website is.

Spotted: lonelyplanet.com website development team

, ,

Leave a comment

The Dead Card Cemetery – where dead cards go to die


The LP Content Desk's Dead Card Cemetery.

Fe says: “That card might get zombied back into the backlog”.

Some cards just never seem to move up the backlog. They are always deprioritised to make way for something else. After a while it becomes apparent that they are never going to get prioritised, that there will always be something more important. But it can be hard to remove a story from the backlog – someone usually still holds that story close to their heart. It’s a good way of managing team members attachment to particular stories. It almost never happens – but if needed, a card can be brought back into play from the cemetery. It’s also a useful visual to show how many things that we think are really important at the time, actually become so unimportant that they never get done.

Spotted: Lonely Planet Content Desk

, , , , ,

Leave a comment

%d bloggers like this: