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

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!

Car stopped in breakdown lane

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!

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:

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!

• 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…

Copyright Simon Evans - Selected Works

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!

Neat, don’t you think? Comments welcome!

Swimming Lesson used by permission from anna_greece

Swimming is not really something extraordinary difficult – you can explain the basic stroke to anyone in about one minute. And yet, we spend hours and days learning how to swim (usually as kids), because it’s seen as having value (eg. staying alive when you find yourself in the water). Once you’ve learnt the basics, there’s no need for refresher courses (or certifications…) because your body remembers how to deal with the wet stuff: the skill stays with you and can be “activated” whenever you need to.

What takes time in the beginning is to unlearn some “best practices” (posture, walking, breathing) that work well in your daily life but turn out to be unhelpful (or even disastrous) when immerged.

Scrum is similar to swimming: easy to explain, but it needs some practice to “stick”. You need to take the time to unlearn some “Project Management Best Practices” you cherish, in order to get the full benefit and to really understand (see below) why Scrum works and how managing complex projects is different. Once you “get it”, you will remember for a lifetime, trust me!

Note to self: next time I pretend I understand something, check if it passes this test:

“If you know something, then you understand it. You respect it.
If you do not understand something, you do not know it.
You believe that you are better than it. You are above it.
You look down your nose upon it. ”

from http://tinyurl.com/cangs8)

So who’s right? Well, IMHO none of the above, really.
Let me explain. If your expectation of “going Agile” is that it will just be a matter of putting some new policies in place, training a few people and adjusting the process schema (oh, and maybe the org chart, while we’re at it), then you’re mistaken. Maybe not as much as Dilbert’s boss, but mistaken nevertheless, sorry.

Dilbert's boss' biased view of Agile

The good news: Going Agile is much more gradual and spread out in time.
The bad news: it’s going to hurt for a much longer period, as you continuously improve and go much further than you thought you could.

Going Agile is a journey on which you will find blood, sweat and tears – and it’s not going to be perfect after iteration 2! Prepare for a profound change in your enterprise culture, a learning experience like learning to swim, or to ride a bike, where you need to let go some of your preconceptions in order to get the full benefit.

So yes, it might be a good moment to start. And keep improving… it’s worth it!

Well, I just made this one up this morning – I think the shortest description would be “a somewhat contagious gene of Scrum-related thought”.
(If you want more info, check here: Wikipedia on Meme. Oh, and the page on Scrum is here.)

My intent is to give you a little something to think (& hopefully act) about during your day, making your work life better in some way.

I’m an Agile Coach and Trainer : I teach teams to perform better in a rapidly changing environment. More on myself and my job in a later post, promised.

So here’s your meme for today:

Processes are just the visible (or, if you prefer, auditable) part of everything people invest in your product. What would happen if you could influence more than the surface ?

Think values like courage, honesty, respect, simplicity and frequent feedback (courtesy of eXtreme Programming, mind you). Do you believe investing in these values could profoundly change your workplace ?

I’m looking forward to your feedback – be courageous, honest, and respectful, of course !