Scrum is seen as an adaptive and flexible software development methodology which aims to improve the development process. Over the years, there have been many success stories which have been attributed to Scrum. However, some teams continue to smell a good amount of inflexibility and rigidity. Is it Scrum at fault or is it a flawed adoption process?
Terry Bunio, in his letter to Scrum mentioned, how he was initially charmed by the processes and procedures in Scrum. However, slowly he felt that the rigidity of the framework did not help him with the freedom that was required for the success of the project.
I really did need a process where I could add requirements during a sprint when it made sense. I didn’t want to be limited in the duration of retrospectives if I thought there was more to discuss. … I hated being referred to as a Scrum Master. The actual role seemed to diminish my value as a Project Manager and made me just a coach of the process instead of a valued team member. I felt that I wasn’t actually part of the team anymore.
Marek Blotny, had a similar feeling about the practice of daily standup. According to Marek, he did not like the idea of team members being in a 'hold state' until their turn to speak. This killed spontaneous knowledge sharing. He mentioned that at times, keeping to the hard set limit of 15 minutes did not help either. If there is a good discussion going on and the entire team is involved then that discussion should flow.
So if you ask me if enforcing so rigid structure of daily scrum make sense. I will answer … definitely not! On one hand you have effective and useful daily scrums which encourage teamwork and on the other quite rigid structure and doing everything by the book.
Rod Claar mentioned that though Scrum is flexible, teams adopting Scrum tend to make it rigid so that they can do right when they are doing it for the first time. Rachel Davies also saw this tendency in teams adopting Scrum. She mentioned,
When I hear about Scrum Masters or teams attempting to "do Scrum by the book" it sets alarm-bells ringing for me. Scrum is a starting point on a team's journey towards agile software development. Being Scrum is not the real goal. We use Scrum to deliver product increments. No one is going to come along to your team to check up on your Scrum conformance.
Geoffrey Wiseman added that rigidity of a process and agility are not necessarily diagrammatically opposite. The process might define that there should be no interference once a sprint is started. The sprint might be seen as an atom of planning and implementation but it is definitely open to practical flexibility.
Is that a hard line to take? Perhaps, yeah. Some might argue that if you can't live within those constraints, you shouldn't use that process. But practically speaking, can a sprint survive a momentary re-routing of a resource? Yes, I think it can, both in letter and in spirit.
Thus the rigidity of the process is as strong as the team wants it to be. Though, it is good to adhere to the constraints lest the entire process ends up in chaos however, being rigid to the extent of ignoring practical conditions is detrimental both to the project and the team.
Community comments
In my opinion the adoption process in these examples
by Alex VanLaningham,
Form and Freedom
by Scott Duncan,
Re: Form and Freedom
by Alex VanLaningham,
Re: Form and Freedom
by Scott Duncan,
Heads Up/Heads Down
by Chris Chapman,
Zen Approach
by Daniel Gullo,
As rigid or flexible as you make it
by Dave Nicolette,
In my opinion the adoption process in these examples
by Alex VanLaningham,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Form and Freedom
by Scott Duncan,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Form and Freedom
by Alex VanLaningham,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Re: Form and Freedom
by Scott Duncan,
Your message is awaiting moderation. Thank you for participating in the discussion.
It's all that literature and writing stuff still hanging on after many, many years!
Heads Up/Heads Down
by Chris Chapman,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Zen Approach
by Daniel Gullo,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
As rigid or flexible as you make it
by Dave Nicolette,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.