Coming back from a customer site and trying to find a compelling visual illustration of Agility (helpful in order to explain what I do to managers, children, and my mother-in-law), I got stuck in a traffic jam… one of these “Eureka!” moments, as I jotted some thoughts down on a makeshift notepad on the passenger seat.
Out of this came this presentation I’ve held at two conferences (XP Day France in Paris, Agile-from Hype to Practice in Zurich) which sums up some of my thoughts about this analogy.

I’ve been asked to publish my presentation I’ve recently given on Urban Traffic, so here it goes (in German and French, pick your favorite):

UrbanTraffic_German
TraficUrbain_XPdayParis09

Comments welcome in all languages🙂


productivity
Scrum uses a concept called “Team Velocity” to measure how much work the team accomplished in the past iteration. Velocity is usually measured in Story Points which themselves indicate the complexity of a task (more on Story Points in a later post). Velocity is used in Sprint Planning meetings as a “Yesterday’s Weather” indicator of how much the team can reasonably achieve in the upcoming Sprint.

So why do I claim is it not a Performance Indicator?

Performance is measured as throughput by time, not amount of work by time. Simply put, if you start mixing up performance and velocity and set performance goals, your team will game the estimated Story Points to achieve your goal – but the throughput of the team in a given iteration won’t go up.

My advice is to measure performance of a Scrum Team as Business Value points per release (or if you have to, per iteration). This forces the Product Owner to quantify Business Value (relative sizes are OK, but they need to be numerical) and has the additional advantages of ensuring the team works on high-value stories and of highlighting when ROI drops off (the team is still working hard, but the stories have less and less value), which is the moment to put the project on Hold and give the team higher priority work.

If you think that this definition of performance places too much responsibility on the Product Owner (“it’s not the team’s fault if there are no high value stories in the Product Backlog!”), consider this: who pays for the team’s work? how productive is a “very busy” team working on low value stories really?

Your comments are welcome, especially if you disagree!


As I’m working on a presentation called “Urban Traffic: a Parable for Explaining Agile” (to be presented at XP Day 09 in Paris), I’m reflecting a lot behind the wheel these days.

Car stopped in breakdown lane

Car stopped in breakdown lane

What is a breakdown lane for ? Building an extra lane on the side of the freeway is a big investment, so there must be a reason for it – and cars don’t break down that often, do they ? Why not avoid with the extra expense and build a smaller freeway, or just pack one more lane into the available space ?

Well, several reasons:

  • Flow: on a freeway a breakdown lane is essential for stabilizing the normal flow of traffic.
  • Safety: a breakdown lane improves safety for the driver of the broken down vehicle and for rescue services.

You can see the concept even more clearly with breakdown bays in tunnels, where the cost is huge! Apparently, stabilizing the overall flow capacity of the system is worth such an investment: you don’t want to lose a two-digit percentage of your flow capacity because of an out-of-gas car.

Back to Lean Management – here are some questions for your company:

  • Where’s the breakdown lane in your enterprise processes? Do you have an ongoing lane or breakdown bays at specific milestones?
  • Are stalled (non- or slowly moving) projects blocking other parts of the overall flow? How can you tell?
  • Do stalled projects know they should pull over? How do they alert emergency services?
  • How do you go about rescuing those vehicles and their drivers? How does this impact the flow of operations?

In Agile teams, blocked items get signalled very quickly (parked on the breakdown lane) and the flow of work is minimally interrupted, as team members move to getting another piece of work done (normal traffic) while the ScrumMaster picks up the impediment. This transparency and honesty sometimes puzzles managers who are more used to projects moving very slowly on the normal lanes. They might even get upset about the number of broken down vehicles (depending on the metrics they’re using, this is where ScrumMasters get yelled at). But once management understands Lean concepts, the advantage is clear and the flow picks up again – as it does when pulling away from a traffic jam!

PS: Traffic authorities in several European countries (where many freeways have only 2 or 3 lanes) have started allowing using the breakdown lane for normal traffic in case of saturation traffic jams, thereby temporarily boosting the local system capacity by 33-50%. But as soon as allow generalized driving on the breakdown lane, you’re back to significant potential blockage of your system – by just one broken down vehicle!


Retrospectives are one of the standard agile meetings, and I usually advise customers who are starting off on the journey towards Agile to start here. But before you kick off a fully-fledged retrospective of your whole division’s last quarter, it can help to just do one for yourself. Here’s how:

In a quiet moment (eg. your commute on the way home, or a toilet break), ask yourself the 4 After Action Review (AAR) questions:
1. What was supposed to happen ?
2. What actually happened ?
3. What was the difference between the two ? Why ?
4. What could I do differently next time ?

If you look back onto an average working day, this should take you no more than five minutes. To make sure my insight-of-the-moment doesn’t get lost in daily busyness, I like to keep a log (a small notebook) of my answers, especially to questions 3 and 4. And that’s all there is to it!

Here’s a sum-up from a non-SW-developement site:
AAR questions according to ODI

PS: If your retrospective involves a team, try and get an experienced facilitator. If you’d like to know more and understand French, my good friend Jacques Couvreur and myself will be presenting a card game that can help you make your next team retrospective a fun & insightful moment – check out Agile-Alchemist.com for more info or attend our presentation at XP Day Paris on May 26!


It hit me while watching this part of The Daily Show (yes, I admit I’m a fan): even writing a constitution can benefit from Agile/Lean principles! Richard Beeman didn’t get to explain all the details of how the team of 55 (how’s that for team size!) men writing the American Constitution proceeded, but I got this out of what he said:

  • they had a shared vision of what they wanted to achieve
  • they left their egos at the door
  • they managed to focus on just this team work for a long time (almost four months)
  • they overcame differences and pains by hanging out together
  • they practiced respect by not badmouthing each other publicly before the result was achieved
  • they knew how to tell whether when they were done, even if all was not perfect

So, here’s your litmus test: how many of the above are a reality in your team?
Comments welcome…


– Okay, okay, so everything is priority 1 -except the urgent stuff, which is priority 0, of course…
– Just finish everything on the list, we need all those features

Copyright Simon Evans - Selected Works

Copyright Simon Evans - Selected Works

These everything statements are typical symptoms of what I call “Product Owner ADD (PO-ADD)” (with all due respect to people who *really* suffer of Attention Deficit Disorder).
You see, this disease highly increases risk on a Scrum project as the Team now needs to figure out how to set up its priorities. And as separation of concerns is one of the main tenets of why Scrum works (in a nutshell: PO determines WHAT & WHEN, Team determines HOW), PO-ADD negates much of the value a team can get out of being agile.

When faced with a PO infected by ADD, my advice to the ScrumMaster is to go back to some agile values like courage and embracing change and encourage the PO to focus very explicitly onto the upcoming Sprint, making sure he doesn’t feel overwhelmed:
– Just for the next Sprint, what features do you want the team to invest time into?

Many POs have an urge to prioritize all the features on the Product Backlog, which is almost completely worthless (it can help in situations where the PO needs to inquire for more info ahead of the Sprint). Encourage the PO to stop prioritizing as soon as he’s covered the usual sprint capacity + some additional features.

This approach usually stabilizes the PO’s time invested in the backlog – it becomes less of a “!*&% – I still need to clean up the backlog for tomorrow’s Sprint Planning” and more of an ongoing backlog grooming (sustainable pace, anyone?). This ensures that the PO is focused on maximising the ROI produced my the team, at all times.

Try it and post your comments!


This is one of the results I got by feeding Christophe Louvion’s “Scrum in 100 words” to Wordle:
Wordle: Scrum in 100 Words

Neat, don’t you think? Comments welcome!




Follow

Get every new post delivered to your Inbox.