frustration #2. Lack of Commitment, Change Management, and Working Together Disciples Among Different Teams

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

The Waterfall Project Delivery Model in a Matrix Organization

skillsets into the same or at best neighbor silos.

Back in times, it was quite popular to see the socalled "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 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'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 fingerpoint 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.