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

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.

Some Scrum purists might argue that what is being done is not fully Scrum as prescribed by the Scrum guide. They are right, but to me that’s not really the point. What 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.

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.

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 to 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.

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.

Leadership Challenge

Micro management is finished… that is, if you choose to work in an agile way. Agile ways of working focus on delivering the most value for the customer. Employees are in close contact with the customer and are given the mandate to do what is required. Clear boundaries are still provided, and — depending on the chosen framework — clearly defined roles and agreements are in place. In other words, employees are given the freedom to deliver value to the customer in the way they feel is best.

What to do if you’re are a leader that preaches agile, but still checks reports for punctuation and proper spelling? Who intervenes in all aspects of what your team, department or managers do? You will need to practice a new style of leadership, starting with such alien concepts as ‘sitting on your hands’ and ‘asking questions instead of providing solutions’.

In an agile organization it is crucial for people in leadership positions to learn to provide clear boundaries, to allow freedom to operate and share responsibilities within those boundaries. And when we say share resposibility, we do really mean share. Compare how a product owner and a scrum team share responsibility. The product owner is responsible for WHAT, the team for HOW and jointly they are responsible for the product.

The subtle art of sitting on your hands

At Organize Agile we are currently assisting a medium sized public organization transition towards an agile organization. One of my colleagues was discussing the transition roadmap with the senior management. During the conversation the focus turned towards the new e-learning platform and what shape it should take. The management team discussed the new platform in detail, until my colleague reminded them that the HOW was up to the development team.

I am struggeling with sitting on my hands

Elsewhere a manager sighed: ”It’s not easy sitting on your hands. I am learning, but I’m struggeling. Especially when I feel the team should do things differently or when my own manager is breathing down my neck”. Sounds familiar?

Coaching instead of ready-made solutions

Agile is all about trust. While plans and micro management create a false sense of security, trust focuses on letting go, daring to trust anothers capabilities and offering support rather than spelling everything out.

I have seen many examples of what trust can do to an agile team. One of the most poignant was seeing an employee passionately argue a case in front of the management team. Something that nobody, including herself, had expected her to be able to do. Excellent!

The team of directors of one of our clients, who is currently in the middle of an agile transformation, is currently focused on the question how they can reshape their departments into self-organizing teams. To my mind, one of the most important parts of this assignment is developing the right mindset in empolyees, leaders and supporting services. Managers need to become aware of their new role: if an employee comes to you with a problem, help them by coaching them. Offer trust, not a solution. Ask questions.

Stop looking at your manager!

Employees need to take ownership

To employees this means that they should not bother leaders with every little issue or focus on the manager in meetings. Consider team behavior in meetings: even when a team is highly self-organized, they will behave quite differently when a manager is present. Often you will see that at least a part of the team will direct their points primarly at the manager and look for non-verbal signs of confirmation. The key to changing such behavior is making the team aware of their behavior and coach them to do things differently.


Trust includes acces to as much information as possible. Make it easy to access and share information . This includes insight into financial margins, information from management meetings, budgets and maybe ultimately even remuneration. Make sure that there is a way that information and trends teams see at their customers, is shared with other teams and managers. Agile tools and frameworks are a great help. Scrum and Agile Portfolio boards are highly visible and offer easy insight into team activities and ambitions. Similarly, tools like Slack can help make information available broadly. Regardless of the used means, the decision to really start sharing information should be your first stop.


In an agile organization leadership focus needs to be on giving and receiving trust. Agile leaders do not intervene, they coach. Instead of offering ready-made solutions, they offer clear boundaries, direction and ask in-depth questions. Only in such an environment, teams will do their best work and deliver real customer value.

Read the article also here on Medium.com

In order to share both the agile mindset and the hands-on applications that Agile HR entails, we created a new explanimation video. Please enjoy! You can find the script under the video on this page.
Also, feel free to join the Agile HR Community on Linkedin. And take a look at our 3-day Agile HR training in New York City.


Agile HR – the new role of HR in agile organizations: the script

Agility is no longer a luxury: it might be the most important competence of organizations in our time. This means a fundamental shift in the way we think of HR. This is what we call Agile HR.
An agile organization often works with multidisciplinary, self-organizing teams. These teams can take on traditional HR responsibilities: team members look for job training together, recruit new colleagues together and sometimes even determine each other’s rewards.

All this change in organizations creates opportunities. With Agile HR, organizations are presented with the unique opportunity to make both the organization ánd HR more agile.
The are different way of doing this: if the HR-department is still a separate department, it can start working agile itself. By using Scrum, or Kanban, or Agile Portfolio Management, which visualizes which big HR-projects you work on, and makes transparent why the HR department makes certain decisions. HR will continuously learn and adapt, while collaborating with internal clients and stakeholders. This way, the HR department is always focused on the things that matter.

Then there are traditional HR instruments that are up for renewal. Like Strategic Workforce Planning, in which you make long term plans about the people and skills your organization needs. But that is still based on predictability and is often made in isolation by HR. Instead, you can try ‘Big Room Planning.’ Every 4 months, all teams share their quantitative and qualitative needs for new team members. And will act on it together. With Big Room Planning, managing the available skills and the recruitment of new people has become a responsibility of everyone in the organization.
The last way to implement agility in HR is for HR-professionals to take on new roles. As a ‘purpose-developer’, ‘trend watcher’ or ‘agile coach’, they help teams to improve their way of working, and make colleagues happier. Take the role of ‘Employee Experience Designer’ – someone who’s focused on improving the experience of the employee in the organization. The Employee Experience Designer ensures employees are serviced in a personal and delightful way, at every step on their journey through the organization.

In the end, agility is a way of thinking. It is not about controlling and prescribing, but about sensing and adapting. With a goal of delighting the customer, done by powerful, autonomous and happy teams. HR has a key role in spreading this way of thinking. That is why we wrote the Agile HR book, in which we share Agile HR practices and cases.
Organize Agile. The thought leader in Agile.

Agile is coming of age

Over the past few years Agile has come of age. This has become highly visible in the way organizations adopt Agile. The software world has been working with Agile since the late eighties, while non-software Agile projects have only been around for four years. Last year has seen a massive increase in full scale Agile enterprise transformations. It has evolved from an ‘IT-only’ party, to a way to tackle complex projects in all sorts of environments, and finally the focus has recently shifted towards full scale ‘enterprise agility’. Not only is the way we adopt Agile changing, the pace at which these changes are happening, is also accelerating.

rise of agileThe rise of Agile

By enterprise agility we refer to the adoption of Agile and its underlying principles and values at all organizational levels. This implies a different way of steering from strategy to operations, and setting up multidisciplinary teams rather than working in isolated pockets. This development involves a fundamental change in the way we lead organizations as well as a cultural shift: it is in fact a paradigm shift.

A set of guiding principles and a corresponding philosophy are an effective way to cooperate in large scale organizations. Such a universally applicable way of thinking, working and organizing is what we call a social technology. Social technologies are a response to the (digital) technological disruptions in our way of working, organizing and even life. Other examples of social technologies include holacracy and sociocracy 3.0.

Taylorism and Agile are cousins

Agile has become nothing short of the most fundamental social technology since Taylorism. Don’t worry, this won’t be an academic treatise on the merits of different management theories. Rather we believe it is important to understand and evaluate where we come from, in order to decide where it is we should be going.

In 1911 Frederick Winslow Taylor introduced his theory of scientific management. He introduced it with the aim of controlling every work activity, from the simplest to the most complicated. Taylor’s argument was that only by doing so, management could have the desired control over productivity and quality by focusing on the most efficient way to do each task.

We can still see the echoes of his theory in many aspects of modern day organizations. One of the most poignant examples is the way how many organizations treat call centres and call centre agents. Rather than focusing on the best outcome for customers (solving their problems), they obsessively measure and focus on things like call-length and number of calls processed per hour (for an example of the right way to do it, consider this). Not only are we sometimes focused on optimizing the wrong things, this has also created a culture in which we have taught employees to no longer think for themselves. Make no mistake, we are not out to bash Taylorism or a drive towards increased efficiency. Quite simply, we believe focussing on effectiveness, rather than efficiency, yields better results and also makes best use of employees and everything they bring to the table. In our opinion, this is the best way to delight customers. Not to mention it makes work considerately more fun.

Focus on effectiveness — rather than efficiency

Four parallels cause us to classify both Taylorism and Agile as social technologies:

  1. Like Taylorism, Agile is based on a set of underlying principles that guide the way we organize and work. The principles offer guidelines for processes, practices, governance and leadership.
  2. Both combine methodology and mindset. Taylor: ‘The really great problem of the change consists in a complete revolution in the mental attitude and the habits of all of those engaged in the management as well as the workmen’. While we don’t subscribe to Taylor’s strict division between workmen and management, experience has shown that social technologies affect all those in the organization. Not only the business but also the leaders and staff departments need a fundamentally different paradigm.
  3. Technological revolutions were the main driver behind the development of both Taylorism and Agile. While Taylorism was the result of industrialization, Agile was devised as a response to the new possibilities offered by the software and internet revolutions.
  4. Finally, both sets of principles are universally applicable. Agile has taken hold from Australia to Brazil and South Africa to Scandinavia.

Mindset beats method every time

The rise of technologies such as personal computers, the internet and smartphones has radically impacted our lives and the way we do business. We are convinced we are at the dawn of a new era of social technology. As we speak we can see a rapid development in fields such as blockchain, AR/VR, IoT (Internet of Things) and Artificial Intelligence, the true impact of these is yet to be fully revealed. As the pace of technological change accelerates we will also see a rapidly accelerating pace in the development of social technologies such as Agile.

The human mind is ill-equipped to deal with exponential growth. For an example of what that truly means consider the infographic below:

Source: https://medium.com/ai-revolution/how-long-until-computers-have-the-same-power-as-the-human-brain-c1e9741c12de

Principles on how to work and organize can only be effective when combined with a corresponding mindset. When using Agile as method rather than a mindset the long term benefits of using Agile dwindle down to zero. How many times have you seen a team become fully energized when starting out with Scrum only to regress into old habits over time. This is a clear symptom of implementing Agile as a system, rather than fully embracing the philosophy , investing in behavioral change and receiving the full long term benefits. Internalizing such a mindset takes time, coaching, and the willingness to open up and expose yourself to feedback. Teams that fail to do so become demotivated and often abandon Agile altogether, claiming ‘Agile does not work for us’.

Putting the social back into social technologies

For too long the focus in Agile has been on the technical aspects. It is time to put the social back into social technology.

Lasting Agile organizational change is commonly frustrated by the lack of a lasting change in behavior and mindset. All too often Agile transformations are initiated by rolling out a standard blueprint for an Agile organization and simply copying a ‘model’ that has been successful elsewhere. During such transformations the focus is on implementing standard ways of working and associated technical platforms. Rather than focusing on the human aspect, the focus is on systems, processes and technologies. An Agile transformation cannot truly succeed without striking a careful equilibrium between frameworks, technology, and the softer human side, including leadership.

In this context do not take softer to mean inexact, fuzzy or unbusinesslike. Rather it means to act upon drivers fundamental to human nature in order to maximize team effectiveness. Robust enterprise agility cannot be achieved without some form of effective Agile scaling. However, the multidisciplinary team, that works in short cycles on customer delight in a highly visual and transparent way remains the core organizational Agile unit. To ignore the human side of Agile is to ignore at least half of what needs to be done to make your change lasting and successful.

Key to successfully dealing with the human side of Agile is understanding that every team and organization has two basic goals. A team seeks to attain a certain result, but also instinctively works to maintain the status quo in team dynamics. A similar thing happens at the organizational level. Change is resisted as a threat to the very survival of the team.

The true power of Agile is in the undercurrent

We find the ‘softer’ side of Agile is often ignored. Many teams and Agile consultants tend to focus on more visible aspects, such as practices and tools. In these situations a major aspect of the way teams works remains undiscussed, but strongly impacts the way the team works and is felt by all. We call this the undercurrent. The undercurrent in your organization is agnostic, meaning it is neither good nor bad. Yes, a negative undercurrent can ruin a team, but a positive undercurrent is just as likely to make your team fly. Friendship for example is an undercurrent that helps the team perform: there’s laughter and affection that makes working together fun.



A negative undercurrent can always be traced back to four basic interpersonal needs:

  • Inclusion: membership and team boundaries. Do I belong?
  • Influence: Who is in charge? Is my voice heard?
  • Intimacy: Do I dare to be vulnerable in this group?
  • Inspiration: Fulfillment. Does what I do matter?

‘Inspiration’ is key. However much you work on inclusion, influence and intimacy, if a team lacks inspiration, all your other efforts will be futile. All interpersonal needs have many different ways they can manifest themselves. Structurally being late might be a symptom of disengagement, and therefore a lack of inspiration. It is the Agile Coach’s job to investigate and diagnose what is behind such symptoms, and apply the right intervention. Only then can we start to make lasting changes.

Don’t imagine the undercurrent as a problem that can simply be solved. It is a bottomless well that requires constant attention. Problems arising from negative undercurrents might distract you from being aware what is truly going on in the surroundings of the organization. As the tribe struggles internally, it fails to notice the tiger in the bushes. While you are struggling with team issues instead of serving the customers needs, you are losing your competitive position.

The only way to deal with the undercurrent is to bring issues to the surface and discuss them. Agile is uniquely suited to rapidly bringing these tensions to the surface. The Agile creed ‘transparency — inspect — adapt’ engrains a process of continuous discussion about results, team culture and collaboration in an organization. By doing so we turn these tensions into fuel for transformation and lay the foundations for the right culture and mindset in an organization. This mindset is not only key to reaping the full benefits of Agile and becoming a high performance organization, but also readies us for whatever social technology comes next.

Agility enables us to deal with massive change

The biggest challenge the future holds is that we simply have to deal with it. Whatever comes next will require us to have a structure and mindset in place that allows us to deal with massive social and technological change. Agile is the most important social technology of this decade because it is uniquely suited to preparing us for the next (unknown) revolution. Considering the rapid evolution of Agile and disruptive technologies, becoming truly Agile is now more urgent than ever before.

Read the article also on our Medium publication.