Why you need to customize your agile methods

by on September 19, 2013 · 0 comments

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, which yields positive outcomes, will make you faster and better

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

And 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 which doesn’t fit your system. Like frictions you introduced with starting Scrum only in development and excluding other departments.

If Scrum iterations do not fit your situation, drop them.

Keep aiming to frequently deliver working software. There are other ways to do this besides 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 does not work for us, just drop it?”

Nope. Don’t be too quick to drop stuff which 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 agile understanding 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.

Did you enjoy this article? Get new articles for free by email:

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>