Advice

Agile Creativity – Principle #2: Embracing Change

by

(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

My Personal Agile: Visualization

by

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

So you’ve just started your own sprint.  You’ve got a nice big spreadsheet.  You may like that (I do) but if you’ve done any agile research you may ask:

“Why the heck are we doing this in a Spreadsheet?”

There are a lot of tools for organization and time management: Trello, Smartsheets, and my beloved Rally.  Why aren’t I using them here?

A few reasons – none admittedly all that noble.

  1. I am deliberately avoiding more sophisticated tools right NOW because I want to perfect my process.
  2. Spreadsheets give me a lot of control and I can read them with multiple kinds of software.
  3. There’s a lot of choices for tools, but none quite my style – or that I want to pay for.
  4. I track things down to very fine levels – these tools might overdo my breakdowns or it’d take more work to use them.
  5. I am used to operating out of spreadsheets.
  6. I compensate for the limitation with some other methods, some of which I list below.

But some of us don’t work out of spreadsheets.  Why?  We need visuals.  I’ll present you some ideas, but a note:

In “professional” practice of Scrum, I use the big visible boards either automated or printed out, and track to the task level on most teams, the story level on teams of specialists.  What works here may work for you and not work for a team or vice versa.

For instance, one tool may work for a team and not you.  My spreadsheet method would be a disaster for a team in most cases.

Anyway, let’s talk about ways to visualize your work if, like most people, you don’t love spreadsheets like I do:

Solution #1: Use One Of the Tools I mentioned

Trello, Rally, and so on.  Really requires you to learn and adapt to one of them.  It could work, but you’d have to learn a new tool.

The plus side is it may work and you learn a tool to use elsewhere.

Solution #2: Pivot Tables

Since all my work is in a spreadsheet, I use pivot tables and quick calculations to see where I am story wise, figure how much work is done, etc.  After doing this for nearly a year I had pretty good instinctive sense of where things are.

As a note, I do create a rough “guess” every week as to what I can, will, and have to do and look at that separately.

Solution #3: Print Out Your Sprint Backlog

This is a cheesy but surprisingly effective way to track work – Print the backlog out.  Tape it on a wall or something.  As work moves, fill in the spreadsheet cells, using them to track progress.  If you use it well, you might not even need to update the original spreadsheet (though I do as I like to run a lot of statistics)

I did this for awhile, by the way.  It helped, but really as I was always in the Spreadsheet I didn’t need it eventually.

Solution #4: The Big Visible Board

A lot of Agile methods – especially Scrum and Kanban, use a Big Visible Board.  You take some board, divide it into columns for the different categories (Backlog, Defining, Developing, Review, Done), and then stick notes or cards up for each task or story, and move those around.  Yeah, it’s nothing more than cards or sticky notes on a board that you move around.  But it’s fast, easy, and in-your face so you’re aware of what’s going on.  It also helps teams coordinate because they get to see what’s up at a glance.

Now you’re not a team, but these Big Visible Boards help you stay focused – you see it all the time, you’re aware of it.  If you find operating out of a spreadsheet doesn’t work I recommend trying this method.

However, my guess is that if you look at your Sprint Backlog there’s a lot there.  A few Projects, a good amount of Stories, and a lot of Tasks.  Wouldn’t the board get overwhelming?

Well first, if it’s overwhelming maybe you’re overloaded.  But if you’re not, here’s a few recommendations:

  1. Only have Defining, Developing, Review, And Done on the board.  Put your print-out Sprint Backlog on the left.  As you take tasks, make sticky notes for them on the board and see them through.  Sure you get a pile of sticky notes at the end, but that gives you a sense of progress.  By the way, you probably won’t need to update the original spreadsheet much if you do this.
  2. Track by stories.  This is a bit more challenging, but if you’re REAL focused on doing each story all the way through before you take on another, then you can just track on the story level.  Put the tasks on the story and check them off as you do them.  By the way, if you have good story/task breakdown you may have to combine it with method #1.
  3. Two-board solution. On the top are the stories in progress.  On the board below, active tasks.  Might get confusing, but it could help you get “both” levels.

Again, see what works for you.  but that’s the point – what works for you.

– Steve

 

My Personal Agile: Work

by

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

Now let’s get on to the next step of my Personal Agile – doing actual work! You’ve got your Sprint Backlog, which is everything you plan to do this sprint (a month) so let’s go.

How Do I Start?

Every day I look at my Sprint Backlog and figure what I should do and want to do. Then I do it. In time you get into a rhythm where you unconsciously know what you want to get done – usually.

Yeah, that’s it. A daily review – maybe more than once a day – and doing stuff. Sounds simple? Of course it is – because you’ve thought this over and taken a manageable chunk of stuff to do. One of the great parts of Agile methods is that you get enough mindwork done up front and break stuff into manageable chunks that it’s easy to focus.

Well, What Do I Do First?

That’s pretty much up to you. In general, you should tackle highest priority work first and work your way down.

In practice, it’s often not as clear cut:

  • There are time constraints on when some things have to get done. You may not list cleaning that grungy guest room sink as your highest priority, but mom’s visiting.
  • Some work may need approval, materials, etc. Those art supplies you needed are late.
  • Some work you can’t stand doing for an extended time period. Maybe you start mowing the lawn this evening but finish tomorrow (but hey, maybe your mowing should be two tasks or even two separate stories).
  • When you start things you quickly realize your priorities are off. You really don’t need those new clothes.

Priority order is a good guide, but the only one.  Do what works.

Sticking With Things

To make sure you progress and stay focused, you want to stick with work.  Here’s a look at what I do:

  • If you take a task, make sure it’s one you can complete in one sitting or one that you’ll get done without anything else interrupting. For instance if you want to write up an essay but don’t finish it before bed, then the next day that’s your top priority.
  • Once you start tasks in a story, that story should (more or less) be your top priority. This lets you focus on delivering value. It also helps get the Story out of your mind. Remember, good breakdown means more stories with less tasks, and that makes this easier.
  • In all cases, try to focus on something being done and complete. Deliver value – or parts of value.

Sticking with something helps you stay focused and keeps you from the mental waste of switching gears over and over.  In a lot of cases it’s better to finish something and start the next thing unless you really have to.

How Do I Track Work?

You want to track the work you’re doing and to know what you’re up to and what you’ve done.  Here’s what I do:

When you start a task, move the “hours” estimate into the appropriate column, and keep moving it. This way you’re tracking work done:

  • Define – You’re fleshing it out and getting ready.
  • Developing – You’re doing it.
  • Review – You (or someone else) are confirming it’s done.
  • Done – Well, duh. Done. Congrats.

This is why I keep totals at on my spreadsheet so, at a glance, I know how many “hours” of work are done where. I’ll go into this more later.

One thing you’ll note is that I track the state of every Task (some methods only do stories). I find if you track and validate Tasks, the stories usually take care of themselves – a truly well made Task may not complete the story but is verifiable. It also lets me follow my progress in miniature as I’m pretty focused on this.

You may only need to check your progress story-level. You can use a pivot table for this, or other forms of visualization I’ll cover next.

How Do I Avoid Being Overloaded?

OK, here’s where we get a new concept: Work In Progress.  This is important.

Work In Progress, aka WIP, comes from Kanban, and has been adopted into many Agile practices, including, of course, some variants of Scrum. The core idea is to limit what you’re working on so you focus – and so you find blockages to completion.

It’s simple – you set a limit on how much work can be in each column (Define, Developing, etc.).  This is usually only one item.  I usually limit it to one task, but sometimes it’s limited to one story.  Nothing can move ahead until there’s “space.”

This idea of moving ahead only when there’s space is called “Pull.”  You don’t push items forward – you pull them when available.  I find this comfort is very comforting, it changes your focus on work.

But what if you’ve got a task in Developing, it’s done, but you have another task in Review waiting on approval? You don’t move that Developing task. It sits. You can either go Define a task and do some research, or try to get the task in Review, well, reviewed.

If all three are filled up? If your Defined thing is Defined, your Developed task is all developed, and you in-review task is in review? You should focus on the in-review task, but if everything is blocked, it may be time to take a break.

Now of course work may have to move forward, but you should acknowledge how you got blocked and fix it in the future. When things get jammed up that’s the sign of a flaw – and a sign you should change your approach so it doesn’t happen again.

Think this is tough? Some folks like to keep it down to one item being worked on period, no matter what the state. In fact, I’m an advocate, on the individual level, for doing this method. Sometimes I even succeed.

So what does all this stuff with Work In Progress Do?

  1. It forces you to avoid multitasking. Multitasking really distracts you, and the more you pile up half-done, the more you’re distracted.
  2. It rethinks work. The idea of “pull” of moving forward only when there’s space helps you see work in a more relaxed, appropriate manner.
  3. It reveals blockages and obstacles. Think of your workflow as a pipe system. If you restrict the amount that goes through it, when a jam up occurs you learn a lot. This is an enormous amount of Kanban – to the point where I’ve heard people say Kanban isn’t a management tool but just a way to find and remove blockages.
  4. It works better with good work breakdowns, so helps validate them.

Now because life gets complicated, I practice what I call WIP 1+1. That means the usual limit applies, BUT I allow myself to work on something else as long as I can get it finished in one go. This means if, say, something is sitting at my editors, I can go do some cooking or clean the bathroom. But I wouldn’t start something that may need another editor’s attention.

As noted, I do this on the task level.  You might find it works on the story level.

What If Something Takes Longer Than I Estimated?

That’s fine, that’s OK. It’s something to note for review at the end of the sprint.

If this requires you to cut work, fine. Figure what the least priority items are and don’t do them unless you suddenly have time. You’ll review this.

One thing I do is change my estimate to fit my new findings.

What If I Get Everything Done Earlier?

Well you could take a break. Otherwise, just bring the topmost items in from the Backlog into the Sprint Backlog, one at a time. Finish those items before taking something else off the backlog.

So This Is Just Taking A List Of Stuff And Trying To Do It Without Multitasking In A Given Timeframe?

Well, yes. Welcome to Agile, where we cut through the bullshit or break the bullshit into manageable pieces.

Next Up?

This may seem easy, but we’ll talk tools and visualization.

– Steve