(UN)FITNESS PARADOX: Why Scrum and LeSS May Not Fit Your Organization?

Since the early 19th century, people have been using an idiomatic expression: “you can’t fit a square peg in a round hole“.
What it means, essentially and metaphorically, is that something or someone is a misfit in a particular environment, situation, or role.
For example, if a person describes himself as a ‘square peg’ at a given company, it means that he does not fit there culturally, mindset- or skill-wise, or in any other way.

In the era of adaptive (agile) product development, we frequently hear people, and companies, referring to Scrum and Large Scale Scrum (LeSS), as frameworks that don’t quite fit organizational structure, established internal dynamics and senior executives’ needs.

We hear various arguments about this:

  • Prescriptiveness and rigidity of rules
  • Lack of business engagement
  • Inability of developers to self organize and self-manage
  • Scarcity of good talent and skill set
  • High time demand for sprint events that leaves not enough time for development
  • A product owner, not having enough time to spend with developers
  • A scrum master, not able to justify why his/her is critical and has to be a full-time
  • Sprints, being too short to produce anything shippable
  • Challenges with dependencies management, across many teams
  • Lack of comprehensive documentation and reporting

The actual list is much longer, and what’s the above is not conclusive.

So, it seems that despite the fact that Scrum and Large Scale Scrum (LeSS) have been defined and introduced more than a few decades ago, as minimally prescriptive, light-weight organizational design frameworks, they still seem to be challenging to adopt, by many companies.

Essentially, both Scrum and LeSS, are considered by many companies, as two square pegs. 

What is ironic is that there are other frameworks that, though much heavier and with significantly more procedural, organizational and other types of complexities, are much wider implemented by companies (of course, with genuine “help” of large consultancies).

What causes this (UN)FITNESS PARADOX?

It appears that those simple, nimble, lightweight organizational design frameworks, such as Scrum and LeSS, actually, are not as easy to implement, as they may seem.  However, the main reason why they are difficult to use is NOT because they are too demanding and ask for too much, in terms of new skills, capabilities, processes or tools, etc.  Just to be fair, Scrum and LeSS do expect people (e.g. for example developers), with significantly higher than average, technical skill-set, business knowledge and overall acumen) but this is not the most taxing requirement on companies, especially big ones, where it shouldn’t be that difficult to search for and find the best of the best people, and put them together, into types of teams that Scrum and LeSS would expect.

It seems that a much bigger challenge is to justify to a company, and more specifically to senior executives, what to do with so many other people that may not necessarily be needed, by Scrum and LeSS.   It is not uncommon to hear, especially from a middle management, that Scrum and LeSS are not accommodating enough for many traditional roles.  Ironically, from a stand-point of what is best for a company, it is a bit odd to hear, as it seems that with this approach we locally optimize for roles, not for a greater success (e.g. company).   Larman’s Laws (1,2, and 3) of Organizational Behavior explain why.

Now, it’s important to clarify that Scrum and LeSS implementations are not meant to be broad & shallow, bombastic installations that involve everyone at a company, at once and fast.  On contrary, they are deep & narrow, methodical, and very thoughtful implementations that make take months/years, and they are usually done by using a parallel organization approach. (Note: for smaller companies a LeSS implementation could be done at once.  However a significant amount of preparations that includes education of executive leadership would be still required).  Therefore, should there be any traditional roles that do not need to be utilized in Scrum or LeSS product group, they could find a place to go, elsewhere, within an organization, where their skillset could be better used.

After years of observing organizational attempts to go through agile transformations, it has become obvious that for many organizations, it is more acceptable to do something on a huge scale that is marginally beneficial, very expensive and risky (many-many people are involved) but much less disruptive, then something that could be of a greater potential benefit, significantly cheaper (nothing is free) and less risky (fewer people are involved), but more disruptive.

Scrum and LeSS, because of their “square” form, do not fit organizational “round holes” well,  even though a number of holes that would be required to properly implement them would significantly lower.

This illustration also explains what tips the scale of Economics of Agile Transformation towards less disruptive, and more “this is how we have been always doing things around here” approaches.  Sadly but ironically, majority of companies are willing to pay a lot for almost guaranteed failures (because, this is more customary), then a little for disruptive innovations.

Today, very few companies seem to embrace innovative disruptions and this explains their complacency to try better ways of working.   The future impact of AI may dramatically change an organizational landscape and, eventually, the Law of Survival of The Fittest (and most resilient) will prevail.

Interesting and relevant video from MJ: Why “Scrum” Isn’t Making Your Organization Agile: Harmful Misconceptions About Product Owner Role

 

Leave a Comment

Please help us fight spam. Lets make sure you are not a robot !!!