4.9.1 Introducing continuous processes reveals PD
Disconnected and incompatible processes:The introduction of processes like DevOps and BizDev was implemented because of a need to reduce the problem of disconnected activities and become more customer-driven. As written in an internal document, “Change is needed to better serve our customers. We need to change the way we work to ensure that we can serve our customers with what they want in a timely manner”. When traditionally separated processes become continuous, new processes replace the existing processes to connect planning, testing, and development activities. Disconnected processes are examples of synchronization debt and unsuitable processes not tailored to the purpose of the companies and the teams. Such debts emerge because of the need to deliver faster.
At the beginning of the study in Company E, business development and software development were separated, including the organizing principle that business developers prioritized what the software developers should deliver without involving them. Consequently, both the business and the development sides optimized their processes. However, running two different processes caused synchronization debt. Software development did not consistently deliver what the business side had expected, and the business side started projects that could not be developed from a technical viewpoint. Further, because the business developers were hard to reach, software developers seldom received fast feedback when they discovered that a feature or design needed to be changed, causing the time from identifying a feature to delivering the feature to take much longer than necessary.
Organizational changes: To mitigate the synchronization debt, the company decided to create agile teams with team members from both business and development (BizDev teams), including testers and user experience designers, to achieve a continuous planning and execution process.
We make decisions along the way, while we work on our tasks, when it is needed. If there is something under development, and an issue occurs, it happens that we deal with it informally by talking with the developers about solving it differently.”
Process unsuitability: However, the new working process and the different working cultures between the two groups introduced new process unsuitability. First, it quickly became evident that different roles had different needs in how they performed their tasks. For example, business developers appreciated a very open work area that allowed discussions and quick feedback. Software developers, in contrast, wanted to have designated seats because their desktop computers contained specific hardware and multiple monitors. In addition, they needed a quiet working zone and wanted to protect their time to focus on technical programming tasks. Even though the BizDev set-up increased the speed of feedback and clarifications, frequent interruptions made the developers’ day fragmented, and the developers perceived that their personal productivity was reduced. These differences in cultural factors, interests, and a lack of follow-up checks caused PD.
Further, as the teams were large (13-20 people), and consisted of people with different roles and tasks, some of the meetings (e.g., the standup meeting) did not give value, as what people discussed was not relevant to everyone. This meeting set-up caused reduced motivation because the meeting attendees felt that the time spent in the meetings was a waste of time. To mitigate the problem of having too large teams and one continuous process, the teams were later split into sub-teams with dedicated responsibilities.
Redesigning processes: However, they still had handover problems between testers and developers. The developers wrote the code, and the testers tested the code. This process was suboptimal because it caused delays and misunderstandings (classical problems). To mitigate this PD, a new process was introduced. They introduced a pull request (PR) approach so that the developers could assign people to check the code written, which made it easier to onboard people. Eventually, they removed the tester role and gave everyone responsibility for quality.