Nov 18

Predicting the future by force

Lately I see it a lot. Scrum teams who plan a session to look at the product backlog and the items in it. It is named a Product Backlog Refinement. It is always a great idea for a team to look ahead at what’s coming next and to be prepared. It the past it was knows as product backlog grooming, but for obvious reasons it was renamed. But often two things happen at a refinement.

The refinement is just to be prepared for the next sprint(s) and to get more insight for the PO so he or she can determine if the userstories are well defined and clear for the team. But do you need a refinement session? In a well organized and running team, every member should be up to date with the product backlog. There should be time to look at it during the sprint. And there should be a kind of ownership for every team member that ensures that everybody knows what is going on.

Often I see a refinement and the team is discussing on how they are going to build stuff. And I have even seen sessions where the team provides estimates. Sure it makes the planning session go a little bit smoother, but it is again a new meeting and it can be a tedious session.

Teams should communicate all the time about items in the current sprint and stay up to date with what is coming. Also the planning session is for new items based on insights provides by the review. The product owner can change the items in the product backlog bases upon information coming from the review. So a refinement session is a bit unnecessary. After all, thing may change so why look at things that are not sure.

Often a Refinement session is a great indicator that a team is doing Waterscrum. Dividing all the set work over various sprints and not take into account that things will change over time and keep the option to adapt to these changes.

Does that mean that it is not needed to look ahead together? No, it is mandatory that the team should know what coming up next. But it is not a planning session. It is not a how are we going to build it. And it is not to please the business. The idea that you can estimate all the future work is interesting but it is not Scrum. It is so management can keep deadlines and customers happy they way they did in the old days.

You can try to make it work, but if you really want to be agile and work with the flexibility that Scrum provides. And you work with delivering actual value. Solve problems as they popup. And build what is needed and not what is demanded. Then you don’t need it. But it demands from a team that they are all involved and look ahead together and own the product they build.

So refine, please do. But don’t make it about predicting the future. It is just to clarify things, nothing more. If a team needs this extra meeting, then there is something wrong with the communication, knowledge sharing and ownership. Refinement is to make user stories smaller by providing insight and knowledge, and nothing more.

Permanent link to this article:

Aug 20

What drives a team and each individual member?

What drives a team and each individual member?Curiosity
To answer this question we must know how we can acquire this kind of information.

For that I have read ‘Management 3.0 workout edition’ of Jurgen Appelo, especially the part that describes Intrinsic Motivation (chapter ‘Champfrogs Checklist and Moving Motivators’). This book is currently online available for free.
Jurgen speaks about a lot of motivators in life and that there are ten motivators related to work. He explains what each motivator does and how it can affect you, your team or your organization.
These ten work related motivators are:

  • Acceptance
  • Curiosity
  • Freedom
  • Goal
  • Honor
  • Mastery
  • Order
  • Power
  • Relatedness
  • Status


How can you make use of this as a facilitator?
That’s where it becomes interesting!
Personally I wanted to use this into a retrospective to answer the following questions:

  • What moves each team member?
  • What is the main motivator of the entire team?
  • Which coaching opportunities do I have?


This is how I got my answers!Goal
I conducted a retrospective which consisted of the following structure:

  • Happiness metric (10 minutes)
  • Moving motivators (75 minutes)
  • Compliments (5 minutes)




What’s needed for this retrospective?
Preparation time: Several hours of reading Management 3.0 workout edition and printing and cutting the moving motivator cards.
Maximal amount of persons: 9
Time needed: 90 minutes

  • A printer, thick paper and a pair of scissors to create the motivator cards.
  • Excel for generating the charts. I can send you the Excel I used by mail on request.
  • A room with tables so each person has enough room to lay down their cards.

Let’s skip the explanation of the start and the end of this retrospective and let’s get right to the ‘Moving motivators’.


Moving motivators!
Before you are able to start laying down the motivator cards, there must be some explaining and understanding amongst the participants. To achieve a common understanding I explained each of the ten motivators plenary. As soon as we reached a common understanding, we continued to the next step.
The next step consists of actually laying the cards in the ‘correct’ horizontal order. Because there is no right or wrong, your order is always the correct order for you. The most important motivator should be on the right and the least important motivator should be on the left. I explicitly explained this to the group, because we have a ‘leftie’ in our midst.
When everyone understood the assignment, I gave them a question that they needed to answer with the ordering of the cards, each member by themselves on a separate table. Because of the importance of this part there will be no time-box for it. In our case the question was: What do you find important in your job?
As a facilitator you need to sense if someone needs a little direction or not. Therefore, get off your ass and walk around, do a sneak peek at each table.

As soon as the group finishes ordering the cards, you will be able to continue to the next step.

Example of ordered motivators

Example of ordered motivators


Now it’s time to generate some insights!
Let’s ask each member a few questions about their cards.
To generate the important insights I have asked the following questions:

  • What motivates you the most and can you explain why?
  • What motivates you the least and can you explain why?


After each member answered these questions you may point out to the team what’s noticeable.
In our case most of the team members find the same motivator the most important and they are quite divided about their least important motivator.


Let’s start shifting!
Because we’re heading to the next part of our assignment it’s time to do some explanation to the team.
From now on it is forbidden to shuffle the cards. They must remain in place and may only shift vertical.
Let’s give the team members something to think about and let them shift each motivator one place up, one place down or remaining on the same place. For these team members I asked them to think about was the following question: How does your daily work reflect to the motivators? As a facilitator you need to walk around and take a look at the shifting and make sure that each member plays by the rules.

Example of shifted motivators

Example of shifted motivators


Once again we are going to generate some insights!
Even now we are going to ask each participant some questions:

  • What happened with the most important motivator? Did it shift? Which way? Why?
  • What is the most important motivator that shifted up and why?
  • What is the most important motivator that shifted down and why?

When everyone shared their thoughts it’s time to collect all the results.


After finishing the retrospective I went to my computer and entered all the results into Excel.
I have calculated an ‘Average’, a ‘Minimal’ and a ‘Maximal’ team radar.
To generate more information I have also created a bar chart for ‘Variation’/’Differentiation’ and ‘Max difference’.
It’s great to see that ‘Max difference’ gives you insight in how much the individual team members think alike on a motivator.
Does the team agree on what motivates them? With ‘Variation’ or ‘Differentiation’ it’s possible to find an answer to this. A small value on a motivator indicates the team is likeminded on this particular motivator!


Team radar ('Average', 'Minimal', 'Maximal')

Team radar (‘Average’, ‘Minimal’, ‘Maximal’)

On one of the walls in the team space we have added the printed results of the team.
These results consist of:

  • Team radar (‘Average’, ‘Minimal’, ‘Maximal’)
  • Bar chart (‘Variation’, ‘Max difference’)
  • An explanation form for each motivator
  • An overview of the average cards in horizontal order.
  • An overview of the vertically shifted result.
Bar chart ('Variation', 'Max difference')

Bar chart (‘Variation’, ‘Max difference’)


What’s next?
Print the results for each team member: both individual and team results.
Put the team results on the wall and discuss them with the team.
Discuss each personal chart individually.
Pay extra attention to the most important motivators that didn’t shift or shifted downwards.
These are the traps that can demotivate an employee or even the entire team or department. Be aware of that!
By coaching the team and each individual it might be possible to prevent demotivated employees.


My conclusion at this retrospective:
It was an eye-opener to see what can or must be done to maximize the full potential of an individual or the team. In our case most of the team has the same most important motivator, but they were not always challenged enough. This is a risk that needs a direct follow-up.
I already knew that I find it really interesting to discover what thrives someone and by doing this I realized the amount of coaching opportunities related to motivation there are.


How did you use the moving motivators and what results or insights have you acquired?

Permanent link to this article:

Aug 08

Please the customer, fix the scope.

The first couple times this happened I was not prepared. We thought we were doing the perfect agile project and worked together as a perfect team. The Product Owner was committed and really into agile. We all were aware that we were working with a variable scope. Everything seemed ok.

But then, at about three quarters of the project, things got a bit more tense. The question: “Is everything we need going to be in it?” was raised. And we all knew that the main stuff would be. That plus all the new stuff we created since we used our new insight and such. The PO told us that he understood. “It is a flexible scope”. We were young and naive and we assumed the if the PO understood everyone understood.

Old habits die hard

Build all the things What happens a lot in this situation is that when there’s some tension people tend to go back to the ways they know and feel certain with.

Managers from clients tend to think they will get more by overruling PO’s or put pressure on them. Demanding that everything that was in the original estimate should be build. In detail. And the “we are doing agile so we do not really know in detail yet” argument is not valid in this environment. It’s about old school management now.

Managers of the development teams tend to put pressure on Scrum Masters and the development teams to keep the customer happy. Tell them to write less testing, stop pairing, add extra developers and say stuff like: ”We have to cover some real ground now”. This is their attempt to please an angry customer without considering the fact that the customer could be unreasonable.

And in this attempt they sometimes make a decision that can destroy everything you and your team have build:

“ We are going to do the last sprint(s) fixed scope, time and budget.”


  • It’s bad
  • It’s bad for the team. It is a signal that they did something wrong and that management is always needed for solving problems.
  • It’s bad for all employees. It says that you can all do that agile thing but when the going gets tough real management is needed.
  • It’s bad for the functionality. With fixed scope and time there’s not much room for new insights. Just build everything.
  • It’s bad for quality. Since the scope is fixed, everything we do that take time costs us money. More functionality, less testing.
  • It’s bad for relations. There’s no collaboration anymore. There’s a client-supplier relationship.
  • It’s bad for the PO’s since they got overruled and their credibility is gone.

And then what?

Be prepared. Be prepared and try to avoid this stress moment. Mostly it happens when you are on 75% of the project. Help both your PO and your management. The chances are that they are not so into Agile as you are so they will need your expertise. Go outside your team and step in their world. Educate. Try to go to their meetings. Demo. Talk to the stakeholders. And if you feel there is some other expertise needed, ask the people who you think can help.

But most of all do not let this happen to you, your team, Product Owner and the product that you are making. Make a fuss if you need to. It is your project too. You do not want this!

Feel free to give us all some tips or stories in the comments!

Permanent link to this article:

Jul 25

DevOps, building on quicksand?

The management decides they want DevOps and Continuous Delivery. It is faster, cheaper and there are less people needed for the same work. So now DevOps and CD are set as goal for the whole company to reach in the near future. So basically engineering practices are being set as strategy, top down.

DevOps is not something that stands on its own. To really benefit from the concept, the underlying dependencies need to be in order. It is not as simple as adding operation engineers in a Scrum team.

But the question remains: is DevOps without fully implementing the underlying aspects like building on quicksand?

DevOps Overview

Read the rest of this entry »

Permanent link to this article:

Jul 21

DevOps and Product Ownership

Change Tyre

[This article was co-written by Miel Donkers and Niels Talens.]

You could see DevOps as expanding the mindset, toolset and processes which started with Agile. Where Agile focuses on creating maximum business value as soon as possible, DevOps can help you to actually deliver this working software quickly. Finally a Minimal Viable Product makes real sense.

But just as we found out time after time with agile adoption projects, the gap between business and IT is often a bottleneck and not an easy one to resolve. With DevOps this often becomes an even bigger bottleneck since it adds the technical aspect of maintaining software in production.

DevOps is not just a matter of integrating Ops work into Scrum. In this blog-post we would like to focus on questions like; How are we going to …

  • help the business with this changed reality?
  • be able to cope with unplanned work (like incidents) while retaining a sustainable pace?
  • show the benefits of DevOps to the business on short term?
  • make sure features aren’t always prioritized above quality and security?
  • make sure that all important work is going to be planned on time?

Read the rest of this entry »

Permanent link to this article:

Jun 17

Moving the mastodont

1206068419g4cHE2hMore and more I see companies who want to work with frameworks like Scrum but fail in getting it right. The more I look at why this happens the more obvious it becomes for me that the larger the company the more the challenge. And sometimes it is even impossible to get it to work.

In large companies the start of working with Scrum can be sparked in two ways. Either by development teams although this is very rare and I’ll explain later. Or by middle management and this is also the reason that it fails often. Now I’m not talking about a company with around an hundred or so employees, this is a challenged but easy to take. I’m talking about the 1000+ size organizations The bigger the more impossible.  You might gues that this is because the communication is harder and it takes longer to get everybody on the same page.  But it is not the communication that is the problem. It is the anonymity of the company.

If you look at scrum from the bottom up, to start with the teams so to say, it is very hard to get management involved. And when they do, they often lack the power to change upper management. Especially in large companies things go as they go and there is a lot of traditional way of working. Change is hard as many doors stay closed and business will stay as it is. Teams might get some improvement but never get Scrum to work to the full extend. Hey but what about DevOps. Well, DevOps is nice, but when you don’s have the cooperation of the entire company, this will also fail and especially DevOps. But let’s stick with Scrum for now.

What if the upper management wants to change then why should the people in the lower levels of the company? The problem is that the bigger the company, the more the anonymity of its workers. Why should you change when nobody will see it? I often encounter people who have worked almost their entire live at one company. They have seen many changes and scrum is just another thing endorsed by management.  To them it is nothing more then the movie of the week.

So basically the chance that you get stuck when wanting to implement Scrum in a larger company is very real. So should you not do it then? Please don’t let me keep you from trying. But you need a lot of energy and even more, a lot of people who are willing to change. And most important, you need sponsor. You need people who are willing to give time, influence and knowledge to help this change. The bigger question that large companies need to ask themselves, and not just the bigger companies, is why they would want this change. The “Why?” question is the one often not answered. Simon Sinek addressed this topic a time ago and more and more I see this question popup its curious head. Why the hell do you want things? Why would you start with scrum in your large 1000+ companies and if you do why is it not working?

So apart from wanting to turn the company on a 180 degree rampage towards something else. Ask yourself why you would want to do that. And once you know why, you can start with what you need the change and how. So there is a little spark here. You can redesign a big company, but you really need to shout the why question.


Permanent link to this article:

Jun 03

You need to have a SIT

7695928_origSo how do you get things to move within a larger organization? As I mentioned before just hiring an Agile Coach doesn’t do the trick. He or she can only bring change on those parts where people are willing to change. But it is just like a Chinese plate spinner. Once you have the first team spinning. The others will loose momentum and might fall. So you need more hands. You have your different Scrum Masters. True, but what if they need coaching as well or are not yet experienced enough to provoke change. What you need it a Scrum Implementation Team. A group of people with enough knowledge to teach others how to work and act with Scrum but also people who have time to do so. And by time I mean, mandated enough to do invest time and effort where needed. Not just one hour per week. This team also should be able to move freely through the company. And last of all but most importantly. They must have authority. It’s almost like the CRACK rules for a Scrum Product Owner.

This team should also be able to provide change by using Scrum. Build a product backlog with all the goals for that period and conduct daily standups, reviews and even retrospectives. So implementing Scrum with Scrum.  So what does the coach do then? Is he or she suddenly redundant? Absolutely not, but the coach can start with the change on a corporate level. And start helping the Implementation team as they need all the help they can get.

Now this is nothing new. You can read about this in the book that Jeff Sutherland and Ken Swaber wrote “Software in 30 day’s”. Yes I know, it is nothing more then a big sales brochure but it has got some good point. But also look at Spotify where they use coach teams who teach and help the different subgroups. It works. Change is not something you can do alone as a coach or as a single individual within a company. You need people; lots of people who are willing to adapt but also teach, promote and change. So as soon as you can. Start with a Scrum Implementation Team (SIT), or whatever you would like to name it. And keep all those Chinese plates spinning. It’s the only fast way to get things done.

Permanent link to this article:

May 12

Be the change

Image source:

People hire me as a Scrum coach to help them to make changes. Often these people work at companies that want to work with an Agile Framework, often Scrum. In many cases when I have the first talks about the how’s and why’s. I get most of the information I need as a coach to get starting. Sometime I’m asked how I’m going to do my work or if I have a plan. My honest answer is that I don’t. Off course I have ideas about how I’m going to do my coaching but I’ve learned that just starting with inspection and a lot of talks helps me to get my hands on everything.

The biggest challenge I face often is not that of helping a team with Scrum. I coach the Scrummaster and Product owners so they can lead and facilitate the teams. But in almost every case I smash into the company walls. Upper management, CEO’s, CTO’s and so one, sometimes want Scrum to work but don’t invest the time needed to get knowledge for themselves. They just rely on me as a coach to do the job for them. I think this is very dangerous, I might have a lot of knowledge and experience to apply changes but I’m just like everybody else, just human. I can make mistakes and my power (if there is any is limited. But even more important, how can you expect that your company will change if you as an initiator. don’t know what is happening or why. Yes I can teach and consult but the responsibility for change is not mine. It is of those who want that change.

At every intake that I conduct with companies, my first question is why they want to work with Scrum. Often I get a logical response but my response is always the question if everyone is committed and willing to change. But telling that someone is commiting is one thing, actually committing is something else. So I was thinking that maybe it would be a very good idea to make this commitment transparent. Maybe a sort of Scrum Coach Commitment document with statements like this one;

My name is …….., and I hereby commit myself to the learning’s, coaching, consultancy and examples of the appointed Scrum coach and will do everything in my power to turn this change into a success. I know it will be hard and difficult. I acknowledge that the way we are used to work will change and I shall accept this and make this change my own.

I would so much love to set this in writing on the wall and ask everyone who is going to work with the Scrum framework to sign it. I know there is the Agile Manifesto and you might say that this should be enough. But even though the manifesto is a very good idea, it does not say anything about really committing to change.

I would like it if a company not just hired a Scrum Coach as a sort of excuse or silverbullet, but that they openly commit themselves to the change. And then ask a coach to guide them. The best guide is knowledge and this is something that you can get for yourself. So read, learn, get involved, work together and most important be the change. Otherwise it will not work.

Permanent link to this article:

Apr 25

Have fun with Lego

Lego RetrospectiveIt’s not the first time I write about this. Maybe I’m very enthusiastic about this. Maybe I just want to tell you about this because it is plain and simple fun but very effective. Doing your meeting with Lego.

As a coach I help people to see things how they are, either good or bad. Applying transparency is important in every environment, not only if you are Agile or doing Scrum or Kanban. So once in a while it is good to look back at situations to see where you can improve. In Scrum it is a good idea to do this after every sprint. It’s one of the moments where you get to change and improve the way of working. But even if you don’t do scrum it is smart to look at what you are doing. One way to do this is with Lego Serious Play.  You can start with buying a big box of Lego and just do it. But a little knowledge of how Lego Serious Play works and how those little bricks can jumpstart the brain is, I think, important.

I’m not going to tell you how this exactly works. It might take a few pages. Although LSP seems simple, the logic behind it and the working of this method takes a bit more explaining.  But once you are able to understand how it works (ask you local coach or LSP facilitator) you can do very powerful sessions with your team or department.

This is not a blog to sell myself. Don’t get me wrong, I’m always keen to do this and earn a little money. But I write this to show you that you can do more with your Retrospective then just sit around the table and talk. Even when you use stickies, retro-games or whatever, once in a while you need new and fresh ideas to get people to attend with new energy. You might want to consider Lego. The glistering in the eyes of ever the participants is so much fun because no matter what age you are. And no matter what you position is within your company. Everybody just loves to play with Lego. Imagine that you have that positive feeling and then do a meeting. Trust me, it will be both fun and work. It will be serious play.

Permanent link to this article:

Apr 24

Agile Scrum. What else?


Image source:

Probably the first indicator that lets me know as an Agile Coach that people don’t really know about the Scrum Framework or the Agile mindset is the way they describe what they are doing. “Yes we do Agile Scrum”. Every time someone tells me that they are doing Agile Scrum the small hairs at the back of my neck start to rise.

Why you may ask is this the case. For this you have to know the difference between the two. Agile is a mindset. It’s a way of thinking and not a way of doing. If you understand the Agile Manifesto, the four simple guidelines are just not more then what they are just four good ideas. Agile doesn’t say anything about how to work, plan, act or do. It is they way you might approach a challenge. You can’t apply Agile. You can’t implement Agile (trust me, this has been asked of me in the past). It is a way of thinking.

The second is Scrum. And Scrum is nothing more then a very simple framework. Scrum has just nine basis ingredients that if you apply them correctly you might get some things done. Scrum is about how you are going to communicate and get transparency within your work. For as far as I know there is only one kind of Scrum (if you leave the Football out of it). So if you work for example in ICT, none will expect that you show-up in shoulder pads and an egg shaped ball if you say you are working with Scrum.

So when I meet people who say they are doing Agile Scrum, I know that they don’t really understand what’s what. It is a very good signal for a coach to start helping people in explaining what Agile really means. To start explaining how Scrum works. And why they are connected but are not the same thing. Keep in mind that there is no other way of Scrum. And when you do it right, you might be Agile without knowing it.  Don’t use them in the same sentence and know them for what they are en what their place is in your team, company or where ever you might use it.

And yes, the same goes for telling people that you are an Agile Scrum Master or Agile Product Owner. Off course you are. But hey you might say. How about you? In the first sentence you present yourself as an Agile Coach. True. But as a coach I like to look at a bigger picture. Having an Agile mindset and explain and train in Scrum, Kanban, XP or what ever it takes to get to a better way of communicating and collaborating.

So. You can think Agile and do Scrum. If you do Agile Scrum, I might ask you if you also do sporting football, water swimming or parachute jumping with a parachute.  Get the idea? I know. It’s a mindset but very important that you get it.

Permanent link to this article:

Older posts «