Tag: second agile principle

 

Posted on by Steven Savage

(This column is posted at www.StevenSavage.com and Steve’s Tumblr)

And we’re back to applying the Twelve Principles of Agile Software of the agile Manifesto – originally meant for software – to creative works. Let’s take a look at the second principle, which embraces what usually drives us up a wall. That, for those of you with a long list of wall-driving, is change.

The Second Principle is:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This is a principle I entirely agree with and am often terrible at implementing. This is because I’m often used to change being for bad reasons – and I’m sure you have similar experiences. It’s often hard to embrace change because it’s dumb.

However this embracing and leveraging of change is core to Agile, and that is what makes Agile so powerful. So let’s see what this principle can tell us about embracing change, even if we currently hate it.

You Embrace Change For the Customer’s Competitive Advantage

In Agile you embrace change for a reason, and that reason is to provide Value of some kind.  “Value” is really the reason for all Agile practices and principles, and using change is no different.

Note that the second principle doesn’t just say “embrace change because it’s change.” It doesn’t say you have to accept every change. You embrace change for specific goals – and as far as I’m concerned if the change doesn’t help the customer, there’s no reason to accept a bit of it.

You have to help sort out if a change helps your customer, brings no benefit, or harms them. Then you, the creative person doing the work, has to work with the customer to help them understand your choice – which might be to tell them *the change is a very bad idea.*

Because you are a creative, as you know your work intimately, you can help a customer decide how to react to a change. The result may not be “yeah, let’s do that.”  The results may be “this is the worst idea ever, let me tell you why.”

I think the change we learn to hate is the change where we cause harm or waste time by following them. We want to help people; there’s nothing more annoying than having that be prevented due to a bad change.  But a good change?  We can help with applying that.

EXERCISE: Think about the last project you did that faced some changes. How did you evaluate if they helped the customer? How did you communicate your findings? How could you have done better?

You Welcome Change Even Late In The Project

Even if we can embrace change, it’s annoying to have to do so when it’s late.  You got a lot of work done and now it’s wrong?  You have to restart some things?  Why?

But these late changes may be valuable, and thus worth doing. As annoying as they are, we should embrace them – but how do we do that?

I think there’s two ways to do it.

First, we have to accept that many of our ideas of “done” are often the enemy. We think something is “almost done” and is thus a solid thing, immutable, unchangeable. When a change comes it offends our sensibilities of “done.”

But, if we think of “done” as a point we navigate towards, tacking here and there, we can embrace change. That late change means it becomes “done better.” By accepting “done” isn’t as solid as we’d like, we can find ways for the actual “final” product to be more what the customer wants.

Second, we should make our creative work easily adaptable to change. This allows us to quickly alter them when new requirements come in. A few examples:

  • For a book, make the plot outline easily editable so you can swap things in and out.
  • For a graphic work, you save the image “historically” so you have many versions, and use multiple layers to edit easily and retain old elements.
  • For a training film you keep it broken up in many scenes for quick editing, only incorporating them at the end. You also never throw away a scene just in case.

So to review:

  • Let go of solid ideas of “done” so you can embrace change.
  • Do your work so it’s change-responsive, and can be adapted easily.

EXERCISE: Take one of your projects and ask yourself what are five ways it could have been more change-responsive?

Embrace Change

The whole point of the Second Agile Principle is that embracing the right change, even late, brings advantages. This requires a mind shift because often we’re trained or experience change as bad – we need to learn to outright embrace it.

I find you can get to this mindset with two things: focus on value, and embrace Agile methods and practices.

When you focus on value, you see change differently; it’s a chance to do better. It keeps your “eyes on the prize” and not on worrying over the latest changes or assuming the worst. It also helps you take a more “navigational” approach to developing works, adjusting to getting to the destination, or perhaps a better destination.

When you focus on Agile methods and practices, they give you tools to embrace change. Using them effectively and whole-heartedly helps you deal with change and get the most out of it – that’s what they’re there for.

There’s a lot of psychology in Agile. As you guessed.

The Second Principle Is Often The Hardest

So there’s the Second Agile Principle – embracing change. It’s perhaps the toughest one to embrace, but also one of the most potentially empowering. When we can alter how we approach change, we can find advantages for our customers, and be ready to shift so they get the best value.

It may just be a bit annoying as we change our mindset.

A quick review:

  • Learn to focus on finding the competitive advantage of changes – if any.
  • Re-think what “done” means so you can take advantage of valuable changes.
  • Make sure your work is “change-enabled” so you can alter course quickly, even when it comes late.
  • Learn to see change differently by focusing on value and using the tools available.

Change may be an opportunity; if we learn to see it and use it.

Now with change out of the way, let’s talk more value . . .

– Steve

...
Seventh Sanctum™, the page of random generators.

...  ...  ... ...

...
 
Seventh Sanctum(tm) and its contents are copyright (c) 2013 by Steven Savage except where otherwise noted. No infringement or claim on any copyrighted material is intended. Code provided in these pages is free for all to use as long as the author and this website are credited. No guarantees whatsoever are made regarding these generators or their contents.

&nbps;

Seventh Sanctum Logo by Megami Studios