Billy Goat

BillyGoat.jpg

I’ve taken a year off from writing this blog in order to spend time attending and contributing to numerous conferences around the world.  In that time I’ve heard a lot of disturbing things about Scrum.  It’s time to write again.  

Do you remember the first time you bought a piece of Ikea furniture like the Billy bookcase?  You brought it home, looked at the front of the instruction book and thought, “It’s a bookcase, how hard can it be?”  You then started to build the bookcase.  Along the way you realized you’d done something in the wrong order and had to undo and repeat some steps.  Occasionally you thought ‘that seems stupid’.  What seemed like it should have been obvious, wasn’t.  That didn’t mean it wasn’t simple and correct; it just meant you didn’t fully understand holistically how all the pieces were supposed to fit together.  If you’re experienced at this sort of thing, a brief review of the instructions can provide you with a view into the mindset of the designers on how to build the bookcase and you proceed with ease.  At worst, following the instructions methodically one by one usually provides you with a recipe to get your desired result, even if it takes an excruciatingly long time.

If you’re experienced at this sort of thing

Over the years as a coach, I’ve written about and worked with the Dreyfus Skills Acquisition model.  This 5 stage model of learning describes that the way to become experienced at this sort of thing is to, each time, follow the instructions until you start to recognize patterns and understand how these types of designs fit together.  With significant repetition you start to be able to look at something foreign and understand what the ‘aspects’ are … the things you should pay attention to in order to grasp an understanding of the whole.  Eventually you get to a place where that grasp comes naturally enough that you can also start to see improvements to the design.  Finally all of this becomes intuitive.  Sometimes this is also referred to in the context of Shu-Ha-Ri.

In the realm of agility, it appears there are many who are not experienced at this sort of thing.  This should not be a surprise.  Working in an iterative/incremental and inspecting/adapting fashion is relatively new to the industry and is significantly antithetical to most of the approaches preceding agility.  And of course, practice takes time.  Did I forget to mention that, according to the Dreyfus model, you can’t skip stages in the learning process?  From the Dreyfus brothers’ original paper: “...avoid the temptation to introduce intricate and sophisticated aids which, although they might improve performance at a particular level, would impede advancement to a higher stage or even encourage regression to a lower one.”

So with all this in mind, I am continually troubled to read and hear about how Scrum doesn’t work.  Simply do a search for ‘agile doesn’t work’ or ‘Scrum doesn’t work’ to see what I mean.  There are countless articles and blog posts on this topic.  I’ve overheard and/or participated in similar conversations.   I’ve even been involved in conversations with self-professed agile pioneers and authors of books on agility who have bashed Scrum unabashedly.  Invariably, in my opinion, the arguments in these writings and conversations have occurred as a result of one or more patterns:

  • the core nature of agility is misunderstood

  • how the Scrum framework fits together and is intended to function is misunderstood leading to ‘Scrum-but’ or worse, ‘Dark Scrum’.

  • people and organizations aren’t prepared to make the changes necessary to truly experiment (including change their development and testing skills)

What leads to these misunderstandings?  I believe it is a result of people and organizations skipping stages in the Dreyfus model;  specifically, not focusing on the basics first until they grasp an understanding of how the Scrum framework functions.

We don’t magically know how to ski or fly a plane.  These are both complex activities requiring a learning process involving inspection and adaptation.  Why do we expect to be able to learn how to effectively use the Scrum framework without practice and practice of some basic rules to start?  My opinion of what those basics are has changed over the last 10 years, but the need to practice the basics has not.   

I can think of three main reasons why people and organizations don’t practice the basics.  The first is that Scrum is deceptively simple, just like the bookcase, and it is tempting to assume you intuitively understand it holistically and therefore can skip the basics.  The second is that it is HARD to do well, and often requires a shift in skills and culture.  The third reason is that there has been an overemphasis by the community (mea culpa) on an agile mindset over mechanics; a balance is required.

Ron Jeffries has written at length about what he coined as ‘Dark Scrum’.  It is the embodiment of Scrum practiced without its original intent.  It is the version of Scrum that far too many people know.  Scrum, as intended, requires culture and skills transformations that organizations all too often are just not willing to make.  For instance, the need for XP development practices (or something similar), becomes obvious if one actually follows the Scrum framework’s requirement to regularly deliver a potentially usable and releasable increment of functionality that meets a Definition of Done.  All too often people and organizations are either unwilling or not enabled to learn new techniques in their core skills. 

There are many ways to BE agile; Scrum is only one of them.  For solving complex problems, Scrum works. It works because it is so simple.  It works because it is a framework, not a recipe.  It works because, by design, it is not a 'silver bullet'.  It doesn’t actually fix anything in and of itself; it only presents the regular opportunity to do so.  Scrum as it is intended, at worst, simply exposes all the dysfunction in an organization that prevents that organization from reaching its goals.  At best, Scrum provides a framework to deliver a continuous flow of value in a sustainable way.

Regardless of where you and your organization are in your agile journey, you won’t get to where you want to be without intentional practice in activities and domains with which you are unfamiliar.  It’s a never ending journey of learning.

So rather than have people decry “Scrum doesn’t work”, I’d much rather hear those people say “We were unwilling to learn.”

 
Previous
Previous

Behavioural Economics: Lessons in Leadership

Next
Next

Clash of Cultures