Business People and Engineers. Part 2: Workflow
In the second part of this cycle, we will check workflow-related problems and several ways to deal with them. We will also review the best practices that help minimize these problems' impact in the long-term perspective.
Stability vs. Flexibility
Understanding the problem in workflow requires understanding the difference in points of view and approaches of both sides.
A typical engineer prefers simple, reliable, and stable solutions. As a consequence, he expects that workflow has to serve to maintain these principles. An engineer follows them in the workflow as well — for example, he will implement the simplest business process to save some time for other activities. He also assumes that others have similar ideas in mind and have to agree with his point of view and suggestions.
A typical business person has a very different approach. He works with organizational, financial, and customer-related problems, and knows that these areas often have no strict rules. According to him, the workflow has to be very flexible, easily adjusted to new cases, and bring results using a minimum amount of time and money. This business person knows that complicated problems rarely can be solved using simple solutions. He agrees with a certain level of complexity if it solves the issue.
It may look like these two sides have different ways to solve issues — engineers prefer stability, while business people prefer flexibility. However, they usually have a common ground in many areas, can rely on the other side's expertise if they do not have enough experience, and can work together to find a solution. Such an approach is essential to solve any problem.
Real-life Workflow
When a person is designing a workflow, it usually represents an understanding of this specific person's business processes. However, the workflow is used by many people with a different understanding of business and other demands, so workflow often has to be adjusted to match real-life scenarios. If an engineer wants to change the workflow, he usually prefers to simplify it and make it more stable. If a business person wants to do the same, he usually makes it more flexible, i.e., complicated. How to solve this conflict?
Real-life workflow has to fully or partially match both criteria. It is hard to make a simple and flexible workflow, so most of the time, it is something in between. The good idea is to start from a workflow that covers all the scenarios with maximum flexibility —a business person can do that. Then simplify it by applying KISS and YAGNI principles — an engineer can do that. Finally need to discuss together use cases that were simplified or removed. This three-steps iterative development allows building a workflow that is relatively simple and covers all main scenarios. Let us call it a passive phase of workflow development.
After the workflow is completed, a team needs to test in real life. It needs to make sure that people are using it properly so that a small workshop may help here. As usual, company results and team feedback will show all pros and cons. They also indicate what to improve should in the future. It is crucial to mention which scenarios are used more often to continue their development and dead ends that nobody uses. Let us call it an active phase of workflow development.
After a team has collected enough results and feedback from all users and participants, it has to repeat both passive and active phases of workflow development to improve and test it in real life. It may happen regularly (e.g., once a year), or be performed on-demand when some new scenario appears. Using such an approach, a team can build a reliable workflow that matches all the needs and continuously improve it.
How To Prevent Problems
The best way to prevent any problem is to think ahead and take action in advance. Workflow problems (both technical and business-related) are no exception.
To identify problems, a team may have regular status update meetings — e.g., once a week or once a month. This meeting can use a retrospective format — i.e., every team member should describe what he likes about the workflow, what the issues were, and what he would improve. At the end of the meeting, a team has to collect this feedback, analyze it, and decide what they need to change in a workflow. A team may split issues into two groups — technical and business-related — and then ask appropriate people to work on solutions.
The more flexible and proactive team, the easier and faster it is to discover a problem and implemented a solution. The early discovery helps to understand when the problem appears, how it interferes with a regular flow, and the possible consequences. The early reaction allows a team to quickly find possible solutions, adjust workflow on the fly to test them, and then pick the best possible scenario.
Finally, a team has to define and track metrics that tell how good each specific workflow is. It has to include both business and technical data to show a full picture of what is going on inside a company. This way, a team may evaluate each change in a long-term perspective, analyze the consequences, and establish internal workflow best practices.
The next chapter will show several real-life scenarios and examples of interaction between business people and engineers to see how it can be improved.