Agile Zone is brought to you in partnership with:

Matthias Marschall is a software engineer "Made in Germany". His four children make sure that he feels comfortable in lively environments, and stays in control of chaotic situations. A lean and agile engineering lead, he's passionate about continuous delivery, infrastructure automation, and all things DevOps. Matthias is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

Why You Need to Customize Your Agile Methods

09.20.2013
| 4867 views |
  • submit to reddit

You’re starting off with a new laptop. The OS is installed, but using it feels awkward. Nothing looks like it used to on your previous one. You’re really frustrated how slow you move around just because you’re missing your beloved customizations.

A few days later you feel the flow again. You’ve tweaked your OS and apps to best fit your workflow.

Your Agile Process Also Needs to Fit Your Workflow

Scrum prescribes a lot of things in detail: which meetings you need to do and when, how to estimate and break down your work, how to iterate and which certifications you should have.

There are no exceptions or adaptations allowed.

Not Allowing Any Exceptions or Adaptions of Your Process Is Stupid

The goal, the people, and the environment in which your organization works creates a unique system. It’s a complex system. In complex systems, there is no “one size fits all."

While there are certain basic principles you should keep in mind, you need to experiment with the processes you use to organize your work. By observing how your experiments influence your work, you can learn and adapt.

Every Experiment That Yields Positive Outcomes Will Make You Faster and Better

Customize your process according to what you learned from your experiments. You don’t need to care about whether you’re still allowed to call it Scrum or whatever. The only thing that counts is whether you can create more value, faster.

Creating more value, faster means you have increased flow throughout your organization while removing obstacles and friction. By friction, I mean anything about the Scrum process that doesn’t fit your system, like frictions you introduced with starting Scrum only in development and excluding other departments.

If Scrum Iterations Don't Fit Your Situation, Drop Them

Keep aiming to frequently deliver working software. There are other ways to do this beside iterations. Every kind of continuous delivery approach will help you here.

Iterations are a way to protect your team from too many changes. If this isn’t an issue or you found other ways to keep your team focused, iterations may not be for you anymore.

“Ah, that’s great,” you say, “If something doesn't work for us, just drop it?”

Nope. Don’t be too quick to drop stuff that doesn’t seem to work.

First, you need to make sure you understand why a certain element (like iterations) is defined by Scrum and what exactly isn’t working. When you’re merely beginning to absorb agile ideas you might misinterpret your difficulties. You might think you need to adapt your process, but in reality you need to change the way you work to proceed on your road to Agile.

We’re talking about customizing a process based on understanding of Agile and experiments, not about sneaking out of it to keep your old way of working.

I’m Not Saying Here That Scrum Doesn’t Work

All I’m saying is that when you’ve understood why Scrum works and which parts might not fit your situation, experiment with changes and adapt. Use it and make sure you understand it.

We need experiments because our work environments are complex systems. In complex systems, the only way to improve them is by running experiments. But experiments need a good understanding of agile foundations. First, make sure you understand why certain things are defined in your agile process. Only then should you start to customize it.

When you customize your process, you’ll feel more at home with it – just like with your customized OS and apps.



Published at DZone with permission of Matthias Marschall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)