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 
Filed under: Uncategorized | 1 Comment
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!
Filed under: Uncategorized | Leave a Comment
Tags: indicators, product owner, productivity, team, velocity
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
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!
Filed under: Uncategorized | Leave a Comment
The Retrospective Habit
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:
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!
Filed under: Uncategorized | Leave a Comment
Tags: continuous learning, feedback, improvement, retrospective
A Foundational Team Effort
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…
Filed under: Uncategorized | Leave a Comment
Product Owner ADD
- 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
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!
Filed under: Uncategorized | Leave a Comment
Tags: everything, priorities, product owner
This is one of the results I got by feeding Christophe Louvion’s “Scrum in 100 words” to Wordle:
Neat, don’t you think? Comments welcome!
Filed under: Uncategorized | Leave a Comment
Tags: 100words, illustration
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)
Filed under: Uncategorized | Leave a Comment
It’s crisis-talk time, folks. Some of my customers feel that this gloomy period of record losses, is the best moment to change their internal processes, because there is a big need for doing more with less (as Dilbert’s pointy-haired boss seems to think, see below). Some others feel that they can’t afford to make the plunge right now, as they need to “stick with their knitting”.
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!
Filed under: Uncategorized | Leave a Comment
Welcome to the Daily Screme!
Just what is a Screme ?
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 
!
Filed under: Uncategorized | Leave a Comment
Tags: courage, feedback, honesty, process, respect, simplicity, values, XP
Search
-
Blogroll
Recent Entries
- Urban Traffic or How To Explain Agile To Your Manager (or Grandma)
- Team Velocity is *NOT* a Performance Indicator
- Lean flow practice: breakdown lane
- The Retrospective Habit
- A Foundational Team Effort
- Product Owner ADD
- A picture is worth… at least 100 words
- “Is Scrum really that simple ?!?”
- When is the best moment for “Going Agile” ?
- Welcome to the Daily Screme!
Categories
- Uncategorized (10)
