Why You Suck at Scrum: The Organization
This is the first in a series describing why organizations actually fail to make any real change when attempting to adopt Agile and Scrum, and upon reflection after reading them, most people will acknowledge that these are at the root of the failures, and ones that they have seen personally.
The Organization as a whole thinks Agile & Scrum are isolated to project management delivery frameworks
When organizations make the decision to implement an Agile framework, they rarely understand the breadth & depth of what that truly means. They understand how they currently deliver projects, and they understand the pain points they have while working within those frameworks.
Pain points such as:
· Inability to understand the full scope of a project
· Inability to understand how long it will take to achieve the completion of the project
· Inability to accurately forecast the funding needed to complete the project
These pain points typically lead to frustration at various levels of the organization:
· Leaderships frustration with continuously changing timelines
· Leaderships frustration with continued asks for additional funding as timelines are extended
· Leaderships frustration with the project team’s inability to deliver accurate forecasts
· Project team’s frustration with being asked to deliver full and complete requirements when they have the least concrete information available to them
· Project team’s frustration with being asked to deliver full and complete estimates to deliver said ‘full & complete’ requirements, and having those estimates used against them by being turned into hard commitments
· Project team’s frustration with being beaten down when they acquire new & relevant information during the project that will require changes in scope & timeline, and the heavy process required to justify & get approval for those changes
The organization that is looking for a new shiny way to deliver projects and thinks that these pain points and frustrations will be remedied by simply swapping from one delivery method to another, with no other effort or change within the organization as a whole, will completely & utterly fail, while blaming the new shiny framework for their inability to solve the real problems that are at the root of those frustrations.
These organizations don’t understand that what they need is not a better way to deliver projects, but rather a better way to deliver products. By missing this they start out for the wrong reasons, and end up not solving the problem that they should have been solving for in the first place.
The Organization thinks Agile & Scrum are changes in the technology delivery area only
When there is no understanding of the breadth & depth of real change that is required, many organizations think the new shiny framework is relegated to the technology teams and project management offices that are delivering for them. They are under the delusion that the problems they need to solve live solely within one area of their organization.
Organizations that think in this way typically have large silos built that isolate teams from each other, further compounding the issues that they are trying so desperately to correct.
The Organization makes no real organizational change
If these organizations think the issues are with one particular group or process, they completely overlook the opportunities to make real change.
In order for the organization to have the ability to pivot, the full value chain needs to be aligned together. To do this there typically is significant change needed to how the group is currently organized.
But this type of change is difficult, and sometimes costly in the short term, and therefore pushed aside in hopes that the minimal change being made in the delivery area will be sufficient to achieve the reduction in the pain points they originally set out to correct.
The Organization doesn’t understand the need to change the organization in a way that allows them to pivot quickly & in a cost-effective manner
In order to be in a position to change direction at a product level when it is clear that this is what is needed, the entire organization needs to be structured in a way that allows for fully empowered Product Owners, meaning they are trusted and allowed to factor in new information and make the necessary changes without a full and complicated process of approvals by people so far removed from the work being done to do so.
To do this effectively HR needs to be involved, and they need to understand what those changes need to be and why they are necessary.
Finance also needs to be involved, to fully understand the need to change funding models that can look significantly different than their current project funding models.
The Organization does not understand how to fill the new roles, or why they actually exist
Utterly poor job requirements that show how unclear the organization is about what they are trying to achieve with the new role they are hiring for. If you actually get what you ask for, this will be a factor into why you will not succeed in making the meaningful change you were hoping for.
Job requirements that mix multiple roles into one are sadly too often an occurrence. These are typically filled with smatterings of key buzzwords used when describing Agile and or Scrum, yet with no coherent logical alignment to any one actual role.
Individuals that respond to these posts often compound the issue as they either don’t understand the role they are applying for, or worse yet, they do, and enable the misguided behavior by stating that yes indeed, they can and know how to do everything you’ve listed in the job requirements, citing the many certifications they hold on all topics.
These individuals will ultimately fail the organization as they are taking on a role that is set up for failure from the start, as these roles are not meant to be combined for many reasons that the HR team does not understand or don’t feel the need to understand. Their measure of success is their ability to fill a seat with all of the boxes checked provided to them. They are not measured on the success or failure of the individual’s impact on the organization, largely in part because they are insulated by their silo, encouraged to stay in their lane, and move on to the next seat that needs to be filled.
This is just a brief look into some of the main reasons organizations fail when adopting Agile and Scrum, there are many more out there.
Up next — Why You Suck at Scrum: Leadership
