Regularity and order with clear processes
An easy process to create more clarity in your teams.
When there is a chaotic work environment, most of the time there is a lack of clear processes. The big challenge is to recognize these challenges. In the past years, I met many teams struggling with unclarity and not knowing how to act on it. These teams started with implementing frameworks such as scrum, or they started stetting clear goals with Objective and Key Results. And nothing wrong with those frameworks, they just don’t solve the problems the teams encounter.
The real problem is mostly not having a clear process. While frameworks like Scrum give some boundaries, they just don’t tell how the work should be done. And that is the missing part most of the teams struggling with.
In this post, I tell you about a real life situation I had with a customer. I tell you a little about their background and what steps we take to help the team grow and achieve the results they had in mind. Let’s start at the beginning.
The implementation of a ticket system
With a strong background in software development - I was involved in software development for over 20 years - I have a strong connection with that branch. A software company was just started with the Scrum framework and encountered a problem: when customers mentioned bugs or unexpected behavior from the software, it took too long before those problems were solved.
The agile coach proposed a ticket system. Customers just have to fill in a form on the website, and the team got notified on their sprint backlog. This ensures the team to see those bugs right on the moment the customer sends them in!
But, there was no improvement for the customer. They still had to wait a long time before they got an answer. They still had to make a phone call to get a status update. Actually, the whole ticket system makes the customer experience worse. Less personal contact and still no answers.
The manager called me. How read a post about the SOPHIA framework and wanted to give it a try. “I can tell you everything about what happened, how we work and what is wrong”, he mentioned in the conversation. “I would like you to tell me what we have to do to solve this situation”.
I explained to him that solving the situation is only possible by the team itself. The ticket system was implemented by the management team, but the development team wasn’t involved. The result, they didn’t change to adapt to the ticket system. I proposed having a 2-hour workshop with the development team. “After that workshop, I know exactly what the real problem is, how to solve it and maybe even have created some solutions”
Familiar with the workshop format, the manger agreed.
One hour of amazement
We gathered in one of the office meeting rooms. After a short check-in, I asked the team to explain to me how they were working. Of course, they explained the whole Scrum framework in detail. From that moment, I knew the Agile coach did a fantastic job. The whole team knew everything about Scrum they had to know.
I asked them to draw the process on the whiteboard on the wall. Within 5 minutes, some discussing and laughter, the Scrum framework diagram was drawn on the whiteboard. Inclusive events, roles and artifacts.
I complemented the team and Agile coach for this great exercise and asked the team to zoom-in a little. “The Scrum framework is the ideal situation. But what happens when a customer finds a bug or something that is not following the specification? What happened when something needs to be fixed right now?”
One of the team members jumped in right away: “We stop working on what we are doing and start fixing it! If there is a fire, you should not wait to put it out!”
I asked the team to draw the process for the exception. A real simplification of the process arose on the whiteboard:
And yes, I know, this is really a simplification of a process. But to be honest, I was a little amazed they came this far! So I asked them some questions:
Who decides a bug is that important that it should be picked up right away?
What happened if that person decides that it is not that important?
What happened to the items you committed to for this sprint? What if you can't make the commitment?
Who is responsible to update the status to the customer?
When, and in what frequency, the customer is updated?
After I asked these questions, the room was filled with silence. Nobody seems to know these answers. Nobody seems to know who is accountable for certain actions.
One hour of solutions
In the second hour, we started to draw the new ‘bug process’. We started simple by simplifying the questions. For example: “Who decides a bug is that important that it should be picked up right away?” became “Is this bug important enough to pick up right away?”. This decoupled the process from the accountable persons.
We found a couple of decision points in our process flow. The last step we did in this workshop was defining roles for those decision makers.
At the end of this workshop, we had:
A clear visual of the ‘Bug process’
A clear list of decision points
A clear list with roles for accountability
I created a document of those input and presented it back to the manager. “There is only one thing we should do”, I told him, “give the team mandate to assign those roles to team members. And before you say yes, I want to make clear that this means the team member, with that role, is authorized to make the decisions.”
He nodded his head and authorized me to do another session with the team to assign the roles. After that session, the whole process, inclusive accountability and responsibility was clear.
The team started implementing the process and after 2 months the lead time of bugs decreased by almost 20%. But, most importantly, the customer satisfaction increased by over 30%! Besides that, the team became more productive. They have clear understanding of the work and process. That improves them at planning and gives them more rest to develop in peace.
Don’t overcomplicate
When you want to start with outlining your own processes, you probably start looking at Google. And yes, honestly, that is a great place to start. But … that also gives you an overload of possibilities. There are plenty of symbols you can use, different styles and different software. That’s why I give you the 4 most common and valuable symbols to start with. With these symbols, you can draw 95% of all processes.
The Oval
The oval symbol is used to draw the start and finish of your process. In that symbol, you can write something like “Start Bug Process”, “End Bug Process” or just "Start" and "Finish". This symbol shows the input and the output of the process.
The square
The square symbolizes a task or activity. Good to mention, we don’t mention people or tools when describing a task or activity. You can write something like “Notify customer”, but not “James notifies the customer” or “Notify customer by sending an e-mail”. You describe what happens, not how of by who it happens. We don't want tasks bound to people or technology that can change over time.
The diamond
A decision is represented by a diamond symbol. Within the diamond, you write the question to answer. In the case, we wrote “Is this bug important enough to pick up right away?”. You use one of the corners of the diamond as an entry, the other corners are the answers you can give. There is no maximum, beside more answers will add more complexity. On the other hand, there is a minimum of two answers. At least there is a “yes” and “no”.
The boxed square
The boxed square represents a sub-process. Looking at the case above, if someone decides that the bug isn’t relevant enough to pick up right away, there can be numerous steps to communicate with the customer. That process is too big, and gives too much noise, to place in the same sheet as the “Bug Process”. In that case, you use the boxed square symbol and write the name of the sub-process in it.
Like I said, don’t overcomplicate. Start with these four symbols, a whiteboard and some whiteboard markers. You don’t have to invest in expensive software to make a digital version of it. You can find these symbols in tools you already have like PowerPoint, Google Document or Canva.
In the end, It is way more important to discuss the process and responsibilities, than looking for the best tools and symbols to describe the process.
Want to learn more?
Subscribe to this Substack newsletter. I share content about organization improvement based on the SOPHIA framework. An easy to understand and implement framework based on simplicity and tools that just work.