Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Loosen Up. It's Agile.

DZone 's Guide to

Loosen Up. It's Agile.

If you’re tempted, as I was, to be rigid in your approach to Agile development, remember that “rigid” and “agile” are opposites.

· Agile Zone ·
Free Resource

Take a Lap

Feeling rigid? Take a lap. You can't be Agile if you don't loosen up.
Photo credit by Unsplash/Jeffrey F Lin

When did Agile development become so rigid, so un-Agile? When did we become so attached to our precious processes and our favorite tools that we forgot about the people we work with and how we interact with them? 

Many years ago as a new Scrum Master fresh out of training, I was eager to apply what I had recently learned. The class reinforced many of the Scrum mechanics I had read about previously and also introduced some new ideas. For example, the instructor stressed the importance of “time-boxes," such as limiting daily stand-ups to 15 minutes. The class also taught the importance of protecting the sprint backlog – e.g. if the product owner didn’t think an item was important enough to develop in the sprint, they could not decide to add it half-way through that sprint.

I already knew much of what the class taught due to my self-study, but my ego as a newly-trained Scrum Master got the best of me, and I began operating in a somewhat militant fashion. I decided that daily stand-ups would never go more than 15 minutes. It didn’t matter if there was still one more important item to cover before we finished; 15 minutes had passed so we had to be done. During a sprint, I didn’t care if the product owner, while collaborating with a developer, determined that a minor, one-minute code change would make the outcome much more useful to the customer; it hadn’t been explicitly recorded in the sprint backlog, so I insisted it would have to wait until the next sprint. These two examples exhibited my mindset at the time, that ultimately led to somewhat of a metamorphosis in me.

During one particular daily stand-up near the end of the sprint, a tester was speaking about a critical bug that she had come across, which had to be corrected immediately. In mid-sentence, she glanced at the clock and noticed that our 15 minutes had passed, and she stopped talking. We all stared at her, waiting for the crucial information the developer needed to resolve this serious issue … but there was no response.

I asked her to continue. She looked around the group and said, “Isn’t it more important to finish our Stand-up on time?” Then it hit me: My zeal for “sticking to the rules” had made us rigid and diminished our agility. I apologized to the team for my short-sighted behavior, and we continued the stand-up, which only took another minute or two.

Thankfully, this critical juncture for me occurred just a couple sprints after my Scrum Master training, and the damage to the team and our outcomes was not long-lived.

Time-boxing is an important concept. Maintaining sprint scope is also essential. But, being so rigid in following rules that it negatively impacts outcomes and team dynamics is not good. Scrum mechanics – i.e. the rules – are there for a reason, and they should guide our behavior, especially for teams new to Scrum.  However, instilling an Agile mindset that focuses more on the principles of Agile – things like collaboration, transparency, reflection, and adaption – is so much more important than a set of rules.

So, if you’re tempted, as I was, to be rigid in your approach to Agile development, remember that “rigid” and “agile” are opposites. Don’t be so stuck on specific rules, methods, and tools that you forget the first line of the Agile Manifesto: “Individuals and interactions over processes and tools.”

Topics:
agile best practices ,scrum ,agile culture ,development ,project management ,lean ,kanban

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}