Archive for the ‘Agile’ Category

Inspired by Bart De Waele’s last post a list of what I typically take with me every day.

– an USB headphone, that I can use to talk on Skype when I work with remote people.
– charger for my MacBook pro
– a physical book. I spend at least 1 hour every day on a train, when I usually read a lot. Although I prefer reading in my kindle, I always have a physical book with me as backup.
Jimmy  Cards, to use with teams or individuals.
– a device to do digital banking. (For when I need to make large payments I can’t do on my phone.) I always have a spare one with me.
– a clicker for presentations (Logitec)
– in ear plugs for listening to music on the train or my bike.
Deborah Hartmanns Fearless Journey cards (based on Linda Risings  Fear-less change book.
– My Macbook pro with gothic Snowwhite. (I have this picture to make sure I recognise my Macbook)
Jurgen Appelo’s delegation poker cards.
– A small pack of glass cleaners.
– two adapters so I can work on my laptop with a second screen.
– my kindle.
– my scarf. As a coach, trainer, presenter, my voice is my most precious instrument, you will hardly see me outside without my scarf. Yes even in the summer, I’m very sensitive to wind.
– My kisika (yellow jack), as I drive with my bicycle to the trainstation and I want to set an example for my kids, I will always wear this. (I just realised, left out my bike helmet because it was not in my rucksack. )
moving motivator cards (also from Jurgen Appelo)
– a small set of gongs. They take up very limited space and at least once a week I can use them when I did not expect it.
– post it’s and Stattys. There is not a meeting that I don’t use them. (I prefer Stattys over post it’s)
– a small solar charger for my phone. (I just realised my cable was actually in use when I took the picture)
– a marker.
– a small notebook
– something I use on plane or train to block light on my eye so I can sleep.
– my Iphone 5S (I agree with Bart, I never buy the first form factor of a new device)
– the phone is inside a small cover that also contains the cards I take with me.
– a wireless trackball (that I can use also todo presentations with)
a handshoe mouse: the last two device or some of the many mouses I use. Since I invested in that I no longer have trouble from a RSI that had started.
This are just the things I always take with me.

When I go abroad I also take:
– a powerstrip, so I can connect many devices in my hotel.
– a small bag full of international connectors
– a neck pillow for the airplane
– passport
– a digital photo camera (Canon)

What I don’t take might be as interesting:
– I hardly have cash with me.





I read everywhere...
The last years, I noticed that I explain dimensional planning more and more.
I learned about dimension planning from Koen van Exem, one of the early Belgium agilists.
It’s one of these early germs of (Belgium?) agility, that unfortunetly has been mostly forgotten.

Last night JB (Rainsberger), Alistair (Cockburn) and myself  had a small discussion about it, that made me realise that I still have a nice story that I had not shared on my blog yet.

Before I do that, let me explain the basics of Dimensional planning.
The idea of dimensional planning, is that we slice our stories in different implementation dimensions.
We do this because as JB says, a lot of  clients want a Lexus by the end of the week. We might not be able to do this, yet we might be able to offer them a toyota by tomorrow, most clients love this offer till we can deliver the Lexus. (Aka very fast ROI)

I prefer the dimensional planning theory like Koen explained it to me.

Imagine you have a client that wants a highway between Amsterdam and Heusden.
You are good at making highways, so you start building right away. After a few months you are ready and you proudly let your customer use the highway. She arrives at Heusden and she does not have a happy smile on her face. You go over and ask about the gas stations and and if she liked the picknick area’s and the exits every 20 miles ect etc. Although she answers positive on all your questions she seemed to get annoyed more and more. And finally she burst out: this is not the city I wanted to get to.

You look around and notice the city sign: Heusden. Did she not want to go to Heusden? Yes she did.
Turns out there are two cities of Heusden.

After this your company and the client lawyers have long and large discussions about who’s fault it is and who will pay of the not useful highway.(If you have a good lawyer, your client will pay and then never come back…)

You could also use dimensional planning. When you do, you start by building a dirt road between Amsterdam and Heusden.

After less then a week that would have been finished and you would have discovered that you are going to to the wrong city. You say no problem, we both knew up front we would encounter misunderstandings. You look around, find the new Heusden and build another dirt road. You deliver that one after another week and wow, you discover together with your client that even that is the wrong one. Turns out there are 2 cities in Belgium and 1 in the Netherlands that are called Heusden. Who knew?
After another week, your client is happy that she has a dirt road between Amsterdam and her Heusden. (A lot faster then the original few months.)
Although she does not have all the features yet, she has already return of her investment as she can start sending cars between the two offices of her company. It’s not a great road, it goes rather slow, yet a lot faster then the previous road that had a detour of 100 km.

The day after you delivered the correct dirt road, you started working on a cobblestone road.
After another 3 weeks, you deliver that one.
You can also create a tarmac or asphalt version and a highway version.
Yet in a lot of cases the clients don’t want to highway version another more when they already have the ROI of the previous versions.

Because we all know that when we ask a customer if they want a highway they always say yes, and developers love working on all the features of a highway.

Yet going back to the car example as JB said so nicely yesterday,  most people would prefer a Lexus over a toyota, except if they need to pay for the Lexus, suddenly a toyota (or even a lada -Thx Rik D’huyvetters *2-) is enough. Just like not every developer likes to pay constant attention to all details the way a Lexus demands.

Reader: Well Yves, isn’t it pricy to deliver 3 dirt roads, a cobblestone road, a tarmac and a highway?
Yes it is more pricy then just a highway, yet as we all know errors are made and delivering all that is cheaper then delivering 3 highways, as we almost always seem to do in product development.
Reader: Oh but in my methodology, we prepare so much that we never make mistakes…
If you are sure and you take that risk, be my guest. Even if you are correct (which I doubt will happen in 100% of the cases) I’m pretty sure that by the time you have started creating your highway, a lot of customers have already changed their minds. And our dirt road projects are delivering ROI already after just a few weeks, months before you even have started.

Reader: All nice theory Yves: how does that work in practise?
Ah glad you asked, I almost forgot, I started this blog with the promise I made to JB to blog about one of the nice real life examples.

A little disclaimer, I did change a few details of this story, to protect the client.

This is large company that already has a website, yet the website is totally in a demilitarised zone of the company network. They have created a small thing they are going to sell over the web.
The CFO was a big supporter of this product and wants to see the websales on a continuous basis.
To do that, they would need to breach to security zones and insert the sales data into their SAP.

At such a large company, that is a large project that will take 6 months of development and to prepare, we will start with meetings with at least 20 people in the room. (Security experst, SAP experts, webdevelopers and then lots of  managers all the way to the person below the CFO)

At another meeting, the CFO shares concerns about lacking visibility of the sales progress for the pet product during the first crucial 6 months. I propose a temporary side projects, using dimensional planning. (where we consider the highway version the other project. )

The dirt road version:
Every day, we generate  a pdf report on the webserver that we put on a floppy disc. (Remember  this server was disconnected from most of the network.)
Everyday we print the PDF and bring a copy of the papers of the sales to the CFO office and have an intern typing in all the data into our SAP system.
The PDF report is created by one of our developers on the same day as the product goes life. By the end of the day, we already have the data for the CFO.
First problem noticed: the CFO wants something extra, something our website did not ask our customers buying the product. The developer that had proudly shown the report herself to the CFO, went back to her desk and less then 30 minutes later, the website asked the extra info, and the new report was generated. (Missing the data of the first day.) Right in time for the newspaper article that was published the next day, when a large number of customers buy the product.
The next day, while these numbers come in, our intern tries to add the data to SAP. We discover our second Heusden. Turns out that we were targeting the wrong SAP table.
This fix takes a few days. The CFO keeps getting his report, yet nothing in SAP the first week.
By Friday of the first week, our intern is able to upload data.
Yet it’s very boring work and is totally not scalable. (We have a few thousands sales the first week.) Time for our

Cobblestone version:

This time we are going to generate the report in a cvs format (Remember, this is before xml was popular.) Every day the first developer arriving at the office, wil physically go to the webserver, generate the report and copy it to the floppy disc.
The same developer will take the disc and upload the data to our SAP system.
This version is more scalable, no matter how much we sold our product the previous day, the action for our developer is the same. Even in this version we have a small glitch: one of the fields is marked as text instead of number. (Just a normal bug).

It’s a manual action every day, not automated and is only updated once a day (for the previous day.)

While this solution is in place, the meetings continue for the highway version. At the end of such a meeting, I ask the collaborator of the CFO, how they use the data and if they are happy with the numbers. Almost by accident I discover that the CFO is only looking at the data on Friday.
(So not on a daily basis ) and he even does not care that he does not see the full sales of the day/week.

Luckily I have a meeting with this same collaborator and the CFO the next day. We talk about the progress of the highway project and how it’s really blocking people from working on a high priority legal project. I gently propose that we might keep the cobblestone project in place for now, and put the highway project in hibernate. A lot of people at this company are unhappy, because they had hoped to work on this super duper cool project. The security officer on the other hand is very happy, because she can keep the webserver in the safe zone, without temporary breaches.
In the end, the company saves 6 month of development for a highway, that is putting their network at risk and that would not really be needed.

A few years later I meet the CFO who tells me that the highway project was probably a little overboard as the product they sold online, never got any sales that even came close to what they would have had to spend to deliver the highway project. And thanks to the dirt road project, they discovered very early that the missing e-mail addresses of their customers and that turns out to be the best investment every. This e-mail list has helped them the next years to up sell some of their services to these customers and that has saved the company from going bankrupt.










In 1997 I’m teaching a course on our product. It was a tool that allowed insurance brokers to manager their clients. We had integrated office into it. So I explain the integration of excel and one lady is clearly annoyed and starts to complain about excel and how her life was so much easier before she had to use excel.
It’s almost time for a break, so I say lets take a break now and you show me what you need to do with excel and why it’s such a bad tool.

Glad that someone finally listens to her, she opens excel and puts in 10 numbers and then gets her calculator out of her pocket, adds the numbers together and puts the result below the 10 numbers. 
She had been forced to use Excel already for a year or 2. She had been complaining all the time. And no one took the time to listen to her and explain that excel could do the calculation for her. When I showed her that excel could do that, she looked at me with a look I never will forget. A combination of pure ecstasy that the tool could help her and even more anger that no one ever showed her that. 

>> if you use a tool, yet keep working as before and don’t get the explanation of why and how, a new tool won’t help you much.

And this lady? She took a one week course in Excel, became a big Excel fan and eventually the biggest supporter inside her own company. 

All because of 5 minute of listening to her. 

This is why I try to keep listening to the people in the companies that are “ASKED” to go agile…

This year it’s 10 years ago that I started working full time as what we now call an agile coach.
Agile coaching is change management, it’s helping people from where they are to somewhere else.
That somewhere else, is a place neither of us know.
Partly because I don’t know yet enough what is their current place, partly because they don’t understand what agile really means.


So one of the typically questions I get is: give me an example.
In these 10 years I have worked for the industry automating food factories, healthcare, postal service, banking, insurance, energy services, consumer service and a few more.
When I gave examples in the first years, I was giving examples about one of these companies I helped.

Yet, when I speak for a few hundred people, most are not in the same industry as most of my examples. And even when they were in the same industry, people came with excuses why my example was wrong for their company. For me that was fine. My examples were never intended to be used as best practises in your company. Their are intended to inspire people, so that they can adapt them and find their own solutions.

So gradually over the years I started to use a different story telling technique.

Most of my examples are now about my family.
Because I consider my audience smarter then me and capable of translating examples of my personal life, to their work situation and find their own solution.

I have the impression this works better.

yes, there still are laggards who don’t want to change and think that some of the new idea’s in this fast changing agile world are crazy and won’t work in their company.
That’s fine. I prefer to spend my energy helping people who want to change, that is still most part of the world.
(And they prefer to spend their time with something they know. That is fine too.)

Look at the picture above: I’m pair working with my daughter. Who is the expert on the picture? yes it’s my daughter. Although I have build a lot more castles then she has, and I have a lot of years more experience, she was really the expert. Next time you are pair-programming , think about my daughter and what you can learn from her …
I don’t even have to explain you what you can learn from this situation. I know you are smarter then me and you will find the lessons you need.

Or as my father says: you don’t have to believe in the sea to get wet, you do have to get in to get wet. Meaning, what you learn of a situation is related to the energy you put in.

If this post inspires you, please share your personal stories. How do you apply agile in your life?

This is the video of my presentation with Joppe at Agile Eastern Europe 2015.

The slides can be found here

The last couple of weeks, I have been in a few discussion (on and offline) around the salary of a scrummaster and an agile coach. (Some inspired by our community book on hiring)
In one of these discussions a European company asked me what would be a good salary for their scrummaster. In another a great agile coach (and dear friend of me) wanted to work as a freelance coach in a new country and had no idea what was an acceptable daily rate. Another company was about to start an agile transition and wanted to find the right balance between paying a decent fee and hiring as many great coaches as possible.

The problem that all these people had, was the only decent information they found, came from the USA and did not feel adapted to the rest of the world. And my personal information is, well is just about me and my friends.  And then my friends Sam & Karen launched their salary survey for South-Africa. I thought, why not launch a similar survey but then globally.

And so I did. you can find my globally survey here

I received a few questions about the survey.

– Who has acces to the raw data?
Me, Karen, Sam. In the future I will probably ask my father to help me with the statistics.

– Where will you publish these statistics?
The statistics will be send out to the mailing list and then published on my blog.
I will only publish data about countries I have at least 10 people. Otherwise it feels like not statistically relevant. And it helps to keep more privacy.

– What about totally transparency of agile?
It’s always a trade off between transparency and privacy. I know that some people hoped on full acces to this data. I also know that others are really scared about giving data about their income away.

– What countries do you have data on?

Australia (<5), Austria(<5), Belgium(16), Brazil(<5), Canada(9), Chile(<5), Denmark(<5), Finland(<5), France(9), Germany(10), Hungary(<5), India(<5), Israel(<5), Italy(8), Latvia(<5), Lesotho(<5), Luxembourg (<5), Netherlands(6), New Zealand (<5), Poland(<5), South-Africa (<5), Spain (<5), Sweden (<5), UK (8), Ukraïne (6), USA (19).

Most countries don’t have 10 people yet. So I hope more people will make publicity for it. As I really want to publish some nice data.

Feel free to add your question about the survey below. 


For years my friend Johanna has been pushing me and bugging me and mostly been telling me nicely: yves you should set up a mailing list.
And every time I was convinced, I ended up creating another interactive mailing list to discuss topics I like. Because I preferred interaction over a one way mailing list. Over the years I created these discussion lists.

agile games
Visual problem solving
– Collaboration of topic

Until some time ago, leanpub – my favourite publishing tool- decided to no longer support their mailing feature and integrated mailchimp instead.
And thus I created my first real mailinglist and integrated that with the books I was selling.

* indicates required
Email Format

I just got back from the first edition of GentM 2015. Today the topic was Social Togetherness.
A topic that I expected to be close to my heart because of one of the speakers Frank Van Massenhove.

I don’t know Frank personally, yet I have heard his story many times and it keep inspiring me.
For those who who don’t know Frank, he turned (one of the) worst FOD (ministries – is that an English word?) around to become one of the hottest places in Belgium to work for.
Inspired by semco, the new working etc…

Many people felt inspired by the talk, yet what also happened was that a few people wondered yeah but would it also work (fill in anything you want…)

Now I have been working as an agile coach for ten years, and more specifically the last 5 years helping large to huge organisations in that role. And then my role is partly a change agent.
Helping to turn an organisation into a new way of working, with a big mindset shift.

I helped companies around EMEA and at the same time I spoke at conferences in many different countries.

Two of the most common reactions I get are:

– yes this is fine in (name another country/company ), but this would not work in (the country /company of the speaker)
– yes this is all nice in theory, but in the real world...

And yes, I have to admit, when I read some books, blogs or hear about company x or y, that I think mm this would not work here.
Well, that never is about the other people, that is me being scared of trying.
And so when you think, what I heard at GentM, or what I read about Semco, or saw in the video of spotify, stop thinking it won’t work here. But look for the smallest step you (not your company, you), can make in that direction.

Thus this mean, I’m never frustrated about where my clients are and the speed they go?
No, I’m always frustrated. I always want to go faster. And that is good because that is my job. The moment I’m happy with where a client is, that means I stayed too long.

The story that Frank told today, is where he is now, and yes it’s the good part. I’m sure there were moments he was frustrated, I’m sure that he still has things he wants to improve and he might even feel they just started. That is not the point.

The first big change assignment I took in a large organisation, I felt frustrated about the speed. I felt frustrated about how little we achieved. I thought I was frustrated because I compared them to what I knew in other companies. It took me a few years to realise that was not really the case.

I compared my clients with:

a imaginary team existing of  
– the best developers from the best teams I worked with
– the best tester from a great team I worked with
– a great scrummaster (who is now working as an agile coach)
– a Product owner that is a combination of two great PO’s I worked with, mixed with the person who taught my PO training and wrote one of the best books on user stories.
– …

mixed with stories I heard at conferences, read online, and hopes I have build up over the years.

so really that is not fair to anyone. None of the teams I have worked with or any of my colleague coaches, will win this comparison. All teams will look pale compare to this imaginary team.

What I started to do instead, is compare my clients to how they were when I joined.
F ex: at my current client, we now have the support of the CIO. That is something that I consider necessary for the kind of change we are trying to achieve now. And I have to admit, one year ago, I did not think we would have this already now. That is a huge achievement.

I can choose to complain about all the possible roadblocks and thing that go slower then I want, and yes I sometimes do that, because I need to let go of my frustration.

yet I love my job, because I am asked to help people to find a better working world.

Just as Frank, I meet a lot of good people that are capable of doing extraordinary things, if we allow them to think. And I know they are capable, because they do it. Unfortunately some of them don’t do it at work, but do it in some kind of volunteer work. And I’m totally not against volunteer work (I’m a coach for coderdojo, and I love helping kids discovering technology), yet I don’t like it when people do voluntary work because they can’t do what they would love to do at work.


Ask people their values, give them a why and trust they will figure out the how. (After all you hired them because you thought they were smart.)
Basically treat them as adults.

PS If you think they are behaving as children, ask me at the next GentM, about some of the times I treated my children as adults and what that resulted in… (Thanks Lamazone to ask me the questions that reminded me of these stories…)

The train station in my home town was finished in 1913.

A train station that is 100 years old that means that it’s no longer adapted to the current needs. Meaning, they have to replace the station. Yet a nice building of 100 years old, also means that the building itself is “protected”. (Meaning they can’t destoy the look and feel of certain parts. )
These two together give some interesting dynamics. The project to replace the trainstation is a very interesting project. In this blog post, I’m going to focus on the project management part. It’s interesting because the train station will not close down while they are re-building the station. Or should I say refactoring the trainstation?

Let me explain what they are doing. (If you understand dutch you might want to watch their introduction video)

The original building they will preserve. As the building is part of the unesco world heritage (or something similar)

Yet everything else, all the train tracks, all the platforms and the tunnel below, will be replaced.
Personally I don’t believe in recreating software. Every project I know that rewrote software from scratch, was a near disaster. I once helped to coach teams that would create a software platform, to replace a few websites. (This company had a website for every country they were active in.) The decision was taken a few years before I came to replace everything. They did not want to create a link between the old website and the new one. So replacing bit-by-bit would not be possible. They considered that linking the two security systems would be too expensive. Unfortunatly when they wanted to put the new website life, a lot was not ready. And to keep their deadline, they decided (as I had predicted, 2 years before) to still link the two security systems. Only now that was quickly done, and created it’s own kind of problems.


All this to say I prefer to replace software bit by bit. Sprint after sprint, or week after week. I was on a train ride with one of the managers of that same company and we passed this train station, and he proudly said; well agile can’t work for everything, they can’t use agile to re-build this trainstation. I told him that they were actually doing very agile stuff. They had killed platform 12 and kept the whole station running while doing that.

(Ok there was a shutdown for a day or so.)


The whole rebuilding of the station will take about 20 years. That can’t be agile.Or can it?  For me agile is about adapting to change. And interaction with your customers.

The replacement of the first platform (12) took much longer than expected. 22 months instead of 18 months.  The engineer who explained all this said: if we would have been able to stop the station it would  have been done earlier. Although I don’t know anything of building trainstations, I doubt that. Most projects take longer as expected. Especially when you are sticking to a plan that is not working. And this is where we come to the most interesting part. They did not stick to the original plan.


For platform 10 & 11, they decided to change the plan. And instead of starting to build the platform from -1 and build it up till +1. They decided to start at ground level (level 0)  and build down and up almost at the same time. That way, they can keep their deadline of 18 months for level +1 (where the platforms are.) I am not sure if this also means they will make the deadline for level -1. And that is not really important, the biggest value for the trainstation is level +1 and level 0. If I remember correct, the lower levels are shops and parking spaces.


It’s important to notice that the way the station will look like, won’t change. It’s the techniques that they use to get there. (and probably some of the supporting structures, will be different.)


Like any big building that is created, they have a team of architects that are working full time. On a day to day basis this team takes decision on the infrastructure (read architecture) of the building. They don’t stick to a hug premade plan. The adapt.
If this can be done for a trainstation in use, why would that be a problem for your software?