English Russian

Departments are dead, long live services

In May 2013 my friend and colleague Vadichka and I opened a web studio. I built the websites and he sold them.

The problem was that what I built was complete crap, and Vadichka could not sell crap. We survived on bread and water for three years and shut down. I got priceless experience and went to work for somebody else. Vadichka got psychological trauma, and God bless him.

A couple of years later I ended up at Aventus and became a team lead. From the very start I felt something artificial about what was going on. When Vadichka, a couple of webmasters and I were surviving in a dying market, everything felt real. Here it was some kind of simulation of reality.

And here is the thing: out on the market we had to think about how to build a service, how to hit expectations on price and quality, how to care about clients. If you do not do that, the market simply eats you.

Inside a corporation it becomes unclear who your client even is. And it becomes even less clear whether the team is meeting expectations. Everyone just shows up at work and tries to be left alone.

Luckily, at the end of 2021 I got onto a Kanban method training, which is where I learned about an approach called...

THE SERVICE PARADIGM

An organisation is not a hierarchy of departments and divisions. From the point of view of the service paradigm, an organisation is a chain of dependent services.

It used to be "the accounting department", now it is "the bookkeeping service". It used to be "legal", now it is "the service of legal advice and representing the organisation in court". It used to be "the damn IT guys", now it is "the service with the damn IT guys".

A service has to design the protocol for dealing with it. Who can submit which requests to the service? When are they processed? How long do you wait for results?

A service sets expectations for its consumers about its throughput and lead time. All of it must be documented and put on public display.

If demand for the service goes up, the service has to do something about meeting that demand.

How the service gets its work done is its own business. How many people work on the orders, whether they work at full capacity, whether those people also take part in other services of the organisation — none of it matters to an outside observer. As long as the service keeps its promises and the cost of keeping it is acceptable, the service is allowed to carry on.

That already looks more like the way a market works. Cruel, but free of nonsense.

Rules of a service

Let us try to write the rules for the service "Development and support of the CRM Shmanus 3.0".

This is a free interpretation of the STATIK practice from the Kanban method. For a short introduction I recommend this booklet

Write the list of work types the service knows how to do

Work types (mostly) differ from each other by their process. If "New feature" needs a code review and "System defect" does not, that is a reason to split them. If the approach is the same, they can be merged into one type.

Work types must be the clients' own words. The type "A task for the frontend developer" does not come from the clients' world, they will never order that.

So, we have 3 types: New feature, System defect, Statistics export.

Describe the classes of service — how you pay attention to new requests

For example:

to the "Standard" class we react as soon as its turn comes, during working hours from 10:00 to 19:00;
to the "ASAP" class we react within 10 minutes, during working hours from 10:00 to 19:00;
to the "Single client issue" class we react within 10 minutes during working hours from 10:00 to 19:00, but at the performer's discretion the work can be pushed to the next day if the issue really is a one-off;
to the "Mass disaster" class we react the moment anyone on the team notices the request, no matter the day of the week or the time of night;
to the "Suite" class we react when somebody in the service has nothing to do, has a couple of minutes, and does not want to encourage their porn addiction.

A class of service is not a synonym for priority. Priority only says what is more important. A class of service describes more nuance.

Write down who gets to call the tune

For every intersection of request type and class of service, define who is allowed to place that order.

For example:

type System defect with class Mass disaster can be raised by anyone;
type New feature with priority Standard can be raised by messrs A, B and C;
type New feature with priority ASAP can be raised by the CEO only;
type Statistics export with class Mass disaster can be raised by nobody, because that is nonsense.

Make one single board of orders

Create one single kanban board with the orders, showing every work type and every class of service.

For inspiration I recommend the book Making Work Visible

This board is for the clients specifically. If the team members need more coordination tools (subtasks, releases, components), do that somewhere else. Do not load outside observers with details they do not need.

Mark where on the board the commitment point is and where the delivery point to the client is. Traditionally commitment happens when an order is pulled onto the board, and delivery happens in the second to last column, right before "Accepted". You are free to define any other points for yourself.

Make promises

Promises have to be made on two metrics: throughput and lead time.

Start with time. Measure how long every order takes from the commitment point to the delivery point. Take the fastest 80% of the orders and promise to deliver new orders no slower than the slowest one of those. For convenience use the lead time distribution chart.

Do this for every combination of work type and class of service. So that you can answer the question "How long will an order for a new feature take if we raise its class to ASAP?".

This metric is called a service level agreement, or SLA.

Now to throughput. Make sure the orders you have taken on do not sit unattended on your board. To do that, limit how many orders can be on the board at the same time using WIP limits.

Measure how many orders went through the service over, say, a month. That is how you set expectations about the amount of work your service can digest.

Be predictable

Do not forget to update the document with the rules and the promises regularly. Listen to what your clients need. Correct your promises if the statistics have changed.

The main requirement for a service inside an organisation is predictability. Only through predictability can all the services start working to one rhythm.