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.