I quit one of my biggest clients last week.

For almost 2 years, it has been a major part of my professional career.  You can imagine it was hard to say goodbye after such a long period.

So why did I decide to leave?

Number one reason is that I started to feel settled.
This is my biggest fear, getting so used to the job that it becomes a routine.  I’ve seen this happening to former colleagues of mine.  Sure they knew everything about the company, its politics, it’s business rules, it’s history…  They felt in control.  But then suddenly the company started a big reorganization, and their world instantly looked different.  While they used to be experts in their domain, they had now become legacy, standing in the way of the new business processes.

From that day on I decided that I would never let that happen to myself.

When I experience one week without (healthy) stress, I would force myself to change.  Maybe inside the company, maybe outside.  That’s why I’m still happy to work as a consultant.  I get to switch projects once in a while, meet new people and face new challenges.  Basically, as long as I’m learning, things are fine. When I’m not, it’s time to do something about it.

I thought it would be fun to share my view of the past 2 years in a small personal retrospective.  I’m sure some of my former colleagues will read stuff they didn’t know about.

My 1st week was very hectic. I remember I first went to the SDC conference before starting at the company later that week.  I was tired of travelling and the stress of public speaking, but the friendly atmosphere at the office made it much more bearable.  As with all new projects, I started to dig into the business domain and local terminology which were quite new to me at the time.  I had never worked in the recruiting business before.

It soon became clear to me that this client had an extremely ambitious vision.  The entire business model was turned around to provide better value to its customers.  At the same time, the entire IT infrastructure had to be modernized to be able to support the new business processes.

I entered in what was later seen as the kick-off project of this change program. Lucky for me, the project was still starting up.

Since I was hired for my Agile/Scrum experience, I unleashed my knowledge to the team.  With wild enthusiasm I was confident we could become a great agile team.  Things did change. Not at the speed I hoped for, but we became a closer group and started to get into the cadence of our 2-weekly sprints.

The project entered its final weeks, and things started to heat up. It was almost time to release, but there were still too many bugs and missing features.

As a result, discussions got more intense.  In my opinion because I wanted to go forward full speed ahead, while some members of the team just didn’t care.  I learned later that the organization actually drove this kind of behaviour.

Our CIO who was, and still is driving the vision, helped the team and the product owner to get out of the deadlock.  One of his biggest capacities is that he can slice projects into releases like no other. He can spot options which others will never find.  I learned a lot about release planning from him.  So instead of dragging on until we could finally release the whole thing, we released a 1st version and updated it 2 times later.  While I thought quality would delay this project in the classical sense, it became a success by applying aggressive release planning.

If I look back at it now, we never had that energy and motivation again.  I haven’t found a reason yet. Did it take too much of the team?  I ‘m not sure.  Personally, I felt pretty confident for the next project.

At that time we had already split up into 2 project teams.  While one team was supporting the freshly released application, the other team was building a brand new customer website.  But since this was an architectural renewal, we had to deal with a lot of legacy and synchronization.  What struck me most was the big variability during this project.  We tried different methods of planning & measuring, but never really got it under control.

This was a painful project, from a PM perspective. But again, we managed to release a pretty decent first version of the website and gradually finished the remaining details.  From a team member perspective, this was a project to be really proud of. A new fancy website with lots of visitors every day.  The shiny access gate to the company!

Meanwhile the second team started a 3rd project, which got highest priority from our stakeholders.  A couple of new people came into the picture, and we continued on our way of working.  Many ‘Agile’ practices were present, but with less and less enthusiasm.

It became harder to keep the business stakeholders closely involved, since we seemed to slip from a product view to a technical view.  This made it hard for them to understand what we were discussing during planning meetings and daily standups.  Demos were of fewer interest to them because of the technical angle.  As a result, feedback got delayed and the gap between what was planned and what was delivered became bigger.  But again we managed to successfully release the system.

We came to a turning point.  Or we could pull our act together and try to move back to the agile core, or we moved to a more classical phased gate approach.

The 2nd option was chosen with best intentions.  I was not disappointed because we knew we needed to try something different.  After almost 2 years, it became clear that the organization was not ready to embrace agile and get full use out of it. In my opinion this is in many cases the root cause of why an agile adoption doesn’t sustain.

I loved this customer so much that I was willing to give it a try.

But one of my biggest fears started to form. The start of the next project got delayed because it first had to be analyzed to a large degree.  However, because of the rapid changing business, it became impossible to pin down the requirements in that amount of detail.  One week, we felt like we were almost finished. The other week we were back off to zero.

At the same time, the development team was waiting, eager to get started.  So they kept busy cleaning up their stuff, doing technical tasks, until they got tired of it and the atmosphere started to change.  A classical decision was made to add more analysts to speed up the requirements gathering.  Off course this resulted in even more discussions and less progress.

This is when I realized that I had played my part and should leave it to others.

It was a tough decision to make, but a necessary one.  Although I’m going to miss my ex-colleagues, I’m also looking forward to learn new things, meet new people and most importantly have healthy stress again.

Many thanks to all! I’m sure you will release many more fine applications and I hope together you will find a process that fits the organization.  Who knows, we might meet each other at a conference where you’re presenting an experience report.

Since the beginning of the year I started my own business. You can now hire me as an independent consultant.  Keep an eye on this website.  Things are going to change!

 
(image by -eko-)

Belgium finally has a new government after 541 days of negotiations.   A new world record, that is!

This feels absurd to many, including myself.  It feels even more absurd when you look back at the events during that period.

Many roles were introduced to solve the formation blockage. We had :

• a informateur
• a pre-formateur
• 2 mediators
• a clarificator
• another mediator
• another informateur
• a negotiator
• and finally a formateur.

Many started with great energy and the best intentions, but soon threw the towel in the ring.

Even stranger was the ease with which all parties around the table ignored the sense of urgency.  At many times, the public had the impression that these politicians were just goofing along, not to be stressed by the growing discontent amongst the Belgians.  Several times, the media used terms as ‘final deadline’, or ‘point of no return‘.  Our dear politicians, however, could not be bothered by these expectations.  They could not be stressed, certainly not by a deadline.

Not even when the absence of a government started to influence the local stock exchange.  In the meanwhile, 2 large banks got into trouble and had to be nationalized.  When a 3rd bank got into sight of the nervous market, they kept their cool and continued their steady pace of negotiations.

We Belgians are calm people by nature. We’re living in a small country that has been invaded many times in the past.  The best thing to do was to shut up and play along, until another invader came along.  I wonder what would have happened if this scenario took place in … Turkey, for instance…

But that’s not the way of the Belgians, we riot on Facebook and keep our cool in public.

Sure we feel frustrated, by my biggest concern is about the bad example that has been set again by our dear government officials.  Don’t stress, take your time, avoid commitment until things fix themselves.  This approach already lives in government and private companies in Belgium and has an effect on organizational efficiency.

If our ‘role model’ doesn’t lead by example, what is to be expected of its followers?  How can we create a culture that grows innovation, leadership and accountability, if the system that should be supporting it is promoting the opposite values?

Just had to get this off my chest!  Feeling better now

You see this happening in a lot of Agile & Kanban adoptions.  Enthusiastic people drive change and try to set up a new way of delivering software, based on the so-called new ‘best practices’.  Short feedback cycles, adaptive planning, close communication, built-in quality, … are introduced and tuned to perfection.  Teams are focused to learn and get accustomed to the new process.

This focus prevents them from seeing the whole picture. 
Why are they adopting Agile or Kanban?

Well, in most cases, because IT projects have a horrible track record when it comes to delivering on time and within budget.  And at this moment, Agile methods offer a better chance of successfully delivery.  Sadly, projects are not delivered on their own island.  They are part of a bigger system, which can be a department, a network or an organisation.  Within that bigger structure, there are rules too.  Rules we tend to feel late in the project’s life-cycle.

This is why I’m such a big believer of minimizing work in progress through a flow system.  The sooner we go from customer demand to delivery, the sooner we get valuable information of the interaction points with the rest of the organization.  At that moment we will experience the Theory of Constraints hands-on!  Where does the work queue?  What is the bottleneck?  Why do we experience a hick-up in the flow?

Finding these organisational bottlenecks early is extremely important!  The later you spot them, the more dramatic the consequences.  Let’s look at a common example:

The Scrum project team has been quite succesful.
They managed to plan and deliver iteratively without much variation and grew in efficiency at a steady pace.
Each iteration, they delivered working software on a staging environment and showed it to their stakeholders and power-users.
After 16 iterations, the team prepared a production release which was sent to the operations department.
Everybody was excited about the new application that would be delivered within time to the end users.
But, unfortunately, the release did not conform all the production requirements of the operations department.
They had to change some files and get back in line for an installation in production, which came down to 4 weeks extra.

In this example, the handover between development and operations was the first bottleneck.

Many Agile teams work in a semi-isolated environment.  They are creating a new product, from scratch, with the latest tools.  The constraints they run into are mostly lying in these domains:

• Collaboration with product management
• Acceptance and installation in production

Most other constraints are within their own power.

In most Agile projects I’ve been part of, we were able to bypass these constraints by putting enormous amounts of effort into them.  But what happens after your first release is in production?  In many cases, teams switch to a continuous flow model.  Because defects need to be fixed, extra features need to be released, usability has to be perfected,…

If you’re into lean product development, you first release will be fast, with limited features.  Minimize the cost to the amount necessary to get quick feedback from the market.

The next months you will hit the same constraints again, but only this time you will hit them harder.  While we were able to compensate them at first, by putting in the extra effort, it gets a lot harder when having to do this continuously.

These are the times when the new process gets questioned, when it gets tempting to let things slip and revert to the old ways of working.  When instead, the journey has only just begun!

I find it extremely helpful to keep the theory of constraints in mind when evaluating your Agile or Kanban adoption.

The book is full of terms and references to authors, ranging from the fields of science to philosophy.  This shows the profound thinking on the subject by the author.  While it is easy to explain an idea from your own perspective, it is much harder to include other’s.

Since humans always try to summarize information for the purpose of being able to remember it (according to the author), I will do no other thing:

The key message throughout the entire book is that you can’t predict the future.

OK, thanks a lot monsieur Oostvogels! Did you have to read a book to realize that?  Let me explain.

In Agile, we stepped away from the idea that we can predict the outcome of a project with high accuracy.  We realize that no matter how hard we prepare upfront, reality always turns out differently.  This is exactly the message mr. Taleb is bringing to me in his book.

A Black Swan is a highly improbable event that

• is unpredictable
• carries massive impact
• after the fact, we simplify it’s randomness by trying to explain it

If we transform this to a project context, I would call them blue mice.

Sure they’re smaller, but nobody can predict them.  All the other mice we know were brown, black or even white, but not blue!

This can easily be translated to the events in a project.  If you reflect for a minute, how many blue mice did you encounter in your professional life?  How many small events had a big effect on your original plan?  Maybe a leaking ceiling destroyed your development server?  Maybe John had to leave the project for a week due to a family emergency?  All these random events have an effect on the forecast we once made.

Does that mean we should no longer forecast or plan?

No, it doesn’t! I will try to translate Mr. Taleb’s advice to our blue mice.

1. Do not try to predict blue mice.  Invest in preparing to deal with blue mice.  For instance:
   Don’t create single points of failure. Make sure knowledge is spread in your teams.
   Create back-up scenario’s for your infrastructure.
   Don’t detail out features too far in advance so that a shift in vision doesn’t cause a lot of investment loss.
   Enable your stakeholders to make decisions on how to deal with a blue mouse.
   …
2. Be open-minded.  Grasp any opportunity to learn about your team, your customer, your end-users, …  This will help you to spot blue mice much quicker.
3. Let others create their big forecasts, but don’t place your bets on them.  Keep your own forecasts small and adjust them regularly.
4. Not all blue mice are bad.  Some bring great opportunities.
   Ex. You learned from an end-user that your customer is shifting its vision and will require tools that are not in your product backlog.  This can come as quite a shock, but at least you know!  And chances are, you are the only one who knows.  This information can be used to your advantage by adapting quickly and getting ahead of your competitors.

You see, instead of trying to stick to a plan that is bound to get messed up, due to the random nature of life, we focus on what we want to deliver.  The product backlog is in essence that exact focus.

At the same time, we already know that the delivery will be impacted, due to blue mice popping up in the form of missing functionality, new opportunities, personal events, …  But that’s ok! We have our focus and a mindset that acknowledges the uncertainty.  The way we deal with it, is what makes the project succesful or not.

In an agile project, we have plenty of opportunities to spot a blue mouse.  Thanks to the visibility and feedback loops on different levels (demo’s, retrospectives, planning meetings, daily standups,…) we can spot them early and present them to the decision makers on the project.

The most important thing is that we don’t hide blue mice.  Because if we do, they’ll eat our project from below, until it collapses.

Now if you’ll excuse me, I seem to have a sudden urge for cheese!

It is a modification to the classic ‘Gathering Data’ exercise called ‘Timeline‘.

This is an activity used to reconstruct what happened during the previous iteration.  I also use it during a project retrospective, where it is even harder to recall the stuff that happened during a project.

During the exercise, we take the time to list all events in a chronological order, so we can use it during the next step in a retrospective which is ‘Generate insights’.

Because a reconstruction of the lifetime of an iteration (or project) is subject to our own interpretation, I applied a technique which prevents us from oversimplifying or twisting the facts.

It is a technique that is often used by police detectives when interrogating suspects.  They ask a suspect to reconstruct his story or alibi in reverse.  Apparently it is impossible to make up things when telling a story in reverse.  I’m not saying that people tend to lie during a retrospective, but we do tend to tell a story based on our own interpretations of the truth.

It can protect us from the narrative fallacy, described by Nassim Taleb in his book The Black Swan:

The fallacy is associated with our vulnerability to over-interpretation and our predilection for compact stories over raw truths.  It severely distorts our mental representation of the world; it is particularly acute when it comes to the rare event.  The narrative fallacy addresses our limited ability to look at sequences of facts without weaving an explanation to them, or, equivalently, forcing a logical link upon them. Explanations bind facts together.  They make them all the more easily remembered.  Where this propensity can go wrong is when it increases our impression of understanding.

In my own words (linked to my knowledge ), this means that in order to be able to remember all the facts of a project or iteration, we inevitably try to interpret them and simplify them.  We link them our view of the world, whether or not this is correct.

If we reconstruct our timeline in reverse, it will be much harder to do.

Don’t get scared by the idea. In my experience it feels more natural and is easier to start with the events that are still fresh in your memory.

So give it a try.  In the worst case, you still have one retrospective that wasn’t boring!

The organization did a great job setting up this conference.  For instance, they opened a call for solutions on their website, where people could list the topics they are interested in.  This helped to create a balanced program with blocks of two sessions on one topic.  After each block there was a 15 minute slot available for the audience to asks questions to the speakers, which sometimes led to interesting discussions on stage.

Last but not least, they found quite an interesting venue. The Centralny Basen Artystyczny used to be a swimming pool and has been renovated into an event venue.

The audience was actually sitting inside the swimming pool!

I was invited to do a talk on Agile Estimating & Planning.

The session was based on these 4 questions:

• Why do we need estimating & planning?
• How do we estimate & plan?
• Why do Agile projects need a different style of estimating & planning?
• How do we estimate & plan in Agile projects?

Part of the second question ‘How do we estimate and plan?’, I explained the differences between guessing, counting and measuring by asking the audience to estimate the number of people in the room using the techniques guessing and counting.

I collected the results afterwards and visualized them in this graph.

What are my conclusions from this data?

1. There’s a lot of variation between people’s estimates.
   While it seems not very hard to estimate the number of people inside the room, knowing that this was not a very big conference, estimates ranged from 400 to 50.
2. Guessing has a higher variation than counting.
   You can see on the graph that the range of estimates was much narrower when we used counting techniques.
3. Most of us over-estimated.
   This doesn’t compare to estimating the duration of tasks in software development, where research has shown that we typically under-estimate 20% to 30%.
4. Measuring gives us a pretty accurate estimate.
   By measuring the number of forms that I collected afterwards, I had a pretty good estimate on the number of people present.  Although I still couldn’t be 100% sure it was accurate since some people might not have participated.

When I think of the reasons why there’s so much variation in these estimates, I realize that I might not have been clear about the scope of what we were estimating.

Estimating the number of people present can be understood in different ways:

•  Estimate the number of people sitting in the swimming pool
• Estimate the number of people sitting in the swimming pool & the ones sitting on the sides
• Estimate the number of people sitting in the swimming pool & the ones sitting on the sides & the people at the registration desk in the back.

This confirms that when you’re estimating, the scope should be clearly understood by all.

We often have these issues in teams when we’re estimating software features & tasks.  But for me,the underlying message stays the same.

Count or measure if you can, only use guessing as your last option since it is often the least accurate.

Last week I went to Berlin for the very first Agile Lean Europe conference.

ALE2011 was one of the many ideas that originated during the World Café session hosted by Jurgen Appelo during XP2011 in Madrid.  As I’m a lazy fellow, I suggest you read the history of ALE2011 in this blogpost from Olaf Lewitz, instead of me writing it down.

I was involved in the organisation of ALE2011 on the community sofa, and I can assure you this was a crazy adventure.  Planning a conference with more than 40 organizers can be quite chaotic!  But thanks to some natural leaders like Olaf & Marcin the chaos evolved into self organisation.  They shared their experience of organizing it during the conference in a session.

On Tuesday evening I flew to Berlin after a day of work at my client’s office.  When I met the other participants in the hotel bar, I could already feel that this conference was going to be special.  There was excitement in the air.  Something new was going to happen!  I also understood the success of eXtreme Tuesday Club, when UK agilists explained me that this was exactly the format of XTC.  Having a good time together in a bar, drinking a beer and sharing stories.  This is why I believe the Agile Belgium Drinkups have a good future ahead of them.

On Wednesday morning, the conference officially started with a warmup session by John Jagger.  He involved the entire audience in his cyber dojo, which was quite an achievement, knowing that there were more than 200 people in the room!

Next was a keynote by Rachel Davies. I really like her style. Very down to earth and honest.  One message she brought was that Enterprise Agility may not be possible at all, a statement that I hear more often popping up in the community.  It was strengthened later in the conference by Brian Marick during his lighting talk, stating that we ‘Europeans’ can choose to quit these big enterprises and start up a business of our own.  Especially since we have a healthcare system

In the afternoon Open Space, I proposed a session about healthy KPI’s, a problem I’ve been struggling with at clients.  Adopting agile is fine, but do we just keep our old KPI’s?  I feel that in most organisations theser are no longer suited and trigger the wrong behaviour.  We experimented a little bit with using trends instead of single point measurements, but without a good feeling.  On the last day, Dave Snowden reassured us during his keynote that KPI’s are not useful and should be left aside.  Maybe that’s a little harsh.  I’d prefer what Bjarte Bogsnes said during his keynote about Beyond Budgeting.  A KPI should start from a goal and be revised constantly.  I will experiment with this in detail to figure this out.

On Thursday evening we had a dinner with strangers. The concept goes as follows:

• The organization reserved places in several restaurants across Berlin.
• You sign up for a restaurant and have dinner with people you haven’t met before.

I went to a Spanish restaurant with 6 other conference attendants and had a great time eating tapas and chatting late in the evening. (watch the sparkle in our eyes!)

This proved to be a great way to meet new people.  It should be part of every conference!

Friday started again with some sessions and an open space.  After lunch we listened to some more lighting talks and did a conference retrospective.  Ken Power did a great job facilitating.  I was quite honored that he used one of the exercises of my blog, called retrospective starfish.

The event was closed by a keynote from Dave Snowden and a thanks to all organizers.

In the evening I flew home with Yves Hanoulle, who made the trip much more enjoyable by being quite the storyteller.

I didn’t get to see much of the city, because I didn’t want to miss a second of the conference.  Here’s a picture of ’Checkpoint Charlie’, the one place I visited in Berlin.

The ALE conference had a great first edition.  I’m looking forward to next year.  Who knows, maybe it will be held in Brussels!

I’ve always been a big fan of humour.   From subtle to absurd, I can appreciate it all.  Laughter makes life more enjoyable.  This is something I come to realize more often as I grow older.

Off course my mind starts to wander.  How come our professional life is so serious?  Can’t we drop the charades and make it less formal?

When I reflect on my professional career, what were the times I enjoyed most?

No, it’s wasn’t the time when I got promoted.  Neither when we successfully released a new product.  Not even when I got the project I always wanted.

It were the times when my team had fun. When we enjoyed our work and there was an open atmosphere.  People were energized and talking freely about the work AND their personal life.  These were the times when friendships were made.  You could feel it in the air.  The sound of laughter welcomed you in the morning and waved you goodbye in the evening.

Some might say “All good and well, Herr Oostvögels, but don’t forget we have a business to run!”

Sure, non work related chit-chat should be minimized, otherwise performance drops and costs increase, right?

I beg to differ. Let me show you the reasons why I think chit-chat is important for teams:

• Only when people get to a point were it feels comfortable to talk about anything, you call them a team.  A team can only reach its best results if all members can depend on each other.  This requires knowing each other on a deeper level that pure professionally.
• Chit chat helps people to connect and find common grounds.  This makes working closely together more comfortable, which improves the capabilities of the team.
• Better connections among team members improves communication.  We’re more hesitant to ask a question to someone we barely know.
• Chit chat and fooling around drastically improves the energy at the workplace, again leading to happier people who care about the organization and deliver better results.

A friend once shared this story with me:

“At the time we had a team of 5 developers who were building a new application from scratch.  The pressure was high, but we had this one guy ‘Fritz’ who always fooled around.  Making jokes, sharing stories, doing impersonations, … You could call him the team clown. 
After a couple of months, when the pressure had risen even more, management decided to remove him from the team because they believed that he didn’t perform, and even worse, that he kept others from performing. 
They soon regretted their decision.  The team’s performance didn’t increase after Fritz was removed from the project.  It fell drastically.  Apparently he kept the team together, acting as the glue, building bridges between people and increasing communication between them.  He was the reason why, despite the high pressure, they came to the office smiling each morning.  When that reason was gone, the team fell apart and the project became a drag.”

So although this person might only reach 50 % of the other’s productivity, his part in the team was much more crucial.  He allowed others to reach their full capabilities.

My 2 cents are : If you’re a manager, don’t get stressed when you hear your team chatting and having fun.  Embrace it, because they’re on the right path to become a real team that will exceed your expectations!

Does this sound familiar?

My team is really Agile!

Great energizing statement, right?  Your team has adopted Agile, experimented and gets the ideas behind it.  They deliver value on a constant basis, with high quality and manage to stay close to the needs of their stakeholders.

However, there’s one hidden issue in this statement.  Why do you say YOUR team is getting agile?  Does that mean the rest of the company doesn’t?  Are they not involved?

Using the great lyrics of a band called White Lies to say: This is bigger than us!

If you’re using a bottom up approach, you can’t stop at the team level.  Not including the rest of the company is suicide.  Whether you like it or not, your team is dependant on other teams.  They are probably dependant on the product management team, or the sales team, or even the service department.

If these guys are not realizing that they need to synchronize to the cadence of your team, quality will (eventually) begin to suffer.  It will become harder to feed your flow with high quality requirements that bring value to your customers. As you know, half-baked input leads to crappy output.

Same goes for the teams that are behind you in the value stream. If they don’t synchronize, what’s the point of delivering each 2 weeks?  Your features will only be waiting at the next stop and not reach the requesting customer in time, which will lead to some features decreasing in value.

I wrote down these thoughts after (again) hearing somebody say:

I don’t care about management, I wanna do real work.

Sure that’s funny, but I find it sad at the same time.  Because as soon as you’re working with more than a small group of people, the lack of good management can lead to all your hard work becoming obsolete.  Whether nobody asked for it or nobody needs it any more.  You don’t want to see your 6 month, hard-working project lying on a shelf somewhere, do you?