In this post I want to explore whether the Increment, a core concept to Scrum, needs to be changed for Scrum in a non-IT context. In future posts, I will do the same for the Definition of Done, or other concepts that may provide a better understanding of Scrum when applied to non-IT context. Please ask questions and make suggestions in the comments! Disclaimer: what I will not do in this post is explain WHY the Increment is a key element for transparency in empirical process control. If you don’t understand this yet, check out this resource and its links. Still have questions? Let me know in the comments.
Scrum is a framework for addressing complex adaptive problems
Since its conception quite some time ago, Scrum has been applied to address complex adaptive problems, by providing a framework for empirical product delivery. Most teams apply Scrum when developing IT products. There are however, a lot of examples of teams working with (and benefitting from) Scrum in other contexts: HR teams, Marketing teams, Police work, running a company, etc. An idea I encounter often, is that you cannot do ‘Professional’ or ‘full’ Scrum in such a setting, and some of its core concepts need to be changed or adapted. One example of this is EduScrum which is used for enabling self-organizing school classes.
My context
For a short time now, I have been the Scrum Master of a Police team working on detection and prevention of Cyber Crime. In the past I have consulted and worked with teams both in and outside of IT development. In this article I will try to give my examples and challenges and how I would approach them. I would love to hear alternate stories and ideas so please reach out with questions, experiences and tips that may be helpful in relation to this topic.
Tricky Concept: the Increment
The Increment is what many people consider ‘The Product’. In Scrum, the Increment is the output of the Scrum team that hopefully delivers value. This is not just the result of the current or latest Sprint, but also includes the value of all previous Sprints. The Scrum Guide has a short paragraph describing the Increment,of which the following sentence is the most interesting for Non-IT, in my opinion.
“An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.”
Scrum Guide – November 2017
The good news is, this paragraph in no way describes the Increment as a software or IT concept. And if you read the full paragraph, you’ll still not see anything that confines the Increment to IT or software. The bad news? it is kind of abstract. Let’s look at what the quoted sentence means most of the time.
Basically, what this says is:
- there is output, that can be inspected;
- this output is assumed to be valuable;
- this output should be in a ‘done’ state at least at the end of a Sprint;
- this output should be part of reaching a vision or goal.
The Increment in Police detection work
For example, in my current police context, for detection work (hopefully convicting criminals):
- the police teams create outputs. For instance an official police file, containing a description of evidence, which is used by the prosecutor to make the case and hopefully get a criminal convicted. But also the registrations that are needed to make sure that the information in the file is admissible in court;
- one of the backing registrations the police file needs is a sound systematic description of how the evidence was constructed. As part of this, relevant changes and data need to be input into an IT system. Only when the police file is based on (and traceable to) official registrations and descriptions, it is admissible in court;
- as a minimum, at the end of each Sprint, the file should be in such a state that no registrations remain or are missing that pertain to useful evidence for the case;
- the official police file and the backing registrations are output that help reaching a vision or goal. This vision or goal is to make the world a little more just, and create a deterring effect, by detecting and ultimately convicting & punishing criminal acts.
The Increment in Police prevention work
Another example, also from my police context, for prevention of crime and victims:
- the police teams create outputs, for instance an event or publication that helps educate civilians and organizations how to be more resilient against cyber criminals;
- for this type of publication to be ‘done’, it should conform to all the rules and regulations of the Police-wide communications, as well as certain language-level;
- as a minimum, at the end of each Sprint, the event or publication should be in such a state that without any further work, it could be used to support prevention activities. Meaning no more work (for instance) corrections should be needed to potentially deliver some value. Bear in mind that this does not mean no further improvements are possible. No further improvements should be necessary for publication (release);
- The vision or goal in this case could be: minimizing the impact of Cyber Criminals by making sure that it is harder to make victims (like education on home security, locks, etc. can help prevent burglary).
You may notice that the second example sounds a lot like a marketing context. This is of course true, to prevent crimes, the Police needs to reach civilians and organization. Just like marketing teams want to reach (potential) customers. The contents and goals may be different but the type of work is highly similar.
Relation to the Definition of Done
Another thing to notice: some of the criteria mentioned above could be part of a Definition of Done. For instance: having to conform to rules & regulations. As mentioned before, I’m hoping to do a follow-up blog post exploring a non-IT Definition of Done with examples from my context.
Conclusion: It is not necessary to change our ideas of an Increment for Scrum in non-IT context
In my own context, I have yet to find a compelling reason to adapt the definition of the Scrum Increment to better suit the kind of work. I have collected insights by focussing on four main criteria that Scrum demands of the Increment, and subsequently providing two different examples from my own Police team context that show how it translates to non-IT work. I have also learned that I may need to coach a bit more on the understanding of the Increment and subsequently, the Definition of Done, so the Scrum Teams can try to move to a better ‘done’ state than we currently cover in our Sprints. As ‘done’ means ‘usable/releasable’ in Scrum, and currently by a long way, not all our work is releasable at the end of a Sprint. But that is for another blog.
Note: the teams are just ‘attempting Scrum’ for a few Sprints, so I look forward to the improvements Scrum will demand from us. I hope the team will agree and see the benefits this will deliver. Some of the things described above are not reality for us yet. We are working towards the Increment as I can see it fit above. If and when we have learnt more, I may revisit this post with additional insights.
More
- Want to know if Scrum could be right for your context? The right tool for the Job? explains how you can gauge whether Scrum or Kanban is better suited for your context
- This description of the Increment at Scrum.org provides a bit more as well as more references to dive deeper
- The Serious Scrum article on Definition of Done contains some good insights into the Increment and how it can support transparency
Note of thanks: I am deeply thankful for the ideas and suggestions of many awesome people, including input by fellow trainers at the recent Scrum.org Delft F2F meetup held at Prowareness. A great reminder we are all standing on the shoulders of giants.