Overcoming A Lack Of Commitment, Change Management & Team Work! This Might Surprise You!
The most significant weakness of process
improvement frameworks used before Scrum
was that: They mainly focused on self-serving
organizational demands of leadership.
Some of these demands are monitoring,
compliance, and predictability. There was no
focus on serving clients well and increasing
employee morale at all.
Thus members of software management teams
and various other internal and external stakeholders
attempted to have a fixed deadline for
software delivery projects and easily monitor the
progress of software engineering phases.
They penalized their people if something was
outside the planned track, and they hoped to
fix emerging issues before the scheduled date
of project completion.
Furthermore, independent silos realized entirely
separated software engineering phases. As an
example, the development team was completely
independent of a software testing (verification)
team. Most people who supposed to work for the
same business mission didn't even know each
other by their names.
Have you got a guess about the reason for this
silo-mentality in our organizations rather than
focus on business missions and professional
(business) maturity of employees?
The reason is simply the
matrix management .
Matrix management is an organizational management
and employee structure, and it has been in our businesses
since the 1970s. At first glance, the differentiating idea
behind a matrix organization or matrix management seems
to be smart.
The Leadership creates an organizational
structure by bringing together employees
with similar kinds of functional and technical
skill-sets into the same or at best neighbor
silos.
The Waterfall Project Delivery Model
in a Matrix Organization
Back in times, it was quite popular to see the so called
"Center of Competences" in our companies where each center of competence
represented an independent and autonomous silo.
One silo for C++ developers, another silo for
database administrators, and another entirely
separate quality assurance silo in oversees
and it goes on and on. Go and figure!
The biggest challenge with the matrix organizational
structure was that: To deliver a software
project without the scrum framework and scrum
masters, project managers had to borrow
employees from silos temporarily.
These employees did not even physically position
with their project teams, but they still located in
the rooms of their particular center of competences.
Up upon completion of projects, these temporary
project teams dissolved and project participants
moved on their next assignments to serve for
other projects.
Therefore, the targeted business values of these
ongoing software projects have never been the
utmost priority for these independent silos.
They tend to see their work as checkboxes
they ticked for one project over here and
another project over there.
Leadership and matrix organizational model
didn't teach them how professionals should
commit their business to improve the bottom
line, including sales, revenue, and profit.
A McKinsey Quarterly article written by McKinsey
& Company has also clearly illustrated this
illusion of cost optimization beyond the matrix organization
.
Gartner has estimated that organizations
worldwide have been yearly
spending 600 billion USD to recover their IT systems
from non-scheduled maintenance work and defects.
Now let's take a short moment to visualize
how the change management and impediment
handling of software projects played
out. How t hey pl ayed out i n a proj ect
configuration with the waterfall model, with the
matrix organization, and without the scrum
process.
Yes. You're right.
Management and employees treated change
management, impediment, and error handling as
if they're ill exceptions which shouldn't have
happened in the first place.
Therefore, changes in a software project have
been the synonym of delays. They usually
created a domino effect of cascading delays.
Teams required someone to blame and finger point
for defects and impediments.
Last, but not least, because silos did not have
a mechanism in place to process, fix, and
learn from their errors, they kept on repeating
the same mistakes.
Furthermore, they kept on
augmenting the amount of technical debt
while they passively attempted to deal with their problems.
Share It With Your Colleagues and Friends to Help Them Learn:
Overcoming A Lack Of Commitment, Change Management & Team Work! This Might Surprise You!
|
|
|
|
|
|
|
SCRUM INSTITUTE™
