These are the 5 benefits of Scrum

Lately, I have been giving several Scrum training sessions, mostly in-house to non-IT folks. When I start explaining the basics of the Scrum framework to them, they eagerly want to hear examples and benefits of using Scrum. It always helps to have a good story ready, this blog contains five examples of the benefits.

1. Create Focus during the Sprint Planning

Usually, when I start working with a new team I ask them to put all the activities they are currently doing onto post-its. As soon as all post-its are on the wall, the conclusion is that they are working on a lot of things. People tend to promise to accomplish multiple things at the same time and then start working on five things simultaneously. This results in getting these five things half way done instead of finishing at least one of them. In other words, there is no focus.

Scrum uses a time-boxed period, called a Sprint, for example, a period of 2 weeks. At the start of the Sprint, during the Sprint planning, the team needs to decide what their Sprint goal is and how they are going to accomplish it within the timeframe. Yes, all things on the Product backlog are important, but as a Scrum team we must choose the items which will satisfy our Sprint goal at the end of the sprint. The Sprint backlog will make it transparent what we are working on and show us that we are focusing on our current Sprint goal. At the end of the Sprint we have a “Done” increment, which meets the Scrum team’s Definition of Done. This means there are no more loose ends to tie up and we can move our focus to a new goal to work on in the next Sprint.

2. Courage to work on tough problems during the Sprint

During the Sprint we work on the items from the Sprint backlog. This is usually where the hard part starts. We don’t have all the answers to how to tackle unforeseen problems and there are no written out plans to follow, so we need to figure it out as we go along. A big dose of courage is expected from all team members. The courage to take risks needed to solve tough problems, but also courage to ask questions or to admit you are in need of help from others. A Scrum team is self organizing, which means there is no manager from the outside telling them what and how to do it. The team itself needs to figure this out and organize as they see best. Yes, this may result in making decisions that end up wrong in the end. But this process helps them learn to do it better.

3. Make Commitment transparent during the Daily Scrum

Are you in or are you out? When working with other team members it is always good to know if they are equally dedicated to the task at hand. Ideally a Scrum team consists of team members who are all fully available to accomplish the work together. The key thing is that you have volunteered your time and attention to this task. You need to have a sense of ‘we are all in this together’. If you are only there to give comments and suggestions, but won’t be there to do the work, you will not be perceived as a committed team member. This usually manifests itself during the Daily Scrum, where we discuss with each other if we are still on track to achieve the Sprint Goal. Commitment becomes transparent by personally asking each other what their contribution to the Sprint Goal will be today.

4. Openness about challenges and uncertainties at the Sprint Review

At the end of the Sprint there is the Sprint Review. This is where team members share the increments which have been completed during the Sprint and stakeholders and/or end users are able to give their feedback. The visibility of the product and progress of the work being done ensures that risks can be tackled early. Openness about challenges and uncertainties that team members encountered during the Sprint increases trust amongst everyone involved. What you see is what you get, there are no hidden agendas and no need to hide things. It’s not always possible, but I encourage teams to ask for feedback from stakeholders as soon as the work is done. The feedback loop happens throughout the Sprint and at the Sprint Review there are no surprises.

5. Effectiveness of the Sprint Retrospective is based on Respect

Finally, at the end of the Sprint we have the Sprint Retrospective. This is the event where the team inspects itself and finds solutions to improve the way of working. At the start of the event, I like starting out by stating the Retrospective Prime Directive by Norm Kerth:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Basically, what it says is that as team members, we respect each other. There is no one to blame and everyone deserves to be heard, regardless of background or expertise.
A team can only flourish when individual members flourish. Individuals need to feel respected for who they are, so they are able to increase their effectiveness within the team.

The Scrum values

Have you noticed the 5 benefits as described above not only fit nicely in the five Scrum events, but also in the five Scrum values? In an attempt to make these Scrum values more tangible within the Scrum events, I’ve attached each Scrum value to an event. Here is how:


  • Sprint Planning Focus: Everyone focuses on the work of the Sprint and the goals of the Scrum Team
  • Sprint Courage: Scrum Team members have courage to do the right thing and work on tough problems
  • Daily Scrum Commitment: People personally commit to achieving the goals of the Scrum Team
  • Sprint Review Openness: The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work
  • Sprint Retrospective Respect: Scrum Team members respect each other to be capable, independent people

scrum valuesAlthough they have been added to the Scrum guide in 2016, people still tend to skip over these Scrum values. That’s a shame, because understanding what these values mean in practice makes it easier to embed the rest of the Scrum framework. Making things work within your team is not only about understanding the definition of Scrum. In fact, it should start by understanding what these Scrum values mean to you and how you can apply them to becoming an effective team member and team.

Let’s watch that video again. Crucially, it describes the reintroduction of wolves. It is quite unlikely that the introduction of squirrels, even in quite large numbers, would have had the same effect. Not all small changes are created equally.

In other words, making a small but significant change at the top of the food chain can change the entire ecosystem. This is what biologists call trophic cascades. So how does this translate to the work environment? Making a small but significant change at the right level can change the entire organizational system and culture. It can change the behavior of local deer, diversify the flora and fauna, and reduce erosion. The right behavior at the top – setting the right example – will change the behavior of the entire organization, will make your organization more attractive to a more diverse workforce by being a great place to work, and thus improve employee retention.


trophic cascadeSource: The City University of New York

Fundamentally, what ultimately changes the ecosystem is different behavior by the deer, who start to graze in different areas. But what triggers the change in this behavior is the wolves. You simply can’t expect all the deer to change their behavior without a catalyst. Organizational agile transformation is the same.

What does this mean for agile transformations?

Many agile transformations start out as grassroots movements that gradually attempt to scale the organizational ladder. The movement is admirable, but it lacks what is ultimately required to make wholesale significant change – the deer can’t change the ecosystem by themselves. The simple truth is that the grassroots movement rarely includes the most significant apex predators in the organization. Agile transformation cannot succeed without leadership support, but more importantly changes in behavior from those in the position to truly influence the behavior of mammals down the food chain.

One of the ways the wolves in Yellowstone National Park have helped to change their environment is by rewarding and discouraging certain behavior. Driving deer from valleys where they are vulnerable is analogous to setting clear boundaries, changing decision making processes and reward structures. For the deer to change their behavior they need to see the value in doing so. In effect the deer in Yellowstone have self-organized towards the areas that deliver the most value. Leaders in organizations can do the same by setting clear boundaries, funding and supporting the right initiatives but at the same time affording teams the freedom to self-organize around the right areas.

Crucially wolves, like leaders, give new life to an ecosystem exactly because they kill coyotes that prey on the organization. In that sense, they clear unsuitable projects and initiatives that take up considerable resources but have no place in the value/food chain.

Wolves not dinosaurs

So what does the organizational apex predator look like? It is not necessarily the loudest, the largest or the most dangerous individual. It is not your typical organizational carnivorous dinosaur. Large, powerful, extremely dangerous, but slow to change its mind. Let’s consider the wolf more closely. It is a social, engaged and intelligent team player. It is the individuals, or rather close knit packs of such individuals that have the power to change the ecosystem in the organization.

So who might this include? Certainly the top management in an organization comes to mind. But how do they operate? Is it a true leadership team? Do they serve to optimize the whole or do they seek to maximize their own interests? Do they engage in constant infighting and turf wars? Is their goal to strengthen their own position or do they put the needs of the pack above their own? Like the wolf pack a leadership team cannot function well – and ultimately will not survive – if its members go it alone. Like the wolves in Yellowstone National Park, top organizational leadership and its behavior have a massive impact on organizations. Conflict between directors of different departments is reflected in proxy wars between those departments themselves. Ultimately, it slows down the whole organization. Conversely, setting the right example can energize and streamline an entire organization.

Apex predators can also be found outside the ranks of top leadership. Crucially these informal leaders will still need to have the clout to truly impact the organization. Someone leading a highly visible strategic initiative can still have a strong impact, but it is hard to truly influence the center from the periphery.


You cannot change an ecosystem by only working with squirrels and deer. Small changes will not result in large scale transformation unless they are made in the right place, by the right people. True lasting change requires introducing or changing apex predators. Organizational transformation requires changes at the top of the food chain, be it from formal or informal (but influential) leaders. The good news is changes at the top can be introduced to the top of the organizational food chain. A new CEO for instance, who ‘get’s it’.

Another way to reorganize the food chain is to change the existing top dinosaurs into a cooperative, social, intelligent wolfpack. That starts with awareness amongst leaders that they are in fact influencing an ecosystem instead of a machine. Which is why ecosystem thinking is a central theme in our Agile Leadership training.

Like organizational change, forging a top wolf pack can be a hard road, but if you want to change the course of the river, that’s where you need to start.

Finally, please remember ecosystems don’t change overnight. The reintroduction of wolves into Yellowstone National Park eventually resulted in a quintupled average tree height, but it still took time for the trees to grow.


Other insights by Michiel van Gerven

Tackling Crime: How one police unit and prosecutor use Scrum to eat into their backlog of cases

Experiments with Holacracy: Why we stopped doing it, and what we learned along the way

Key challenges to Agile in 2019

Why Agile is the most important Social Technology of this decade

A bit of history

Last year the team also went on a company trip, it took them to the city of Rotterdam. One of their stops was a visit to my former office at Coolblue. One could say this was the start of a mutual interest in each other. I showed them around the office and they shared their views on improving the employee experience. I had just started applying the agile mindset outside of IT and had read their Agile HR book for inspiration. Later in the year Nienke came for another visit to interview me for her Agile Top women series. Several other encounters with Organize Agile colleagues sparked my interest in this company and since May this year I can proudly say I am part of these ‘organization sillies’.

Since then, it’s as if I have boarded an exciting roller coaster ride. No week has been the same. My new colleagues have done their best to make me feel welcomed. I have been able to join them during regular visits to clients and have also been able to provide trainings and workshops with them. The first part of the celebration happened in the first week of June, when we had a big party to celebrate this milestone with clients, family and friends.


Saskia Vermeer

As the newbie, I got the honor to cut the cake (with a sword…)


The trip

We continued the celebration last week with our visit to London. It started really early on a Thursday morning. Everyone managed to arrive at the airport on time so we could catch our 7.20am flight from Amsterdam. After we dropped our luggage at the hotel we made our way to the Mayfair area for some coffee and window shopping. Our first appointment was a lunch date with some of the folks of The Culture Trip. After some Japanese soul food at Bone Daddies we headed off to their offices for a meet and greet with some more colleagues.

The Culture Trip had asked us to do an item on Agile Leadership. We had prepared several workshops which split into break-out sessions, after Minke gave a short presentation about our vision on Agile Leadership. The Culture Trip was also host for the London Agile Coaching Circle Meetup, which I facilitated together with Carmen. We decided on an open space format, which allowed us to gather topics from the participants and also bring our own topics to share with the group. It was an interesting evening with lots of engagement from the participants. We also held a short ‘survey-game’ to visualize the differences between the state of Agile in London vs that in The Netherlands.

On Friday morning it was time for our quarterly strategy session. As a big fan of Liberating Structures I had the opportunity to facilitate an Ecocycle Planning session. It gave us some good insights into the different phases of our activities, which encouraged lively discussions within the group. After lunch, we met with Ryan Behrman who gave us some personal insights from his talk How to run an Agile Transformation (in 10 easy steps). My big take away from this conversation is to start small: decide which part of the organization you can ring fence, which allows you to experiment. And then take it from there.


Riccardo in front of his ‘Restaurant to AWESOME!’ Scrum board


For me, the biggest highlight of this trip was a visit to Riccardo Mariti’s Italian restaurant ’a taste of Tuscany’. Riccardo has managed to run his restaurant by using Scrum. He gave us a tour of his office and kitchen which was filled with whiteboards and post-its. His staff members had enthusiastic stories and clearly enjoyed working there. The food was also delicious, I was really impressed by Riccardo’s inspiring stories and his hospitality. 

Bucketlist Light

After dinner it was time for the ‘Bucket List’-light nominations. Everyone in the company keeps a list: what things would you like to do, have or experience? Light, because it must be feasible and affordable. You nominate one colleague: who do you think deserves to complete something from his/her Bucket List light? What did he or she do for the organization in the past period?

Beautiful speeches were delivered and several tears flowed. I heard a lot of new things about my colleagues for the first time. It was special to witness some of the intimate stories that were told. 

Michiel was the clear winner this night and after a group hug it was time to play the Company Quiz which was delivered with huge energy by Bart and Brenda. It’s clear to me that we have a lot of competitive people in this company. The energy can be quite intense, but seeing all these fanatic colleagues explode in their enthusiasm made me giggle.

Sightseeing and clubbing

After an interesting club on Friday night (I don’t even remember the name of the place) it was time for some tourist activities on Saturday. We enjoyed a (competitive) city trail in the Shoreditch area. After which, we played several nerf games on the Powerleague Shoreditch football pitch. We took time for some good conversations over Indian food at the Dishoom Shoreditch. And for some dancing, we ended up at the Ballieballerson club.


Organize Agile

The pink ball pit at Ballieballerson


I realize I’ve only been with Organize Agile for two months now. This trip to London has helped me connect with my new colleagues and understand the stories behind these wonderful people. 

The decision to leave my previous team wasn’t an easy one. However, the experiences and encounters with my new colleagues acknowledges the fact that I’ve made the right decision to join Organize Agile. Looking forward to changing the future of work together with them.

Who are you?

We are a team of three full time police officers plus two ‘coordinators’, additionally we have a number of officers that work with us on a rotation basis. We work in close collaboration with our district prosecutor (also one of the interviewees for this article).


What does the Common Crimes Unit Do?

We work with a very small team to serve the entire Schiedam (The Netherlands) region. Our unit is responsible for investigating cases that are not the result of a live arrest. If an alarm call goes out, and there is a live arrest, those cases end up with another unit. We take the cases that are the result of a statement taken by our colleagues and have leads we can follow up. The team is responsible for dealing with a vast amount of relatively common crimes. High impact crimes, such as (street) robberies and burglaries are not within the domain of this team.

A typical case might concern public violence, maltreatment, theft or traffic quarrels, but can also include such mundane things as stolen bicycles. The common denominator in these cases is that there is no suspect yet.

On a daily basis we receive twenty to thirty new cases. These cases are screened and prioritized. This prioritization is based on a nation-wide 1-4 scale, with 1 being most severe. Level one and two cases are always picked up, while level three and four cases are picked up depending on capacity.


How and why did you get started with Scrum?

In the old situation we used what we call a buffer. Every case was linked to a single colleague. Not just electronically, a physical filing cabinet of sorts. This buffer got so large that we as team coordinators lost the overview. We no longer knew which colleague was in charge of which case, how cases were progressing. In other words, we had completely lost track of the state of affairs. The quality of our work was often disputable because we would all do things in our own individual ways. This often resulted in rework. Even worse, due to the fact that all cases were assigned to individuals we never got to celebrate success as a team. Even when there were successes they were individual ones, which did not help for team spirit.

The buffer consisted of about 160 cases and we never had a moment to relax. We would get to work at six, eat lunch at our desks while working. Leave work at four. Get home with no energy left to be a good partner or father. Even worse, while working on a case, the new cases would continue to pour in. It truly felt like we were in a never ending story.

Clearly some radical changes were required. We started searching for a way of working that would help us to stop fighting the buffer and also allow us to work better as a team and take joint accountability for the entire case load. We wanted to get rid of the spectre of the number of cases that still needed doing that haunted us. It was constantly getting in the way of our job satisfaction.

We did not immediately transition to using Scrum. We originally started out by using a weekly to-do list. This allowed us to at least monitor what still needed to be done per case but did not result in the level of team initiative we wanted. Rather, team members simply did what was on the list, without considering what needed to be done in other cases or whether there might be more effective ways of achieving our goals. We wanted our team members to think tactically, by simply giving them a to-do list we stripped them of a way to take initiative and grow. Anyone can contribute to a case by simply following a step-by-step guide, even you (the interviewer) but this way you won’t learn.

Last September we saw an announcement by another Common Crimes Unit in Arnhem (elsewhere in The Netherlands): “From one hundred and sixty cases to zero”. We were intrigued and initially skeptical. This seemed too good to be true. We read the message and saw they were going to give a demo of their way of working. As team coordinators we decided to go on the basis of “it can’t hurt, it might just work” and also bring two of our team members. The demo was a turning point for us, we decided on the spot this is how we want to work in the future. Two weeks later we had out whiteboards, magnetic sticky notes and all the other things we needed to get started.

At the demo we also ran into Ton, who had more experience with Scrum and told him: “We want to be a pilot team”.

Ton works for the so-called Q team. A team dedicated to helping the police force innovate and future proof the organization. They had previously experimented with Scrum and Agile within the police force but previously these had always been in ‘change’ situations. This was the first time they would use Scrum in day-to-day core operations.

Ton advised us to call this an experiment so we would be afforded the time and space to learn and adjust as we went along. Before the demo we read about Scrum online and we decided then and there this is how we would work in the future. Ton shared our enthusiasm and offered to help and facilitate us.

The first thing we did to get started was to start using a kanban to offer us a better insight into our case-load and progress and stop us from having to constantly call and text each other till late every night to share information and keep everyone up to date. It’s not necessarily a bad thing to work late occasionally, but this was unsustainable.

A crucial thing we had to do to make this work was to draw a line somewhere. We wanted to start working in this new way but we still had a buffer of 160 old cases. When we started out first sprint these caused constant interrupts. We couldn’t just start with a clean slate, there was still information coming in from ‘old’ cases that we had to deal with.


How were you finally able to start with a clean slate?

Hard work was definitely a major part of it. It did strain the team and that pace would have been unsustainable in anything but the very short term, but the enthusiasm of the team members that had joined us for the demo carried the day. The fact that the prosecutor we work with was also a fan and willing to join us in this experiment was a great help. Together we were able to prioritize and decide that a number of the priority three and four cases that were still in our buffer would no longer be picked up. We simply did not have the capacity to pick up all these cases so we had to write these off to focus on cases with more impact.

We also had to learn to truly work in iterations. It was very easy to get into a flow of constantly adding new cases to our kanban as soon as we solved another. Eventually though we decided to set a clear deadline to start our sprints. While the team continued to work on the backlog of old cases we prepared and refined briefings for all the cases we would pick up in our first sprint.


How do you work now?

We no longer constantly monitor the number of open cases. Occasionally we do still check, but this is no longer our primary driver. Instead we focus only on having a good Sprint. This means doing the things we do right, rather than trying to do everything. Focusing on having a good sprint means we enjoy our work more.

Starting to do Sprint Planning gave us a great way for the team to think tactically and grow their skills. It allows everyone to chime in and suggest how they would tackle the case. You might be the best coordinator or detective in the country but a group of six detectives will always know more than you and have better ideas.

The hardest part was drawing a line in the sand and really deciding some cases would simply have to wait for the next sprint. It felt unnatural because it feels like you are letting people down. However, working in sprints and focusing has resulted in bringing down the cycle time for all our cases, meaning people affected by these cases are more likely to see results earlier.


What you do is not quite conventional Scrum, how did you adapt Scrum in order to make it work for your situation?

What role does the prosecutor have in your situation?
Having the prosecutor present during our sprint planning also allows us to reduce scope gracefully. For instance, when discussing cases the prosecutor will indicate that out of collecting statements from a certain subset of two from six possible witnesses will suffice to take the case to trial. Alternatively, in case witness statements don’t corroborate, we might stop pursuing the case as it will no longer be possible to get a conviction.

The importance of having the prosecutor on board cannot be overstated. Apart from making choices in cases he also prioritizes them. There are simply too many cases to pick up so he helps us by picking the most valuable ones to pull into our sprints.

What is your own role as team coordinators?
As team coordinators we pre-screen and prioritize all the cases. Next we prepare a briefing for these cases. During the next Sprint planning we discuss all the cases with the team and the prosecutor and estimate the work required to get the case done. As team coordinators our role does not fit into a conventional Scrum bracket. There are definitely both Product Owner and Scrum Master characteristics to our work. This is not conventional Scrum but is unavoidable in our work.

We also name all our cases. This is definitely not standard police policy but it helps us a lot. Case numbers simply do not speak to us as catchy names do (we never use real names).

We have also added a ‘planned’ column to our Scrum board. This helps us signal to our colleagues that interviews with witnesses and suspects have been planned so we don’t waste our efforts and contact people twice. More so because we don’t work in the same team composition every day.

On top of this we use a quality assurance column we call ‘check’. This raises quality but also helps develop our colleagues as this ensures we learn from each other’s work. This has worked well for some of our more introverted colleagues on top of massively reducing the amount of rework we need to do. Previously we had quite a lot of rework at the request of the prosecutor’s office because we missed something or something extra was required. That is no longer the case. Team members can challenge each other: ‘shouldn’t we also ask for this? We are still missing this bit of evidence’. This also prevents suspects getting off due to a technicality.


How has changing the way you work affected the people around you?

One of the things we enjoy most is that working in Sprints means we can sometimes actually be done. This has worked wonders for job satisfaction. Cases will keep coming in but while some work may have to be done on them immediately, such as ensuring we get a copy of relevant security camera footage (refinement of sorts), most work can wait to be prioritized and pulled into one of the following sprints.

Being done also means we get to assist other teams, for instance by joining them on police raids or otherwise. This has improved our teams standing in our department meaning they are also more ready to assist us when we require their help.

police man with whiteboardOne of the mobile Scrum boards used bij the Common Crimes Unit to closely cooperate with other teams.

One of the most interesting things we did is to introduce mobile kanbans. Small mobile whiteboards (such as the one in the photo above) that other teams can take with them. Please note, these never actually leave the police station, for obvious reasons. This is a fun way for them to assist us with our cases when they have spare time, but it also ensures transparency. In the old situation we would sometimes ask other teams or patrols to do something for us, or check certain things on the street. They would say yes, but often it would not get done. Using the mobile kanbans they have a visual reminder but it also becomes transparent when things still need to be done, instead of ending up in limbo.

Quite often we receive visitors from other units from across the country, who have heard about the way we work and are considering their own Scrum experiments. We are happy to share our knowledge and learnings but also emphasize there is more to it than whiteboards and sticky notes. We also think Scrum would not suit all police teams but every unit could benefit from having a Kanban on the wall.


Towards an Agile National Police Force?

In the time between this interview and me finishing writing this article (which has taken embarrassingly long) units across the Dutch National Police similar to this team have started their own Scrum experiments. I do sincerely hope it will prove as effective for them as it has proven to be for the team in Schiedam. Crucially, what should be ‘copied’ is not just the kanban board, but the close collaboration, bias towards action, boldness and willingness to learn the Common Crime Unit in Schiedam and their prosecutor so clearly exhibit.

As the Agile movement gradually scales across the organization these teams will inevitably start to change the organization around them, I will be watching their journey with interest and assist wherever I can.


Reflections from an Agile Coach

What the case of the Common Crimes Unit in Schiedam makes abundantly clear is that Agile is ultimately all about the people. It is a clear example of a team with a bias towards action (like pretty much all of the people in the Dutch National Police Force I have met), boldness and willingness to learn that is required to take on Agile in an unconventional environment. Every single one of them is a team player. Before the team started using Scrum they were just as dedicated to their work, but changing the way they work has empowered them to work as a team like never before.

The trio of prosecutor and two team coordinators have played (and are playing) pivotal parts. In Scrum terms there might be some role confusion; do they share the role of product owner? Are they also the team’s Scrum master(s)? But they have shown great leadership by creating a safe space for the team to learn and experiment in and constantly and gradually allow the team to grow and take on more responsibility. They are quick to compliment each other and humble about their own part.

They have learned to reduce scope gracefully and prioritize, both in sprint, and when deciding which cases to pull. Non-viable cases are not started and when an in sprint case turns non-viable it is dropped without delay. Credit for this must go to the prosecutor who’s boldness and clear boundary setting allow the team to do so.

The true inter-agency cooperation (Department of Justice and National Police) we see in this case is a great example of customer collaboration over contract negotiation.

You could argue that what is being done is not fully Scrum as prescribed by the Scrum guide (yet). You would be correct but the Common Crimes Unit is doing is clearly working for them in their situation.



This blog came about on the basis of two interviews. One with the Common Crimes Unit (VVC) and another with the Prosecutor. Their Agile journey is their own, I merely wrote it down. I am partial to Agile in unconventional environments and using it to further the greater public good. It is a story I felt is worth sharing and learning from, both in Law enforcement everywhere but also as an Agile community.

I have withheld the names of the interviewees at their request due to the nature of their work.


Other insights by Michiel van Gerven

Why true agile transformation requires apex predators

Experiments with Holacracy: Why we stopped doing it, and what we learned along the way

Key challenges to Agile in 2019

Why Agile is the most important Social Technology of this decade

What is Holacracy anyways?

If you’re unfamiliar with Holacracy, I like to describe it as a way to constantly reorganize and refactor your organization. While it might seem terrible to work in an organization that is constantly reorganizing itself, the point of course is that by constantly changing, change becomes an incremental process rather than occasional and infrequent shock therapy. Ideally, Holacracy makes organizational change easy and helps to ensure your organization is always in tune with what outside forces and the people in the organization demand of it.

Key to this is the concept of a ‘tension’; something in the organization that isn’t quite right, could be better, or is simply missing altogether or superfluous. Anyone can signal a tension and can offer a proposal on how to address the issue. Such a solution might be to assign a new responsibility to a pre-existing role, create a new role, or change an organization policy. To discuss and decide on tensions and solutions Holacracy uses clearly structured governance- and tactical meetings.

Roles are not the same thing as job descriptions, rather they are flexible things that can be created, adapted or disbanded according to the organizations needs. Similar roles or roles that contribute to a shared purpose are grouped together in a ‘circle’. An organization is therefore likely to consist of one main circle with several subcircles. People can have multiple roles at any given time, meaning they should be able to use all their talents and carry all manner of responsibilities, rather than just do what is in their job description. We tried to keep things pretty light-hearted. Minke’s quite seriously named Employee Experience Chief role was contrasted by an IT Troll (one of my roles, basically responsible for making sure we had the right hardware such as phones and laptops), and a Metrics Monster (One of Mikel’s roles responsible for helping us work in a Data informed way).

Crucially, Holacracy is also about distribution of power. To do ‘pure Holacracy’ is to have the owners of a company relinquish their power over it by signing a ‘constitution’. It therefore goes beyond self organization into the realm of self-management.

Should you want to read more about Holacracy, ’Holacracy’ by Brian Robertson and ‘Getting teams done’ by Diederick Janse and Marco Bogers (In Dutch) are good places to start, although I found ‘Holacracy’ a pretty tough read. Alternatively, there is the Holacracy blog.


What did Holacracy ever do for us?

I’m not out to bash Holacracy. We stopped doing it, but before we did, it helped us do many things. So to paraphrase Monty Python: What did Holacracy ever do for us?

men discussingMonty Python discussing the merits of Holacracy circa 30 AD.

Like Agile, Holacracy doesn’t solve all your problems, but it is pretty good at making them visible. Holacracy’s meeting structure and the concept of tensions helped us to bring issues to the surface and forced us to have a conversation about them, even when sometimes maybe we didn’t really want to.

Some of the things it forced us to discuss where our company values, strategies and policies. Any mismatch between them would often result in a ‘tension’ which we would then have to resolve. That wasn’t always easy but at least we were actively discussing them. We also found many of our company policies were implicit. ‘Everybody knows this, right?’ Making our policies explicit definitely raised the quality of our work and helped us to build a culture by doing certain things the same way.

Explicit policies also proved valuable when on-boarding new people, it gave them (including me) something to fall back on. Please note, our entire policy book consists of a thirty row excel sheet, so it’s pretty lightweight.

The Holacracy meeting structure also allowed us to involve everyone in our governance process. We’re not a large organization but it is still nice to be able to use everyone’s knowledge and experience when dealing with something. Holaractic meetings can give everyone a voice.

When our strategy was in flux we were constantly able to adapt the organization to this. Don’t get me wrong, this still hurt, but it gave us a mechanism for clearing up organizational debt.

Finally, we never became stagnant. My favorite thing about Holacracy is that it’s an anti-consensus model. Rather than not deciding anything Holacracy helped us make a decision and experiment with a solution to a tension. If a solution proved ineffective we could always bring up a new tension next week (and we often did).

So in fairness, Holacracy gave us lots. So why did we abandon it?


Why did we stop?

There is not a single reason why we stopped doing Holacracy, rather there are many reasons both large and small which added up to the disadvantages outweighing the benefits. These disadvantages were not necessarily caused by Holacracy, rather they are what we experienced when we used it.

By using Holacracy we sometimes ended up trying to address an issue by assigning a new responsibility to a role or changing a company policy. Sometimes there is another way; simply solve the problem. Holacracy does allow ‘one-off actions’ and you can ask a role to pick up an issue but having a framework for discussing tensions in place sometimes resulted in waiting for the next governance meeting to address something when it could have been solved well before then. In other words in some cases we allowed Holacracy’s framework to limit our thinking in coming up with the right solution.

One such solution we tended to forget about was leveraged assets, meaning simply hire someone or some organization to do the job for us. We moved certain responsibilities between roles (even several times), or sometimes created new ones to solve problems that would have been easier to solve by outsourcing rather than by trying to finetune our internal division of responsibilities.

In Holacracy tensions are dealt with by proposals that can create or adapt roles or policies. If there are objections to such a proposal these need to be validated and if proven valid they need to be taken into account. In our Organization process the validation process created its own tensions. A colleague would have an objection to a proposal but would know from experience this would not be a valid objection. This resulted in people not even bringing up these objections, or already mentioning that they would not be valid. It didn’t make for a very constructive debates and was a cause for some rumbling in the undercurrent of our organization.

Holacracy is also about how power is divided in an organization. It can energize an organization by giving individuals the power and mandate to act. However, we sometimes ran into friction when a role would clash with the implicit hierarchy in our company. It is all very well to put to paper what role is responsible for what but at some point that can clash with what founders (who still own the company) feel the organization should do. This can be partially tackled by giving them the Lead link role, but it doesn’t solve everything. Distribution of power is not just about (explicit) power structures, but also what’s going on beneath the surface.

A key thing my colleague Jens mentioned is the nature of our company. We are a consultancy company, and spend most of our time with our clients. Friday is the only day we all always spend at our own office, in order to work on our shared backlog, share knowledge and improve as an organization. As such governance and tactical meetings were quite a drain on our time. Our time together is very precious to us and we do not take kindly to unnecessary overhead.

Last but not least. We are a company of Agile Coaches, and it shows. Meaning, we tend to have an opinion on pretty much anything, especially on anything in the realms of process, governance and decision making. Our meetings sometimes devolved into soul-sucking discussions. Especially when people felt strongly about issues, and personal tensions might get mixed up with professional ones or elevated to the level of team tensions. I have facilitated my fair share of our tactical and governance meetings and some of those rank among the most difficult sessions I have ever facilitated. I tried following both the process to the letter and being more lenient with the rules, both created issues. It was very hard to get right.

I am fully aware that most of the things above were at least partially our own mistakes, but here’s the thing: Holacracy as a framework should have helped us make our lives, and organizational governance, easier. It did not. Holacracy is anything but simple, and the holacratic road is riddled with pitfalls. Maybe we simply were not good enough, but I believe there are simpler ways to achieve what we set out to do with Holacracy, one of them is organizing ourselves into Agile teams and working from a shared backlog.


How did we stop?

We didn’t just stop doing Holacracy overnight. In fact, for a long time we weren’t even sure whether we had actually stopped doing it. The roles were still there, but we stopped having regular tactical and governance meetings. Basically Holacracy was slowly bleeding out.

We found for instance that administrative roles, or components thereof had all ended up with our Office Manager. Theoretically we could still move these roles to another person, but we never did. In other words, these roles had become waste because in reality they corresponded to a job description.

It took us a long time to make the decision explicit but eventually we decided to formalize what in reality we stopped doing for a while.


What are we doing now?

We still use roles in our company, but there are far fewer than there used to be. We love the flexibility roles offer, but not everything should be a role. For instance, Minke, one of our Agile coaches, has taken on the role of Employee Experience Chief, but most of our colleagues no longer have ‘extra’ roles besides their regular job of Agile Coach.

We have learned from our mistakes and have explicitly given Minke time to fulfill her role. Also we will evaluate her performance in this role on a set date. Not to judge her, but to help her and our organization improve. In doing so we have also shifted towards Sociocracy 3.0. Where Holacracy felt very formalistic this feels more human to us. It allows more space for discussion but isn’t soft.

One of the key concepts that allows us to keep our momentum is ‘good enough for now, safe enough to try’. Instead of wanting to get everything right, this helps us to take a more experimental approach. Something that is close to our hearts, but was sometimes lost along the way.

Putting responsibilities in roles meant work was often done by individuals. As mentioned elsewhere we now use our own stable agile teams to do our development and maintenance work in a structure that could be described as a very lightweight version of LeSS.

Combining elements of Sociocracy 3.0 and stable agile teams allows us to have the benefits of flexible roles, but also simply get stuff done. We still have all sorts of discussions, but the focus has returned to delivering value.


Conclusions, and is Holacracy right for your Organization?

I still like Holacracy, my favorite bit about it is that it is basically an anti-consensus model. It allowed us to be a different organization pretty much every week and experiment rather than get stuck merely talking. ‘Doing’ holacracy is definitely not easy though and bits of it feel overly restrictive to me. Conceptually it is very strong, but execution is hard and to my mind many of its goals can be achieved in simpler ways.

In some ways Holacracy reminds me of yoga. Can yoga help you become more limber? Maybe. Probably. But quite possibly yoga is suited most to people who are already very limber. In the same vein Holacracy can help you become more agile and responsive to change, however it is probably best implemented by organizations that are already very agile. Starting to do Holacracy in an organization that is not ready for it is likely to result in accidents.


Other insights by Michiel van Gerven

Why true agile transformation requires apex predators

Tackling Crime: How one police unit and prosecutor use Scrum to eat into their backlog of cases

Key challenges to Agile in 2019

Why Agile is the most important Social Technology of this decade

In the past few years we at Organize Agile have used Holacracy as a way to share the burden of HR tasks over several colleagues. For us this proved too fractured, it resulted in too much time spent on meetings, and nobody giving HR the time and dedication it rightly deserved. A big mistake, as people are our most important assets and they deserve all the attention we can give. We experimented and learned our lesson, now it’s time to try an alternative: bundeling all HR related things in a single role, the Employee Experience Chief! In this role I am responsible for the healthy and sustainable growth of our organization. My goal is for my colleagues to be highly engaged, and enjoy doing their best work for our clients.

Developments in HR

This HR role did not just appear out of thin air. While assisting organizations in their transitions towards Agile organizations I was gradually drawn into the HR field. These transformations where usually characterized by a lack of involvement from the HR department. This surprised me so much that I decided to remedy this and write Agile HR (in Dutch) in 2017. The goal was to inspire and offer some practical tips to HR professionals in developing agility. During the past two years I have assisted many HR teams in their transition. Sometimes I would coach and facilitate HR teams in working in an Agile way themselves, using Scrum, Kanban, or Agile Portfolio Management, always aiming to develop the Agile mindset. In other cases I would concern myself with HR’s role in the Agile transformation; the development and use of Agile HR instruments and tools and facilitating the development of self-organizing teams.

Questions as an Employee Experience Chief

This year at Organize Agile we are testing whether having me in the employee experience role will help us make our people awesome. Despite a wealth of knowledge and experience I start my new role with lots of questions. I reduce these to two main ones:

  1. Where do I get started?
  2. How can I gain an insight into how everyone is doing?

Where do I get started?

Ready to go? Well not really, because where to even get started? My head is overflowing with ideas, and if that’s not enough my colleagues are happy to add their own. Back to basics: a backlog. On the basis of all ideas and our employee journey we start our product backlog using my colleagues to add to and prioritize it. They are my stakeholders and are the only ones who can reliably tell me whether I am adding value. By putting them in the customer/stakeholder position I hope to achieve that they will be involved in what I do for them, and I won’t spend my time on things they don’t see the value of. I highly recommend doing regular backlog grooming with your ‘customer’. The quality of the backlog increases massively with the questions they ask.

How can I gain insight into how everyone is doing?

Naturally, the simplest answer to this question is to just ask directly. I love that. The least amount of superfluous documentation the better. In practice, this is hard. How can you keep up with everyone in a growing company while everyone works across the country? My colleagues also challenge me on why I would want to monitor this so closely. I have two main goals:

  1. Be able to rapidly respond to individual (development) needs
  2. Gain a better insight into team morale

Developing our buddy system

To help us achieve the first goal we create a buddy system. Colleagues are perfectly able to help and support each other in their needs, it does not require my personal intervention. Every colleague picks a buddy and determines their coaching frequency and what they can expect from each other. This is their own responsibility. We also closely link this to development. That’s a subject for a different blog.

Team development using retrospectives and team metrics

To help gain better insight into team morale we do regular retrospectives. I am embarrassed to admit that in the past few months we had grown sloppy. Busy calendars were used as a poor excuse. While nobody in our line of work needs to be told the importance of retrospectives we still prioritized other matters. Fortunately retrospectives are now back on our regular schedule.

With our clients we have been using the team morale metric (credits go out to Christiaan Verwijs) regularly and we have now also made this a fixture of our own team meetings. It provides us with quick and regular insights into how everyone feels about their work, on the basis of which we can take action. Our team morale metric consists of four questions we ask team members every week.

  1. In my team, I feel fit and strong
  2. I am proud of the work I do for Organize Agile
  3. I am enthusiastic about the work that I do for my team
  4. I find the work that I do meaningful

In (Scrum) teams this metric has proven to be a good predictor of future team productivity. If team morale drops you may expect the team to start missing sprint goals and add less value.

Do, Learn, Keep Going

My first two months as Employee Experience Chief have be fun, instructive, tough at times, but primarily energetic. Responses have been mixed: The buddy system was adopted and executed immediately, the team morale metric was embraced, but there was also feedback (and pushback) to for instance documenting the holiday schedule (‘that’s not agile’).

I will energetically continue to improve our team using small steps. The next few months are all about creating more transparency and clarity (by setting up an interactive personnel handbook among other things) and, with further company expansion in mind, to improve our onboarding process.

Friday morning, May 18th 2018, time for our biweekly team meeting! The entire Organize Agile team is standing in front of our development portfolio board. I enthusiastically share I have been working on our Agile HR convention with Àpun, our marketing specialist. Mikel asks for help in preparing a proposal for a new client. In no time at all we get caught up in a discussion about our leads process and start to lose focus. We are sharing some great ideas, but at the same time the energy level drops and frustrations are rising.

The proverbial Cobbler’s children are going barefoot. Time to get them some shoes.

Part of the problem is that the company is growing. This of course is not a bad problem to have, but is does make it increasingly hard to communicate and cooperate effectively. In other words, we are suffering from our own scaled agile problem.

It is rather ironic to have to admit that we are suffering from the exact same issues our clients are. Fortunately we are all highly motivated to address the problem. Also, because it might enable us to help others more effectively. More and more rapidly growing organizations ask us for help in their quest to become an agile organization. They do not only want do agile, but truly become agile as a person, team, or organization. A common problem in teams is that they simply do not reserve enough time to actually work together.

So what are we doing wrong ourselves? It turns out that as a group of agile coaches we should not facilitate our team simultaneously. We all have an opinion on everything and easily get sidetracked in discussions about how the process should be run. We do not free up enough time to do our own development work, and when we do, often urgent ad-hoc things pop up that we choose to deal with first. On top of this we tend to do our development work in many different small groups, or — if we’re brutally honest — solo. At the same time, we make decisions by consensus, requiring all sorts of superfluous coordination. We all care deeply about our work so we often work evenings and weekends to get everything done. There is real passion for our work, but that is not a healthy situation.


The team mob programming this blog

Much needed repairs

We all agree some major changes are required, but where to start? We decide to take a page out of our own book and start by restructuring the company into stable teams. We self-select into teams taking into account our own personalities, knowledge, skills, and ambitions: excellent! From experience we know that getting the basics right is key. We do our best work when we are co-located, so we decide to physically work together at our offices every week, not an easy task as we spend most of our time with our clients. We decide to prioritize what is important, rather than what is urgent and free up time. At the same time we shorten our cycles by going from a bi-weekly to a weekly team meeting. Working together with the entire team in a single location every Friday allows us to improve communication and produce better results. Focus! We still have limited time (only two hours every Friday) but we spend all of it working together on the same deliverable. During the week we constantly groom, discuss and prioritize our team backlog using Slack and Trello so we can spend our time on Friday working on what is most valuable.

As it turns out it is hard to stick to dedicated development time. Despite the fact that we are all very much aware of the value of focus and prioritizing, we still tend to go with what is urgent, rather than what is important, which is when development time falls by the wayside. We decide development time is sacred, it doesn’t matter what else pops up, development time is always more important.

At first we don’t appoint a team facilitator because we assume a team of agile coaches should be able to self-regulate, but in our team Michiel gradually assumes the role.

Getting shit done

Let’s jump ahead in time a bit. Friday morning January 18th. For the first time in the new year the entire team is complete. After exchanging new year’s wishes and checking in, the stable teams go to work. Each team is free to decide how they do their work. Common denominators are they all have a open and transparant backlog, and we use our portfolio to visualize and coordinate their work. Where we used to fully self regulate, both teams now have a product owner who takes responsibility for the backlog.

The product owner of my team Nienke has prioritized our backlog. Despite the fact that we only have two hours every Friday, our team of five is getting things done by swarming on a single issue. This blog for example, was written as a team co-production in two hours. Including coming up with the concrete idea, writing, adding photos, and putting it live on our website. Our Friday has evolved from a day full of meetings, which we would leave with a to-do list for the weekend, to a productive two hour sprint. The rest of the day is for sharing knowledge , sparring about challenging clients, and yes some vital meetings. Having such a tight time-box ensures we focus and spend our time on what is truly important. We finally get things done every week.

This article came about by talking to various Agile people; Scrum Masters, Product Owners and Agile Coaches in a number of organizations, both public and private and of course my own colleagues. What you will find below are the challenges they mentioned most, coupled with some of my own thoughts on the subject.

Agile In Name Only

The primary challenge is Agile In Name Only. It can manifest itself in a number of ways. The first common way is for a situation to carry the name Agile, and maybe even look Agile, when in reality it is anything but. A situation a senior Product Owner at a financial institution described to me as: ‘Agile 3.0, now with extra top down.’ He was referring to a major project with multiple Agile teams that was using Agile on a day-to-day basis but was also expected to deliver the project fixed budget, fixed scope, and fixed deadline. This was in an otherwise mature Agile organization.

The second way is on the personal level. Like Prince2 before it, the certification happy nature of the Agile crowd has created an abundance of people that have received training but can’t do what it says on the box. When I met Tanner Wortham in Silicon Valley in October 2017 he aptly described this as ‘certificated rather than certified’. In other words, someone who talks the talk, but can’t walk the walk. Fortunately, help is available in identifying and avoiding such people.

This trend is mirrored in the fact that many organizations pretend to be more Agile than they actually are. This may be partially driven by an interesting megatrend affecting Agile today: the war on talent. Qualified people are getting scarcer and scarcer. This week for instance, I spoke to a leading Agile Coach at a well know brand that was struggling to find good scrum masters and Agile Coaches. Presenting yourself as an Agile organization may help in recruiting young people especially (not just scrum masters, coaches etc.). Therefore expect this trend to continue in 2019 and the foreseeable future.

A rather special kind of Agile In Name Only is machine room agilism. Many coaches report seeing this more and more as Agile starts to be adopted by follower, rather than early adopter organizations. It is personified in managers that seem to champion Agile, but only do so to serve their personal interest. While they can lever the power of Agile teams to increase innovation and development speed in their organization or department they will support the Agile movement in an organization. But as soon as they will have to change their own behavior they will drop their support. To their mind Agile is only for the production floor. This is a dangerous trend, because it weakens an Agile movement at a key turning point in a transformation.



Everybody’s doing it

As it turns out, there is such a thing as a conservative Agile transformation. A type of transformation that is not driven by a true desire to ‘go Agile’, but one that seems to start out of a fear of lagging behind and the feeling that ‘everyone is doing it’. The trouble with these is that what has worked somewhere else, will not necessarily work for you.

The banking sector for instance seem to suffer from Spotify-syndrome. Across the world we see virtual carbon copy implementations of the same model (hold your comments, I am perfectly aware the spotify model is not a model). It comes in many guises; bricks, squads and cells are all names for the same thing, an end-to-end Agile team.

Most coaches and consultants I spoke to are expecting to see more and more of these types of transformations in 2019 as Agile starts to become more and more mainstream. Such cookie-cutter transformations carry with them an inherent risk, which brings us to my next point.

Incomplete transformations and commodification

As Agile starts to become more widespread the danger of a backlash increases exponentially. Typically, an incomplete or conservative implementation (yes in this case it is usually an implementation rather than careful adoption) involves a large scale training effort, a phased roll-out of the selected Agile framework across the organization, and a steep consulting fee. Clearly there is more to transformations than rolling out a framework. Without serious consideration for what goes unspoken any transformation is doomed to fail.

Agile is fast becoming a commodity of sorts. This is clearly exemplified by the entry of large consultancy firms into the market. On the one hand they are very welcome, they have the clout to convince the upper echelons of management and their entry is a clear signal that Agile is starting to become the new normal. On the other hand they are a clear reflection of what is sometimes referred to as the Agile Industrial Complex. There is money to be made in selling Agile. Which is fine, if what is being sold is true Agile. Too often, however, selling Agile involves selling Agile frameworks or methodologies without consideration for the things that truly matter, the mindset and ideas behind the frameworks.

Inevitably, we will (start to) see failed or incomplete transformations. This will cause many to become even more skeptical towards Agile. In the past Lean has suffered from a similar backlash. In many organizations it is not uncommon to hear ‘we survived Lean, we will survive this’. The value of Lean principles has not gone away, yet the inherent inertia and resistance to change in many organizations has resulted in an unsuccessful adoption. As more organizations will try to adopt Agile and fail because they underestimate the challenges involved or simply because they want the benefits without putting in the work and making the hard choices.

Leaders are afraid to admit they don’t know what Agile is

One of the most curious challenges pertains to leadership in organizations that first start out on a path towards transformation. Being a senior leader in an organization is not an easy job at the best of times. Now imagine coming face-to-face with something that goes completely against everything you have always known, something like Agile. Agile likes to turn things completely on its head, in fact that is one of my favorite things about it. However this, coupled with the fact that Agile is now trendy, makes it a difficult beast to handle for many managers. For them, it has until now been a thing that ‘some of those IT teams do’.

Many of the Agile coaches and scrum masters I spoke to signaled that senior managers are often lacking in knowledge of what Agile truly is. Moreover, they are often in the unenviable position that admitting to this doesn’t feel like an option to them. Educating leadership on Agile should therefore be a key issue in 2019, especially since without them, wholesale adoption of Agile in an organization is downright impossible.


Agile In Name Only and the commodification of Agile may be the two most dangerous trends facing Agile today as they bring more and more people into contact with a faux form of Agile. Not only does faux Agile not ask the real, hard questions, it might also put many people off Agile as it fails to deliver on its promises.

But, let’s not forget there is also plenty of cause for celebration. Agile is clearly starting to move into mature territory. Adoption is more widespread than ever and Agile ways of working are steadily becoming the new standard in an ever in widening range of disciplines. In Finance, and HR especially Agile is really taking off.

As an Agile community we should be ready to confront the challenges in this article and make sure we can continue to change the future of work for the better.


Other insights by Michiel van Gerven

Why true agile transformation requires apex predators

Tackling Crime: How one police unit and prosecutor use Scrum to eat into their backlog of cases

Experiments with Holacracy: Why we stopped doing it, and what we learned along the way

Why Agile is the most important Social Technology of this decade


What do we mean by stable agile teams?

By stable agile teams we refer to cross-functional teams that can carry out an assignment from end-to-end. This kind of team works together on the same assignment full time and is not dissolved when the assignment is completed. They are rather given a new assignment. This change is fundamental if you want to start working agile structurally. Instead of bringing people to the work, bring the work to the people (existing teams). In other words, you keep your teams stable. When a new project pops-up, the work is either taken to the most relevant free team or divided over (the backlog of) multiple teams.

By stable teams we explicitly do not refer to homogeneous teams that divide their people over multiple projects or assignments. We would rather refer to such a silo as a department. In such a situation, teams do not work end-to-end but rather work flows through multiple (specialized) departments.

The value of stable agile teams

As a team member of a stable team you are in one team at any given time. This means you do not have to divide your attention over multiple project teams. This decreases the amount of the required task-switching and increases focus . This ensures stable teams to deliver more value more quickly compared to non-stable teams.

Within IT and software development these types of teams are commonplace. Outside these fields many organizations cling to the idea of (relatively) short-lived project teams. If you want to stay relevant as an organization, you need to make the step towards stable teams.

The best predictor of teamsucces is not what you might expect. It is not intelligence, skills, synergy or even leadership. It is safety. What makes people feel safe? Working together in a focused way for a longer duration of time. Every time you break up a team to form a new team, you have to start this process all-over again from square one. Often it is better to give a mature stable team an assignment that does not completely matches it skillset, than forming a new team that needs to go through the forming, storming and norming phases of team development, before they start performing. High performing teams will quickly pick up the required skills, become a high performing team is a much lengthier process.

Many organizations tell us that setting up stable teams in their situation is impossible. There are too many projects and employees simply cannot focus on a single assignment at a time. This points to a more fundamental problem: the organization is unable to make real choices and prioritizes badly. Paradoxically, as the amount of different things you need to get done increases, it becomes exponentially more important to focus on one thing at a time. Only by focusing and finishing tasks and projects one by one, you will succeed to rapidly and continuously delivering customer value.

Another fundamental problem is the amount of time and information that is lost through slow and sub-par communication. This too can be tackled by using stable teams that work together, preferably at the same desk. When team members are seated closely together, information is easily shared and problems are quickly resolved. If two team members are discussing an issue, and a third has a solution, it can be solved without a need for long email conversations or meetings.



Would you like to get started with stable agile teams?

The easiest way to get started with stable teams is to simply keep a project team together after the project has been completed. Give the team a clear purpose and allow it to expand its scope to form a full time, dedicated, stable team. Another way to get started is to seek out a group of pioneers; a group of highly motivated colleagues that is ready and willing to experiment and to take on a challenge in close collaboration with a product owner and their stakeholders.

We recommend you to start out small, focus on one or two teams. They will help you to rapidly find any obstructions in the current structure of the organization that block progress. They are the trailblazers that will clear the way for other teams.

Are you also working on too many projects at the same time? Is everything both urgent and important? Do you spend most of your time at work in meetings? Are your team members unmotivated and do you miss commitment? Would you like to know how your company can start to reap the benefits of stable teams?

Feel free to get in touch. We would be happy to discuss things over coffee.

Reptile brain

We’ve all been in this situation: As soon as you walk into a room you notice something is off, without anyone telling you so. The most primal part of our brain, the reptile brain signals you to beware.

There are many factors that contribute to a sense of psychological (in-)security. This article will focus on one of them: the importance of clear boundaries. All of us, as individuals and employees require a certain level of security. For some this means a preference for predictability in their work, others might require a clear awareness of what level of autonomy in decision making the organization permits.

In his research on organizations and change Joost Kampen draws a parallel between insights from remedial education and the behavior of people in corporate environments. It states great leadership is a combination of being available emotionally and setting clear boundaries.

The role of agile leaders

Leadership, including setting boundaries, is not just the domain of managers, team leaders and directors. Wherever you stimulate taking responsibility you may (happily) expect to find leadership.

André Wierdsma, professor of Organization and co-creation at Nyenrode Business University, recently wrote the following: ‘By nature people are very sensitive to authority and in- and exclusion. We are afraid the herd will leave us behind. True self-management, therefore does not exist, because there are always people that take the lead and shape this self-management. All groups require clarity on axes of freedom, values and the rules of the game. Even in organizations with a very flat hierarchy that seek to empower the lowest possible levels in the organization, leadership activities remain important. It is possible, however, to redistribute these activities.’

Boundaries, clear assignments and agile organization

The most common way to organize in an agile way is Scrum. One of the core strengths of Scrum is that it is highly structured. The product owner represents the customer and has a clear vision on what problems need to be solved. He or she is in charge of what: What needs to happen, and in which order. Budget and time allotted present other boundaries, as do other projects, and stakeholders the team needs to take into account.

Within these boundaries, the team has a high level of freedom. The team is in charge of how. How will we solve the customer’s problems and what should that look like. On the basis of regular feedback the product is developed by the team while continuously focusing on delivering maximum value for the customer.

What happens when you set a teams’ boundaries too narrow? You will rapidly lose all initiative. Instead the team will look to the product owner for even the smallest decisions and all energy will drain from the team. (sounds familiar? non-agile projects are even more susceptible to this)

Personally, I have found that a Scrum team with a Product Owner that has set the team boundaries too wide can usually still function reasonably well (especially compared to a team with very constricting boundaries). What will hopefully happen with such a team is that by using reviews and feedback from customers and stakeholders the boundaries will become clear over time. Either the team finds the guardrails by itself eventually, or the team is able to link the project to the organization’s purpose and priorities.

Real world examples

One of the organizations I am supporting in their agile transformation uses a very incremental experimenting approach. During their transformation I was struck by the lack of clarity and transparency in all steps of the process. Employees were at a loss about what strategic direction the management envisioned as there were multiple conflicting strategic directions. In order to become agile leaders, the first order of business is for the top leadership to agree on boundaries for the organization. On top of this we will devote considerable time to clear communication and leading by example.

Interestingly, in organizations where this is clear, agile teams are quite often not happy with these boundaries right away. Rather they feel they are being restricted in their freedom. True master ship lies in being able to provide teams with exactly the right amount of freedom. Finding -and maintaining- a balance over time is what every agile organization’s leadership needs to make a priority.

A clear purpose

Every team or management assignment should be in line with the organization’s reason for being. This serves as a compass. What are we all about? And what is outside the scope of our organization?

It is often referred to as a purpose, the Why (Simon Sinek), Intention (Wouter Hart). A purpose is not merely about making money. Rather, a purpose serves to energize employees end offers customers a way to connect with your company.


Making boundaries explicit and giving clear assignments is crucial in an agile organization. Only when these are explicit and clear teams will feel the freedom to do what is required for the customer. Leadership’s role is to offer clarity or create a situation in which boundaries will automatically become clear over time. Tip: don’t forget a clear purpose.

Need inspiration? Morning star, a leading tomato processing company works by these two principles: ‘No use of force’ leading to total freedom, and ‘Keep your commitments’ which leads to total accountability.