"A drifter discovers a pair of sunglasses that allow him to wake up to the fact that aliens have taken over the Earth." If this sounds like the story of a low-budget horror film, you might have seen too many of them.
I saw "They Live" as a kid and the fact that I still remember this movie, almost 25 years later, is astonishing. The storyline was quite original at the time - wearing a special pair of sunglasses allowed the main character to see aliens who otherwise looked like normal humans.
This utterly unimportant piece of information popped up in my head while talking to Teodora Bozheva (co-author of the Kanban Maturity Model) about the Service Orientation Agenda of Kanban. I was challenging some of the Kanban training materials as there was no sufficient guidance on how to identify the so-called services in a given organization. The training material just says, "Identify services in your organization and then do XYZ...". But how do you go about that?
To many of you, this might be too obvious of a question but it wasn't for me. Maybe my brain is damaged by the lines of code I've written in the past because I see everything as a service. The things that we now call REST APIs, the waiter in the restaurant, the review that this article is going to go through, getting my car fixed - it's all a service of some sort.
When everything is a service, it's kind of hard to see where one starts and where the other ends.
Boy, I wish I had a pair of glasses that help me see the right services, just as in the movie...
After reading dozens of blog posts and watching the same amount of conference presentations, I realized there was no clear answer to my question. I had to get to it empirically through observation and analysis. But first, let's explore the WHY a bit.
Why Are Types of Services Important?
Maybe you've heard about the API mandate in Amazon. Some years back, Jeff Bezos sent this memo to the entire company:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of inter-process communication allowed.
- It doesn't matter what technology you use.
- All service interfaces, without exception, must be designed from the ground up to be externalize-able.
- Anyone who doesn't do this will be fired. Thank you; have a nice day!
Such a sweet guy, isn't he? Bezos might not be the most charismatic CEO to work for but he knows how to run a company. He saw the service orientation need 10+ years ago and required that all development teams communicate via services.
Kanban takes the same idea but applies it to knowledge work, instead of software. When you think about it, the benefits in both cases are pretty similar:
| Benefits of Amazon's API Mandate | Benefits of Kanban's Service Orientation |
|---|---|
| Everything is a service, making it easy to exchange information between IT systems. | Everything is a service, making it easy to exchange information between teams. |
| The internals of the system are abstracted by an API with backward compatibility. | The internals of the system are abstracted by formal service requests with certain SLA |
| The architecture is distributed, making it easier to scale and maintain | The teams are distributed, making complex projects easier to execute due to the lack of functional silos |
| Information flows whenever and wherever needed | Information flows whenever and wherever needed |
I hope this explains why I was so obsessed with answering the question, "How to identify services on a Kanban board?". I wanted to get to these benefits as effectively as possible and also wanted to teach others how to do it. So, let's get back to my empirical analysis, which had to find the easiest way to do so.
The Analysis
The obvious place to search was our company - Businessmap. It was an easy pick as we are a 100% Kanban company, I know all the services we provide (both internal and external), plus I had all the data at my fingertips. I thought that there must be one thing that predominantly speaks about the presence of a given service.
After reviewing a few hundred cards, there were a few properties of the cards that could be used as indicators for existing services:
- Class of service
- Priority of work
- Type of work
Class of Service
This was one of the obvious candidates. The term "Classes of service" even has the word "service' in it. A good example seems to be boarding a plane. Priority boarding could be a viable service, and standard boarding could be another.
However, I discarded this idea, as I concluded that it was the very boarding that represented the service. The different Kanban classes of service existed to make the process smoother and more predictable (for some), but in the end, the service was the boarding itself.
Priority of Work
This one got discarded fairly quickly, as it's more or less a subset of the previous property.
Type of Work
Bull's eye! All work types that I found to be used were a pretty good indicator that there was an underlying service, which was neither too small nor too big. Sample work types would be:
- Technical feature
- Customer feature
- Support request
- Sales quotation
- Case study
- Bug
- Blog article
- SEO analysis
- Etc.
With this not-so-profound observation at hand, I've concluded that the work type and the underlying service have a one-to-one relation. I.e. each service is responsible for producing one type of work.
This means that we have the following types of Kanban services: a "feature development service", "bug fixing service", a "blog writing service", a "support handling service", and so on.
It's one of those things that seem so obvious once you've figured it out but it took me a while. Actually, the fact that the explanation is so simple is a huge success, as that was the original goal of my mini-quest - to figure out how to identify services easily.
Satisfied with the discovery of the century, I thought my task was done. However, it's never that simple. There were two questions that were still occupying my mind:
- What if the work type is defined in a way that no customer value is generated?
- What if the work type represents a very small part of the actual work?
These two questions led to the extension of my "service discovery framework". I had to add two guiding policies that help us along the way.
Guiding Policies to Define Services Types in Kanban
The first guiding policy is "Take the customer view" and the second one is "Minimize handoffs". I presume there may be others but I've not yet found the practical need to add them.
1. Take the Customer's View
This policy means that when we define the types of work and the corresponding measures, we need to come from the perspective of our customers. A good type would be something that the customer is willing to pay for.
To put that into perspective, you better measure how much time the car spends in the service instead of focusing on each individual part that’s being replaced. Of course, it’s a good idea to have metrics for the individual sub-services, but what we should care about the most is the whole.
With that said, we should be striving to define our internal services to match and support the customer-facing services as much as possible. Taking the customer view first is a measure that won’t let us define services and work types that are too fragmented.
2. Minimize Handoffs
This policy can be looked at as another aspect of the customer view described above. The core idea is that you organize your services for the convenience of the customer, not just for efficiency. On top of better customer satisfaction, eliminating the handoffs is likely to save you time and resources too.
The first example that comes to mind is visiting the bank to submit payment. First, you need to work with the clerk at his/her desk, then you need to go to the cashier and actually make the payment. In this example, the work types are “form submission” and “payment,” but I wish there was just one “money transfer” that combines the former two.
The process experts at the bank probably know this and have made a conscious decision to decouple the form submission from the payment step but as a customer, I only see an unnecessary handoff, which wastes my time and probably time for the workers at the bank.
In Conclusion
Exploring the service orientation agenda of Kanban leads to the conclusion that there are similarities between an IT network and a network of connected Kanban systems.
To identify a service on your existing Kanban board, look for the work types represented by the Kanban cards. Most likely, there's an existing service in the background which is worth measuring and continuously improving.
When defining or improving the service architecture, always take the customer's view first and try to eliminate as many of the handoffs as possible.
Dimitar Karaivanov
CEO and Co-founder of Businessmap
Dimitar is a lean thinker and a Kanban practitioner with a solid background in the areas of software development and process improvement. He is passionate about achieving extreme performance at scale and applying Lean/Agile principles outside IT.
