Five months (and a bunch of Agile thoughts) later, its time to continue to address the challenges organizations have with Scrum.
In my last post on this subject, I focused on the Scrum Master role, the current certification model and the failure of people who are in supposed Agile change agent positions to really dig deep and own their craft. I got a bit of feedback from some people indicating I was a bit too harsh. I’m sorry if I offended anyone. The remainder of this post may also be offensive to some. Please proceed with caution.
This post focuses on the situation where the existing organizational culture not being a fit for Scrum (and Agile). The values of each subculture are not shared or complementary and the behaviors are at odds with each other.
Many organizations that want to “go” Agile (by way of Scrum for example) don’t realize that they are potentially embarking on a cultural change that the organization may not be prepared for. A lack of awareness and unpreparedness eventually causes conflict and failure. I’ll present (as examples) three Agile cultural values that are often at odds with the prevailing cultural values in many organizations.
Planners Plan, Doers Do
I’ve shared my thoughts on the role of the manager in knowledge work and human-based systems. You can check out all my posts on this here. Many (if not most) managers have been informally trained to be managers from the school of Taylorism with the belief that managers “plan” and the non-managers “do”. A manager is only successful if she or he is good at telling people exactly what they should do, how they should do it and ensuring it gets done.
Scrum teams are self-managed. It’s been my experience and observation that many organizations find themselves at odds with the concept of self-managed teams because it challenges the conventional role of a manager in their organization.
The organization has little need for Scrum Master’s who focus on helping establish self-organizing teams. Managers want someone who will answer to them and “drive the team to success”. But in order to have the moniker of an “Agile organization”, they label these individuals as Scrum Masters. It doesn’t take long for Scrum to implode in such environments.
Get Off My Lawn
Many organizations struggle with establishing cross-functional teams that work across functional silos. The development of products is often more than just a ‘tech org’ endeavor and yet I often hear people (in and outside of technology) suggest that Scrum (and Agile) is just for technology. As a result of this, silos are encouraged and reinforced. People spend hours debating roles and responsibilities and then developing RACI matrixes to govern their interactions. Working as a cross-functional team throughout the process of developing products simply doesn’t occur. Instead, work is handed off from department to department and complex processes are developed to manage these handoffs. If your organization is not committed to cross-functional teams and believes deeply in silos, Scrum has a little chance of helping the organization change.
It’s Just Complicated (Not Complex)
Many individuals in organizations will agree (on paper) that product development is inherently complex and yet their behaviors would indicate that they view software development as being a “complicated”. What’s the difference between complicated and complex? The answer to that is probably worthy of it’s own post however I will try to illustrate with simple examples.
A jigsaw puzzle of 1000 pieces is complicated. Even though it’s difficult and may take hours to finish, there is still only one outcome that indicates that we have solved the puzzle. With study we can determine the best way to solve the puzzle and possibly automate its solution. On the other hand, a soccer match is complex. There are many interactions that are occurring and multiple outcomes are possible.
Product development is complex. Scrum as a framework realizes this and has “rules” and events that are intended to guide work that is occurring in a complex system. Organizations that spend a lot of time creating plans and then attempt to follow them as closely as possible are treating product development as if it’s complicated. Organizations that focus primarily on efficiency (over effectiveness) are essentially considering the creation of products to be a predictable and repeatable process. Scrum will struggle in environments where this is the case.
These are just three examples of where the Scrum subculture could be in conflict with an organizations pre-existing subculture. I actually expect such conflicts to exist. The question is this: Is your organization ready to embark on a cultural change journey or is it wedded to its current culture? If there is no intention for meaningful change, then it’s very likely that there is nothing with Scrum. On the other hand, there may be something wrong with your organization. I’ll let you decide that.