---

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 were supposed to work for the same business mission didn't even know each other by name.

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, neighboring silos.

The Waterfall Project Delivery Model in a Matrix Organization

Back then, 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 overseas 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 were not even physically located with their project teams; they remained in the rooms of their particular centers of competence.

Upon completion of projects, these temporary project teams dissolved and project participants moved on to their next assignments on 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 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 they played out in a project 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 were unwelcome 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 looked for someone to blame 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.