Tackling Crime: how one police unit and prosecutor use Scrum to eat into their backlog of cases
When training Agile Coaches in the Dutch National Police one of them mentioned to me that he had recently started a Scrum experiment at one Police unit, the Common Crimes Unit in Schiedam. They were using Scrum to deal with their caseload and were having considerable success. They agreed to be interviewed so they could share their experiences. This article is the result of that interview.
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.
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 purist 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.
Originally published at https://www.organizeagile.com.