nthorpe

Raised, and subsequently abandoned, by wolves, I went on to an illustrious career, where I selected the wallpaper for the little known small hadron collider, located outside Warambool.

Post-it Not


No, that strapline is not missing an “e”.

We Agilistas navigate through our days using tons of post-it notes.  You can always tell where the agile folks have been: they leave a trail of the things just like Hansel & Gretel.  When you’re facilitating, or even thinking, they’re just too handy. They allow us to group ideas, to reposition them in relation to each other. We can use their colour and arrangement to help us see patterns in ideas. We can have everyone in the room contribute their own ideas, and then group and edit them as a team. What could be better?

Well…in some cases, this stuff.   This turns any piece of paper into a post-it.  You just smear a line of it onto a card or bit of paper and you can re-stick it and reposition it to your lil’ agile heart’s content. It’s called a re-stickable glue stick.

So what? Well, it’s a lot neater and less splodgy than blu-tac, so it’s good for avatars and little badges which go onto the surface of index cards. Blu-tac often causes these smaller pieces of paper to warp.  But it also lets you effectively create your own post-its. You can create post-its of different shapes, where the shapes are meaningful for your team. They could have templates on them for key terms, or story numbers, or, or… anything!

You could get it here, for example.

, ,

Leave a comment

Shower Curtain Aids Transparency


No, it’s not for planning your iteration in the shower. Sorry.

Sometimes, you just can’t get to the walls. Maybe the building police won’t let you put anything on the walls. Maybe there just isn’t the space, or your team isn’t located adjacent to a wall.  Portable whiteboards, which are the usual guerilla weapon of choice in this situation, can block lines of sight and available light. And sometimes they get the building police excited, too.

One team decided to take matters into their own hands and create their own Shower Scene. The cards fit into little pockets designed into the shower curtain. Note the little suckers at the top which allow you to stick it up on any smooth surface.

Just one supplier for this product (shop around, people, and let us know where the bargains are!).

photo (3)

Spotted: Bankwest, Perth

, , , , ,

Leave a comment

Whiteboard Paint


Turn any wall into a whiteboard! This stuff is the bomb.

I haven’t used this brand before, but there are a few variants on the market. Once you get over your fear of writing directly on the wall, being able to write anywhere is very liberating.

At Lonely Planet, there was a team war-room where all the walls were painted with whiteboard paint. The kind we had wrote well, and erased well too. For a while, we had an entire business case sketched up on the wall and stakeholders could come and talk through the whole thing. We could change the slides right there on the wall, on the fly. A great place for thinking. Look out though, your wall is going to look like this in no time!

Here is another brand.

Special props to Nigel Dalton and Gus Balbontin on this one.

, , ,

Leave a comment

Are We Gonna Make it?


Here’s a tool for teams doing commitment – based planning.

On this chart there is  confidence slider per day of the iteration. Team members individually mark their confidence that the team’s commitment will be reached on the chart after standup, with a line.  On the left of the scale is “Very scared that we will not achieve everything we have committed to this iteration”. On the other: “Very confident that we will deliver everything that we have committed to by the end of this iteration.”

This one makes an excellent conversation starter. “Why do you feel that we will / wont make the goal?” The answers may well reveal risks which may have remained hidden.   Different teams will display different patterns. For some, they become more confident as the iteration progresses. For others, you will see the cloud of marks moving back to the left.

Below you can see the clusters of lines, and you can see outliers: skeptics, or optimists. Graeme, the Iteration Manager, says: “For stakeholders, or other interested people, they can see how the team feels about a commitment.” That’s hard to argue with. “I like it better than a burndown chart.”

It certainly looks like a better form of reporting than the standard RAG Sheet.

Look below: this iteration, the team have divided on the fourth day in, with at least three team members strongly convinced the goal is out of reach. What happened on Wednesday? A great conversation starter.

Spotted: Telstra  Contact Solutions CCRI team, Graeme Robb.

, ,

Leave a comment

Making Sense of Tech Debt, Fast


Fabio Pereira uses this method to help teams quickly prioritise tech debt. In this example, the team held a Tech Debt retro where they brainstormed all the technical debt they thought they had accrued since the start of the project.

“Technical Debt” is postponed work created when a team takes some technical shortcuts in order to get a solution out fast. These shortcuts create a “debt which must be paid back later. It’s often hard to know where to start on addressing this “debt”.

The team then classified the debt on two axes this way:

“The relative effort that the team would have to spend in order to pay this debt.“

Pain is the direct impact on productivity that this debt causes. (interest)”

This made it easy for them to decide what to tackle first. “Lets start on the high value work which takes the least effort”!

Fabio says: “One interesting thing that came out of our retro was that the High Return section was almost empty. We came to the conclusion that this was a good sign, it means that we had already fixed most of the LowEffort/HighPain debt during the normal development. Which is exactly how this type of debt should be paid.”

 

, , , ,

1 Comment

Release Radar helps you see through the fog


A common or garden Agile board is good for a view of the iteration you’re in, and perhaps a little further out. But what about when you need to see even further? Agile teams often face the problem of “boiling priorities”. Priority changing on big  pieces of work daily. You start to work on them, and then you hear they have been de-prioritised. It’s hard to know what you should be working on.  The team can churn through a lot of brain cycles thinking about pieces of work which may or may not eventuate. This can be stressful.

Sometimes we need to be vaguely aware of pieces of work which are “out there” in the future, whilst still keeping our focus squarely on what we know is coming next. Different roles in the team, too, have different time horizons they need to care about. For Project Managers, or Business Analysts who need to organise and run inception activity, it’s good practice to keep an eye on what’s coming down the pipe. For developers, it’s often: “Meh. Just tell me what I need to do next.”


Daniel Aragao
showed us a great way to deal with frothing priorities – the release radar.

Here he has trained his radar across the portfolio:

– each concentric circle represents time (12,9,6,3,1 and .5 month).  Items far out on the radar are distant in time, items nearer the centre are closer in time

– each slice is a project, identified by a post-it on the outer rim

– resources working on the project are also on the outer rim – these will be avatars in the future

– each post-it represents a task, module, something that is big enough to be picked up by the radar

– post-its will be colour-coded to show the size of each task.  T-Shirt sizes (S-green,M-yellow,L-orange,XL-red)

– IT, Ops and Business get together every 2 weeks to update the Radar and discuss associated risks

On our team, we took the idea and adapted it to our needs.  Our radar simply tracks pieces of work as they orbit our world, and then come in to land.

The purpose was to be able to provide steady priorities to the team (they only need to look at the innermost ring), to help our BA structure her work with stakeholders on preparing epics, and to get a view of the whole pipeline if we needed it. We keep it on the back of the iteration board, and a subset of the team meet once a fortnight to update it. It tells us what we need to actively think about, and what we can ignore.

The quadrants relate to stakeholders.

Spotted: Daniel Aragao of Thoughtworks shared this idea.

, , , , , , , ,

1 Comment

Highlighting Process Glitches


“We wanted a way to notice recurring patterns in glitches.”

This team gets through an enormous amount of work which requires many hand-offs with other departments.  When there’s a glitch in a part of the process, the team member adds a little red sticker to a card, often with an accompanying note about why there was a glitch.  If a story accumulates a few of these, we can see it’s in trouble.  Also, the little stickers are an excellent reminder for retro, where we have a chance to talk about how to address any larger issues that might be driving them, or even use “5 whys” to delve into the root cause of glitches.

Spotted: Lonely Planet

, , , , ,

Leave a comment

Revenue on a Card


Sometimes it feels like the agile community knows the cost of everything, and the value of nothing.  We have clever ways to measure velocity and to estimate the size (and therefore cost) of pieces of work, and we like to obsess over these. But when do we ever quantify the value which will be delivered by a piece of work? Relative value is taken into account when a product owner prioritises higher value stories in the backlog, and some methodologies do take a shot at quantifying business value nowadays, but I don’t see much evidence of teams trying to quantify the value of a piece of work either before, or after it is delivered.

Deming says “Plan, Do, Check, Act“. But most of the time it just feels like “Plan, Do, Plan Do, Plan Do”.

I salute this team which puts the revenue at stake right on the card for everyone to see. If this is job is blocked for a day – is it a big deal, or not? Look at the revenue at stake. It’s a big deal.

Spotted: anonymous

, , , ,

Leave a comment

Card Equaliser


Team says: “A cool way to visualise the output of each iteration.”

What to do with cards after an iteration is finished?
Tear them up? Spike them? Leave them on the bus?
How about turning them into a ‘card equaliser’?

The idea behind this hack is to give a visual representation of the cards signed off in each sprint.
The card colours represent bugs, features, BAU support and tech stories.  By arranging them on a spare wall according to colour groupings it’s easy to see how many cards and of what type have been signed off each sprint.  For example, feature cards, defects, and tech cards. And you can see how this changes over time.

It’s also immediately apparent whether the main activity has been skewed towards one area.  It takes it’s name from it’s similarity to the display of a graphic equaliser.

Like this:

Just by walking past, it’s easy to learn a lot about this team’s work:

So.. what this board is telling me is …

… this team pumped out a lot of features in a short time then faced down some serious technical debt and some outstanding defects.

Here’s another card equaliser, this time from the Lonely Planet web site team.

Spotted: lonelyplanet.com website and mobile development teams.

 

Here’s another variant, from a different source. Might be useful if you don’t have a lot of space:

, , , ,

1 Comment

Release Readiness Traffic Lights


20110614-071337.jpg

Nick says: “The first time we did this, it helped us to get our release success rate up. It was a long road, but this was one thing which helped.”

We were working on a sprawling web site made up of 22 separate applications which may or may not need to change for a particular release. The release would bring work by 2 to 4 teams to production. As we moved to biweekly releases, we needed a way to see exactly how our preparations for release were going. Is regression testing complete? Did we pass load testing?

So we decided on what our criteria were for a release to be good-to-go, and made each criterion a traffic light which could be red or green. This included a “stop the line” light which developers could turn to red at any time if they felt the release was too risky.

Each day, from three days out til release, we would stand around the release readiness traffic lights after morning standups were over and discuss the status of each light (“is that really green?”), and agree on actions to get to green.

Spotted: lonelyplanet.com website development team

, , , ,

Leave a comment

%d bloggers like this: