Scrum Is Easy. People Are Hard.

I often compare Scrum to the frame of a house.  We can look at the frame to know the size and shape of our rooms and how the house joins together.  However, it’s up to us to figure out what color to paint the walls and where to place the couch.  The saying goes, “Scrum is easy to understand but difficult to master.”  I agree, but I prefer a different slant:

Scrum is easy. People are hard.

But why?  How can the Scrum Guide explain Scrum in 17 pages, but when it comes to its implementation, it can sometimes feel like herding cats?  Let’s talk about that today.

Rational Or Not, Here I Come

While working on my MBA, I remember sitting in a portfolio management class.  My professor told us a story about how a chimpanzee picked better stocks than the world’s highest paid money managers.  That couldn’t be right.  Humans are rational, and that should be doubly true when our money is at stake.  Shouldn’t these money managers be experts in understanding human rationality and apply it to picking stocks that return better than the market?  It turns out I was wrong.  We humans aren’t nearly as rational as we pretend to be, and I’ve since learned to provide latitude for irrationality that inevitably arises from the fear of organizational change.  While a bit harsh, I mostly agree with Will Smith:

Human beings are not creatures of logic; we are creatures of emotions.  And we do not care what’s true.  We care how it feels.

Simplicity Is Rarely Simple

Complex problems are rarely solved by complex solutions.  It’s often one small, simple solution after another that succeeds.  However, it’s easy to lose sight of simplicity when the environment or issue is chock-full of nuisance and noise.  Learn to explain the solution in two sentences or less.  If that’s impossible, keep working.  Finally, it’s unnecessary to create solutions that accounts for everything.  Have a vision of what perfect looks like, account only for the variables that matter most, tweak once implemented and until satisfied, and manage the exceptions through conversation and collaboration.

Value Values

Take a moment and enumerate all Scrum ceremonies and artifacts. For many of us, it won’t be hard; we talk about them almost daily.  Now take another moment.  What are the Scrum values?  There’s five.  Did you remember them all?  I’d imagine many didn’t.  (By the way, here’s those values.)  Many team members want to be left undisturbed and don’t wish to collaborate with the team. Do these members value openness?  What do they value more?  Other teams deal with sprints that frequently get blown up by interruptions and distractions.  Does the organization value focus?  What does it value more?  It may be time to sit down with those around us to understand what is valued and why.

A failed Scrum adoption can often be traced back to a misalignment of values between team, management, and Scrum.

Humans Are Not Created Equally

Let’s take the term “best practice.” It insinuates that a person is a cog and can be exchanged for another.  We know this assumption is wrong, yet we continue to operate within this and other Tayloristic constructs.  Additionally, “best” assumes there’s no better way making continuous improvement pointless.  This is also wrong, and it is in stark contrast with our agile mindset where good enough never is.  As Cynefin tells us, Scrum does not operate in the obvious domain so abandon the term best practice and replace it with good or emergent practice.  We should allow teams to find their own way with our guidance.   We should encourage teams to experiment with what has worked for others and determine if it works for them.  However, we should never impose our solutions on others.  Allow them to succeed or fail based in the merit of their own ideas and actions.  If we don’t, we rob them of the opportunity to learn from their mistakes.

The Cost of Fighting Inertia

The system within an organization is often unkind to Scrum adoptions.  For example, where Scrum is risk absorbent, an organization is often risk adverse.  Put differently, organization wish to minimize risk while agilists wish to fail in small, yet substantial, ways in the spirit of learning about themselves and their customers.   Just as traditional organizations feel planning gives them control over their future (which it doesn’t), these same organizations believe avoiding risk creates a better, more resilient company.

But back to the system.  How does the organization reward what it values?  What kinds of themes are present on employees’ performance reviews?  Consider diagramming and discussing parts of the system to have a clearer view of where it fits together and how it can be influenced.  After all, it was Deming who teaches us a powerful lesson:

A bad system will beat a good person every time.

Much more comes to mind on this topic, but I’ll stop here for today.  Also, I’d like to give a special thanks to the people in the Hands-On Agile slack channel for brainstorming this topic with me.  What do you think?  Do you find the human element of Scrum easy?  Tell us how and why in the comments below.