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!

Permanente koppeling naar dit artikel:

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

Lees verder »

Permanente koppeling naar dit artikel:

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?

Lees verder »

Permanente koppeling naar dit artikel:

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.


Permanente koppeling naar dit artikel:

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.

Permanente koppeling naar dit artikel:

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.

Permanente koppeling naar dit artikel:

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.

Permanente koppeling naar dit artikel:

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.

Permanente koppeling naar dit artikel:

Apr 10

To Scrum or not to Scrum

hamletA good colleague of mine came up with a good idea. Or better said, a good mindset. For a while now in Scrum there is something known as Scrumbut. It’s like the Pino in Prince2 (Prince in name only). We Scrum….but.. and then the excuse why you are not fully doing Scrum.  “We are doing Scrum but only do the daily standup, the planning is done by the project-manager” . I know of a lot of companies and teams who do Scrumbut. They only do a little cherry picking and avoid the more challenging parts of Scrum. “Yeah we do a weekly standup” or “We do sprints of six weeks” and so on.

A lot of people are doing Scrum but only do a few things. They think that it will work. Scrum has only nine basic things you need to get it running. These nine things (three roles, three artifacts and three meeting) are needed to get it to work. Every single one of these nine scrum things has a purpose. It is there for a reason. If you leave them out, your Scrum-process might not work and you get Scrumbut. Now why is this dangerous? When a company is doing Scrumbut and it does not work, they immediately blame Scrum. “Yeah we did Scrum but it did not work for us.” But when I ask such a company why it does not work, I get all the wrongs and hear the stuff they did not do. So that’s why my collogue said. You either Scrum or you don’t. And even if it looks a bit like you are doing it. Don’t name it Scrum. Call it something else.

It is all about an image and a mindset. If you do it right you can name it what it is. If you are doing it just partially it is something else but not Scrum or scrumbut or scrum-almost-doing-it.

So ask yourself the question. Can you say the words with you head held high. To Scrum or not to Scrum, that is the question.

Thanks to Rien Walraven of Centric, credits paid where credits due.

Permanente koppeling naar dit artikel:

Apr 05

The Agile Concerto

Earlier this week I was at the Effenaar in Eindhoven for the first show of The Jam Sessions by The Kyteman Orchestra. It caused a severe case of professional deformation in my head: for me this show is the ultimate agile concert. And it was great!kyteman

Let me first explain the concept of this new project of former control freak Colin Benders (aka Kyteman): a team of 20 good musicians comes on stage with a mission to entertain the audience (in this case 1200 people). They have not rehearsed any songs, they have only built and rehearsed their framework of cooperation. By pure improvisation they create new songs live on stage.

What I specifically like about the framework, is that the string section has a completely different way of working than the horn section. They are both doing what works best for them.

Kyteman himself plays the role of conductor, mostly by giving some general signs, thereby both facilitating and channeling the creativity of the orchestra. For me, witnessing the creative process turned out to be a huge part of the entertainment. The music was mostly good, sometimes great, but also with a few boring minutes.

On 3voor12 Kyteman referred to The Jam Sessions as the complete anti-ego-project. Much like in agile software teams, ego stands in the way of team creativity. I’ve seen it happening in Scrum teams, and I saw it happening at the concert: the boring moments happened when the ego of one individual musician took over (first one of the keyboard players, later one of the drummers and in the encore when Kyteman himself pleased part of the audience by blowing his own trumpet). In all three cases, you could literally see the rest of the team lean back rather than participate.
And the great music sprang when there was no ego whatsoever, just a well-oiled musical team enjoying itself and the entire audience. During those moments I felt very much aware that these awesome songs were not designed upfront, they were invented right there, and will never be played again. It doesn’t get more agile than that.

Let me conclude with a shameless job application. This show in Eindhoven was just the first sprint, there are at least nine more to come. Kyteman, if you read this: I would love to facilitate your team’s retrospectives to enhance your continuous improvement. Please contact me at 🙂

Permanente koppeling naar dit artikel:

Oudere berichten «

» Nieuwere berichten