Feb 05

Scaling Agile, steep mountains have slippery slopes

7699228408_e7805285c5_kA lot of IT companies are trying to work with Agile. And most of them are having some sort of success. But the bigger the company the more difficult it gets. Getting Scrum to work with development teams works in most cases but surrounding management and connecting departments have a hard time to adapt.

To accommodate this we see a new trend. Scaling. Scaling Agile to help larger companies to make the change and gain the benefits of agile frameworks like Scrum or Kanban. But this comes with a price and to my believe might in most cases not even work. When a company starts to work with Agile, often Scrum, a change is set in motion. Communication and interaction start to work differently and the focus moves from budget driven to value driven. As I said, most often the development teams can work with Scrum but the interaction between these teams and the rest of the company becomes blurry. So systems like SAFe, LeSS, Scaling Agile, Blowing up Scrum or whatever the name, are brought in. Sometime because someone read an article or a coach is challenged to come up with something that fills in the blanks. I have heard from companies who start directly with these larger systems without even trying to get the basics like Scrum to work.

Why doesn’t it work? Keep in mind that the idea of scaling comes from the fact that there is a feeling that Scrum does not accommodate the larger picture.  Scrum doesn’t say anything about architecture or design. It doesn’t say anything about DevOps. So smart people start to invent large scale scrum solution that accommodate the bigger picture, but in doing so they forget two very important things. The first one is that the Agile mindset is about people and bringing value. Frameworks like Scrum are designed to help people to communicate and work on value. And they are horizontally throughout the company. They feed on what customers want. Traditional process management on the other hand is budget driven and feeds management and sometimes shareholders. You can read about this in an article from Forbes. Large scale Agile systems are to keep this vertical system in place and in most cases go against everything that Agile stands for. The idea of using Scrum is so everything becomes visible. The good things but also the bad and painful stuff. Agile as an mindset can then help to make the change.

The second thing is that often examples from other companies are used for these Scale Scrum Systems. Spotify is a good example. At Spotify they started small and with Scrum. When they became larger, they adapted Scrum so it worked in their larger system. They started to use Tribes and Chapters. And it is very cool, but keep in mind that this is something that Spotify worked out by themselves. They knew the potential of Agile and got it to work and designed their own Spotify system. This does not guarantee that this will work for other companies. What is good for one might hurt another. So when a company works with Scrum and finds that is does not completely work throughout the entire system. A click and play scaling Scrum system will not work. Each company will have to start working on their own Scaling. Every company has it’s own unique DNA and even though they all might develop software, the people doing this have a unique mind. You cannot upload a system into that mind and hope everything will scale. You have to build it from the inside out and using the companies own building blocks.

We often say that frameworks like Scrum are easy to understand but are very hard to get to work. There is no plug and play solution. We often try to adapt systems or frameworks to the needs of the company. Most companies have grown so large that it is nearly impossible to control. So we try to fit something over the mountain. But when are companies going to learn that maybe they have grown too big and made thing to complex. Maybe it is not about Scaling up. Maybe it is better to start sizing down. To go back to the basics and look at what is really needed and what will bring value.  I know of companies who work with around 250 developers and 5000 surrounding managers and supporting functions. What went wrong there? Together they try to control a large software landscape where most of the functionality isn’t even used anymore. But nobody dares to touch it, change it or throw it away.

So the question is not if you need to scale? The question is if you can reduce. And if this is somehow not an option, don’t just pick a ready to install Agile Scaling system, because they don’t work like that, but start to change from within the DNA of the company. Use Scrum as the tool to make the path visible and apply Agile as you navigation. That’s the way to scale the mountain. And I can provide a lot of metaphors hear about slippery and danger. But I think you can figure it out by yourself. So don’t just use an “instant” scaling system but device your own.

Permanent link to this article: http://agilethings.nl/scaling-agile-steep-mountains-slippery-slopes/

Jan 12

Bring home the bacon not the receipt

BaconWhen did we start to lose track of what we really needed and began focussing on how much something costs? As a Scrum Coach I see it more than often that customers ask how much time something takes. How much effort and money is needed. The planning of a project is build upon the time people are consumed by it and decisions are taken on these plannings. Often I hear that developers need to do something within a certain time. It no longer is important what they do but it seems it is more important on how long it takes.

Somehow it seems that businesses have lost track of what it is all about, namely the delivery of something that is needed. Something of value. A product or service that can help the customer to do business with. The fact that at the end of the year in almost every company, people start to worry about the budget. Either they have to spend the last dimes in order to preserve the same budget for next year. Or there is not enough and more is needed. It is never about what is really needed. I have always disliked the thinking in budgets and end of year nonsense. Somehow customers and companies have lost track of what they are doing. Al the energie seems to go in the effort and not in the result.

In the time before software it seems it was all a bit easier. You needed something. You got it. And you paid for it. You left the store with something that brought you value or satisfaction. Over time products have become more complex and we no longer know what it is that we need. Sofware is no longer something that you can save on a disc, it is intricate and has connection with other networks and services. The scope is lost and the only thing that people seem to hold on to is how much lose is made on something. It seems easier to control how much is spent than how much is gained. This is strange. When you walk into a store, you will look at what you want to have and you make sure that you take it home. I never walk into a store to get something but the only thing I take from the store is the receipt. What I got is not important. Can you imagine going to the grocery and buy stuff you need. But when you get home you tell everybody how much you spend and that you stayed within budget. The groceries you left at the store, but hey you stayed within budget. Seems strange but we do it all the time.

Big companies only seem to focus on controlling budgets and not on what is gained in value. They have lost track of what it is all about and forgot the groceries. No wonder that employees of large companies have no idea what everybody is doing. As long a they work hard, show some results and don’t take to long in doing so. So think of this. What is more important to you as a customer. Getting something of value, something you really want. Or spent money and stay within budget. Do you want the groceries or the receipt? If you want the groceries start by focussing on the value output and not on the cost. Stop wondering how much time something will cost, but focus on what is delivered and why. The why is important, because if you get something that you don’t know why you want it, then why spend money on it.

In order to move towards a more logical delivery of goods, companies need to change their way of thinking. Stop looking at the cost and start looking at the value. Stop thinking in budgets and start with value streams. And most important, start with looking at you groceries and bring home the bacon.

Permanent link to this article: http://agilethings.nl/bring-home-bacon-not-receipt/

Dec 08

Make sacrifices if you want to change

zurbaran-agnus-dei-lamb-of-god-madrid-1339x800“We only do scrum where and when there are problems within the company” the guy said on the other end of the table.”Otherwise we just keep doing what we are doing”. I almost dragged his ass across the table. I often hear this. People think that Scrum is something you only do when you want to solve a problem, as if it is a short term fix. The silver bullit you can fire and then all is solved. Well I hate to bring this to you but it is not. Scrum has to do with organizational change. Once you start to implement, the effect will be noticeable throughout the business. I agree that Scrum is not something you do just for the fun of it. You have to realize why you need it and what you hope to achieve by implementing it. But once it is running it is very difficult to go back.

I also agree that Scrum is not something you do when things are going great. It is something you do when things are not going great. When revenues from developed work are not up to the standard or could be better. It is not so a team can perform better and management can lean back in comfort. And when suddenly things change and work is not delivered as planned by sales, you stop Scrum and go back to the old way of working with micro management. I also see this a lot. “We really have to deliver on that deadline so we quit Scrum until things are smooth again”.

The biggest challenge is to get a business to see that when you want more revenues, better quality work and delivery of work that really has value, you can work with Scrum but you need to go all the way. It is organizational change. Everything needs to change. People have to start working differently. The old ways will have to go, and if that means that people have to change or even have to go, then so be it. I’m a big fan of Ricardo Semler and he said, more or less in these words, that a company is not a family. People come to work, provide a service and get paid for that. The company needs to grow and make profit. And when it doesn’t, you need to change and improve where you can. The company is not for providing jobs, it is to make money. If your company is doing the right thing then people delivering the right thing together can be happy in doing so.

So if you embrace Scrum you need to be willing to change everything. To radically reorganize everything. People who are willing to see this and want to move with this change, keep them and help them where you can. But as soon as you stumble upon conformism, act with your goals in mind. You want to make money and be a successful business. You want people to work together on things that matter so they can produce a good quality product so you can satisfy customers. You do this with people who are willing to do so. You don’t want to do this with people who are out there to save their own ass and their own job.

It may sound a bit harsh but keep in mind why you want change. Why you want departments and people to start working differently. What is the goal of what you do. Is it keeping people within your company happy by solving problems when they occur or is it to be successful and change so problems won’t occur? It’s not why you want to do Scrum. It is why you want to change. The you can look at what you want to change and the how can be with Scrum (thanks Simon). You need to see this first and make sure the people who are at the helm see and understand this and know that you need to change and make sacrifices in order to excel.

Permanent link to this article: http://agilethings.nl/make-sacrifices/

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: http://agilethings.nl/refining-future-force/

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: http://agilethings.nl/what-thrives-a-team-and-each-individual-member/

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: http://agilethings.nl/please-the-customer-fix-the-scope/

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: http://agilethings.nl/devops-building-on-quicksand/

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: http://agilethings.nl/devops-and-product-ownership/

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: http://agilethings.nl/moving-the-mastodont/

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: http://agilethings.nl/you-need-to-have-a-sit/

Older posts «