How Rigid is Scrum?
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.
In my opinion the adoption process in these examples
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
Form and Freedom
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
Re: Form and Freedom
Heads Up/Heads Down
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.
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.
As rigid or flexible as you make it