Change is scary.
Uncertainty is... well... uncertain.
Dealing with the human and emotional reactions to change is the hardest part of implementing Scrum effectively. Especially in an established organization where people already have established behaviors, expectations and domains, these changes can feel overwhelming, frustrating, inefficient or, in some extreme cases, even insulting.
"The good of the many outweighs the good of the one," a famous Vulcan said (hey, I made it this far without a Star Trek reference... it was tough!). In general, most of us agree with that most of the time. But in corporations, our ability to apply this bit of wisdom is often limited. Whether based on fear, politics or a loyalty to "the way things have always been", this kind of rigidity coming from the upper echelons of a company usually foretells the end of its growth phase and the beginning of its decline. But, with Scrum specifically, the multiplicity of concerns are generally not from the Executives, who are sold on the ability to achieve hyper productivity. It more frequently comes from people at the mid- to lower-layers of the company.
People who have built their careers around being superheroes are suddenly asked to become team players. Managers are turned into servants -- an easy transition for some, but a very difficult one for those who are more authoritarian. The familiar tools are usually judged inadequate or counter-productive for an effective implementation of Scrum, and that can frustrate the career plans of those who have spent years amassing skills and certifications with those tools. When a company stops communicating in the old language of hours, projects, assignments and the "QA cycle", formerly composed professionals can feel adrift, bored or demoted.
A person's reaction to change depends in large part on their general outlook on life. I was once chatting with a fellow -- sort of an Eeyore kind of guy, if you know what I mean -- about the changes that come with a Scrum adoption. "If nothing changes," I said enthusiastically, "how do you expect anything to ever get better?" He turned to me, completely stone-faced, and said, "I don't expect them to get better. I just don't expect them to get any worse either." It's a fair concern.
When you try new things, the likelihood of failure increases. Suddenly, people are broken out of their established patterns and are asked to engage the company's business in a brand new way. I was recently told by a Manager that, before Scrum, a certain employee had been happy to sit idle in his cube for days on end without uttering a word. Those kind of people don't do very well in an effective Scrum company. Scrum will simultaneously add work to the plates of those who have been coasting while taking away the busy work from those who believed that simply being busy creates value. Being busy is great, but only if you're busy heading in the direction identified by the company -- and most busy-work workers aren't.
But for every naysayer or Eeyore you've got in your company, you'll have 10 people who are enthusiastic, open-minded and embracing the positive changes they see Scrum bring. They're just not usually as vocal as the people who feel that they are suddenly engaged in a fight for their very careers, and that's a shame. Almost all of the employees in an established company have a good and purposeful home under Scrum but many close their ears after the briefest of overviews. The chief blessing of Scrum can also be a curse -- its simplicity.
A description of Scrum comes in twelve bullet points: Three Roles, Three Artifacts, Three Ceremonies and Three Best Practices. But that's just a description. A real understanding of Scrum comes from a deeper study of self-organization, emergent behaviors and human nature. People who scan a book and develop an opinion or an implementation are likely to leave out some of the most fundamentally powerful components of Scrum simply because they are uncomfortable to implement.
There are a few truths that sound blasphemous to most Engineering minds. For example:
- To generate more value, write less code.
- Multitasking is value embezzlement.
- Implement at least 80% of your Sprint Backlog each Sprint, but never implement more than 40% of your product requirements in any given Sprint.
Compromise is not always a virtue -- especially when the compromise is between a few noisy people clinging to the old methodologies, and an energized plurality willing and eager to make the quantum leap.
