It's All Just A Little Bit of History Repeating...

The software industry fell into civil war. 

A technical firestorm had erupted when a long smoldering spark was fanned to flame by a comparatively unimpressive innovation.  Adversarial camps – Supporters and Deniers – were quick to form on opposite banks of the revolution.  Supporters made promises that sounded unrealistic and full of hype.  They assured us that this innovative approach would make our work cleaner, clearer, more accurate and more cost effective in the long run.  Deniers, on the other hand, painted it as merely a passing fad – hardly an "innovation" at all and really more a novelty that was appealing only for novelty's sake.  Supporters were cast as wild-eyed, gullible zealots by the Deniers while they were themselves accused of being stodgy, out of touch kermudgins and relics of a previous age.  I, being new to the industry at the time (nearly 20 years ago), vacillated between camps unsure where my fledgling loyalties should lay. 

Tempers flared as the status quo was challenged.  It was an entirely new way of approaching work that, if it were to succeed, meant re-evaluating everything: hierarchies, organizations, responsibilities, tools, processes – even roles, titles, positions might have to change if companies were to reap the benefits of the innovation. Worse yet in the eyes of some was the fact that seniority, established based on prowess with the Old Ways, could be lost if the New Ways did not come as easily. 

To many, change represented a grave threat. 

My company, which was a very large CAD/CAM organization with over 10,000 employees, was quickly convinced by the technical leaders steeped in the Old Ways that the innovation only represented bloat, slowdown, overhead and imprecision.  They raised the specter of project overruns and uncertain deliverables.  One closing argument I recall from a Denier was this:  

"We are not a research firm.  Leave that to Universities and think tanks.  We are an Engineering firm and need to build our solutions quickly and with proven approaches that have worked well for us since the company was founded.  After all, isn't it really all about just getting the work done?" 

Management was persuaded.

I arrived at work one day to find my keyboard (and all of the keyboards in the office) draped in a memo from the office of the Senior Vice President of Software Engineering.  Though it was passionless and brief, the point was clear:  anyone caught espousing, promoting or exploring the new approach would be immediately terminated without further warning. 

And so with that memo, C++ and Object Oriented  Programming were banned.

Now I won't go into the differences between C and C++ here – there are many well written articles and blogs available to you through Google on that subject – but what I find fascinating is the parallel to how Scrum has been treated as it enters the American market today.   

Years later, I recall reviewing a co-worker's first attempt at C++/OOP wherein he had created an object containing three methods, each essentially a C-style function. All variables were at global scope.  He instantiated the object, called the methods in sequence and let the object go out of scope.  He mused aloud as he stepped me through his code, "I don't see what all the hype is about.  It's just a different way to organize code and I don't see how it helps anybody.  But, oh well.  It works!"

Well… yes, and no.  He got the syntax but had totally missed the point!   He was so busy going through the motions that all he accomplished was creating a larger executable than he might have done with C.  His interest in learning OOP was minimal and his focused effort was dismal.  Because of that, his results were horrible.  No wonder he thought it was pointless!

When I am sitting through a meeting with a team that is still in this mode with Scrum adoption, I often think what it must have been like for the fellow who built the first bicycle in the world.  He must have spent many long hours crafting the machine only to climb aboard and immediately crash into something.  What made him keep picking that bicycle up, putting himself back on it and go crashing around until he got it right?

Much like C++, Scrum comes with a syntax:  Sprint, Product Owner, Backlog, Story Points and so on.  And just like with C++, it is so easy to get the syntax right but still miss the benefits altogether.  But unlike the poor chap with the first bicycle in the world, we have precedent on which to base our hope and studies that show us what will and will not work.

Standing with your team for fifteen minutes each morning will not improve your situation if you turn it into a project status meeting or a hang-out session. 

Having a Backlog populated with micro-managing tasks that are disjoint and have no business value attached will not improve your team's ability to deliver value to the company's bottom line. 

Getting yourself a Scrum Master will not change the dynamic if s/he is just the directive, controlling Manager of the team and continues the old behaviors in a new meeting.

For any of you who lived through that C-to-C++ transition with me, you'll recall that "ah HA!" moment when you suddenly realized that OOP, event driven, multi-threading development was fundamentally a new creature – as different as monkey and man.  You, too, found that only a small percentage of the neural pathways in your brain that worked for procedural coding still served you well after making the change.  The shift to Scrum is no less demanding, as we have to rewire our brains if we are going to succeed. 

As an Agile Coach, I get to see how many times people in crisis fail to the familiar and jeopardize all of the progress we've made.  It is sometimes disheartening but then I remember that changing minds is first a logical act, but then very much a physical one.  The brain literally has to rebuild itself to establish new behaviors, and that just takes time.

Many years ago, I found myself standing on the snowy slopes of a ski resort in California waiting for the start of my first snowboarding class.  The ruddy cheeked instructor blasted downhill into the waiting crescent of students, spraying us with snow as he ground to a standing halt.  His first words to us were these:

"How many surfers do we have in the group?"  No hands were raised. 

"How about skateboarders?"  Again, no one moved.  I started getting worried that I'd never get snowboarding if those skills were required.

"AWESOME!" he exclaimed.  "It's SO HARD to un-teach that stuff on the slopes!  But with no surfers or skaters, you guys are going to be awesome!  Follow me!"  

In no time, we were off on our first run.