How Rigid is Scrum?

Don't get me wrong, yes scrum is flawed... :) For example Kanban is better for specific projects or teams. All of the examples you have given are things our teams don't hold to 100% letter of the law, including the title of scrum master, at least I don't want that title when I am doing that role...

Our approach is start at the scrum baseline and inspect, adapt and deviate and return to the baseline when things aren't working so well..., but you must give scrum and teams many sprints to go through these cycles. We have 4+ years of scrum on different projects, teams and clients and it works, but only because of inspect and adapt and sometimes that means we almost go into anti-scrum patterns for periods of time as long as we meet the primary goal, ship working software.

Good luck ~alex
www.totxt.com
and
www.forwardvisibility.com

Whenever I see/hear arguments about process rigidity vs freedom, it reminds me of everything I learned about form vs freedom in my college days studying literature, the writing process, and artistic endeavor in general. Later, when I met and spoke to people practicing martial arts (though I never did), I heard some of the same ideas about form vs freedom. Then, when I encountered ideas about Agile methods (after decades of more traditional development work), the same idea(s) struck me again. This was especially true when I first heard Alistair Cockburn talk about development and how the martial arts idea of "Shu-Ha-Ri" was related to it.

For some, the "rigidity" of form is important because they may not instinctively or naturally be able to simply "wing it" in an endeavor from the outset. Being stuck there, however, isn't the goal of the form because, ultimately, the art/skill is about going beyond the form and creating new forms. But the original form gives you some sense of when you are actually doing that and a reference for what it means to go beyond the form in a certain direction or not. For some people, even going beyond the form requires a kind of form to allow them to realize that they are doing so in an, ultimately, useful way.

But this does not mean the form is at fault or that it is "flawed" if it does not answer all the questions of how to go beyond it effectively. First, I do not consider it being "flawed" for something to not have all the answers to every question that might arise. Perhaps those who do so might be relying on a "Shu" approach to the domain the form addresses and want someone else to show the way to extending the form because they do not see how to, or feel comfortable in, extending it for a satisfactory result. Second, if the answers were all there, that would constitute the "form" and questions of extending it would not arise in the first place. That is, if the questions did not exist, one might suppose the form was so successfully rigid that it answered everything.

To me, the real question is what doesn't seem to be working within the form and why? Then, what would make it work better (which is the extension of the form) in a given situation?

There is a very nice book called Discussion of the Method by Billy Vaughn Koen. It is about the "process" used by engineers and how heuristics play an important part in the way engineers work, i.e., the form(s) within which they solve problems and devise solutions. It reads very theoretically a good bit of the time, but that's because it is discussing the idea of recognizing how and when to use a form but also recognize its limits.

A new form that addresses the problem/solution better can replace an older form, but the older one existed because, at some point it (seemed) to be the right one for the job or, at least, the best at that time. That may mean it was flawed and, perhaps, flawed all along. Or it just may mean that, at some point, we were more flawed in our appreciation for the problem. However, that does not, it seems to me, to be a reason to abandon form, but rather a reason to try to understand a form and its limits better.

I think this is what is constructively at the heart of an inspect and adapt approach. All those literature, writing and arts ideas seemed to suggest that understanding a form (which usually requires practicing it) is important to start for most people, but there will always be form lurking in the background even if it is the form of the Ri level where form is so internalized that it seems like no form at all.

Nice post Scott, although I might sound like I am going more towards the freedom side, I agree with what I believe you are saying here. Start with the basics and some teams can handle deviation better than others. Not so eloquently though :) ~alex

It's all that literature and writing stuff still hanging on after many, many years!

Scrum can be restricting, if we let it become that way: There's nothing in "the rules" that gives everyone the appropriate amount of common sense to look up and ahead. This comes from maturity and experience. It's not something that can be canned and consumed.

In the notes to the latest Scrum Guide, Schwaber likens the rules of Scrum to those of Chess: They tell you how value can be delivered by containing complexity within a Sprint, planning time boxes, simple roles, daily scrum, sprint review, retrospective, etc. They don't tell you how to become great at it - that's up to the team to apply their own strategies.

I find this a subtle distinction that not a lot of folks are picking up and understanding - even those who I consider learned in agile practices.

By way of example, I blogged recently about a team whose QA members figured out a solution to their Product Owner's desire to have traceability in their requirements without having to ramp up into heavyweight documentation. They demonstrated some innovative skill to understand how they contribute value to the team for a Sprint to deliver an increment.

There's a lot that can be done with Scrum as-is; when people get the itch to work around its rules, it's usually indicative of deeper issues.

This is what I liken to heads-up/heads-down approaches: For new teams, it's heads-down for a while as they get used to the rhythms of incremental delivery - they're developing muscle memory for the processes. Over time, when this becomes second nature, they are ready to become more flexible.

Some folks snicker when I tell them of my experiences so far with not only enterprise-wide Agile transformations but also enterprise-wide Agile transformations with the Federal Government. I usually smile and explain the analogy of being in a very dark room or cave, etc. If someone merely lights a birthday candle, it makes a vast difference. If there are two birthday candles, is it twice as bright? What about 50? What if your goal is simply to read a book or to see well enough to carve a stick, etc.? You don't need flood lights for that. With complete darkness, you can do nothing but with only a few small lights, suddenly there is much that is possible.

The same is true with implementing Agile. Let's say there are 100 Agile best practices that folks use and you are dealing with a completely un-Agile organization. Simply helping them to discover and master 5-10 best practices or even 20 might improve that company's delivery by 1000%.

The moral of the story is, that Agile is not really a destination and should not be a massive checklist to fill-in. The focus should be on customer delight and continuous innovation and improvement.

-DJG

IMO Scrum is as rigid or as flexible as you make it. I can't think of any two Scrum implementations I've seen that are identical. Do what you need to do to achieve your goals. If Scrum helps, or parts of it help, then that's great. Don't worry too much about adhering to a model.