Agile Creatives: The Agile Manifesto

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

Hello everyone and welcome to my next blog series.  I’m going to be putting this in a few different places because it applies to so many of you – creativity and productivity.

Most of us are in a creative profession – even if we don’t know it.  The problem is that creative professions require productivity, yet are also the hardest to manage because creativity has many unpredictables.  Being able to be creative, deal with unpredictability, and be organized is a challenge, one rarely met effectively.

I meet this challenge by using Agile methods (Scrum in my case), which you can apply to many efforts, including creative ones.  Agile methods are about adaptability, adjustment, responding to change, and efficiency.  Perfect for something creative, as long as you make the effort to apply them.

I’m not going to talk which Agile methods to use. You can try Scrum, Kanban, or whatever works for you.  Instead, I’m going to talk about the mindset you need to be Agile and creative.  I’ll do this by exploring the Agile Manifesto and what it means for creative works like writing, drawing, and more.  Agile is all about adjustment and adaptability, something creatives are supposed to be good at – but we’re often restrained by everything from bad organization to our own assumptions.

I’m going to start with the Agile Manifesto – which happens to be about software.  This isn’t a problem – this means its perfect.  Software is a creative act, bordering on a mixture of high technology and shamanic vision, resulting in hard product through a near-occult process. The Manifesto is a perfect place to start to develop a creative approach.

Now before we begin, let’s take a mercifully quick look at Agile.

A Mercifully Quick Look At Agile

  1. Agile methods are highly adaptable forms of productivity.
  2. Agile methods avoid large-scale plans – that often go awry – and focus on adaptability, review, and improvement.  I sometimes call this “micro-planning”
  3. Agile methods have existed for decades, and seem to have originated in store stocking and manufacturing.
  4. They became more codified in the 90’s.
  5. The Agile Manifesto and the 12 Agile Principles of 2001 expressed Agile as a Philosophy.
  6. Thanks to the Agile Manifesto, Agile took off as it could be seen as a mindset.
  7. I really, really like the Agile Manifesto and find its a good guide to adaptable productivity.

Now, onward.

The Agile Manifesto In Review

Let’s take a look at the good o’l Agile Manifesto.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Here’s the core of good Agile.  Work with people over a bunch of tools and methods and meetings.  Deliver stuff that works over detailed breakdowns.  Work with people directly as opposed to arcane agreements.  Respond to change instead of following a plan that doesn’t work five minutes after you finish making it.

It’s a lot of common sense, and like common sense it took someone to write it down to make it clear  It’s good advice anywhere, though it’s pitched for software, as are many books and guides on Agile and Agile methods.

So let’s take a look at the manifesto and think about what it means for creative work.

Individuals and interactions over processes and tools

You’ve got to create something.  You need to understand what people want.  The people asking you do to this need to understand what they want.  You also need to work with them to communicate, have meetings, reviews, use certain pieces of software (or get people to use them).  Sometimes this conflicts as people use different processes or argue one tool over another.

What do you do?  You focus on working with people directly as possible.  You may have meetings and statuses and use specific software, but that’s not as important as making sure you’re actually working with people directly.

For creative people this is exceptionally important because creative work is a highly individual experience.  A person has a vision they need expressed – and you must understand it.  There are near-infinite options in creative works, from a color scheme to a dialogue choice, and working with a client or an actor or an artist requires dialogue to “get it right”  A creative work can become anything – so talking to the people involved helps it become a right thing.

Because creative efforts involve so many options, you’ll need to focus on interactions with people over formality or a given choice of tool.  Sure a regular meeting schedule is nice, but you may need to make that early-morning change.  You may use one graphics program while someone else use another – so you need to find a universal file format.  These things may matter, but not as much as interacting with people.

Sure you may need to use specific methods and tools.  You’ll figure those out.  But the first thing is talking to people.

As an Agile Creative:

  • Work with people as directly as possible.
  • Interact with them regularly.
  • Processes, plans, methods, are secondary to the goal of interacting with people – and should support interaction.
  • Tools, software, and so on are secondary to the goal of working with people – and should support this collaboration.

EXAMPLE: You’re writing a short story for a specific online magazine – and two people have to give you feedback on it.  You figure the best way to do that is to put it on a public document share (that you do use), and chat with them on a web chat (which you’ve never used but they use).  Everyone has the chat program on their phones so you can get feedback as you work any time.

Working software over comprehensive documentation

Let’s step away from the word “software” and think of “usable results” here.  Creating something usable is your goal because that work – even a rough draft – stands on its own.  That’s a lot more valuable than a detailed description or ten pages of noes explaining what you did.

(Note sometimes your product is documentation.  In this case it’s not needing documentation of documentation.)

Sure you may need documentation, but you want to get to a result because it speaks for itself. A rough draft gets you feedback.  A wearable if safety-pin laden costume can be tried on.  Getting something done matters, even if you know it’s a draft or will need feedback to improve.

What’s less valuable is trying to document all of this.  Sure, you might need to do some documentation, but don’t make it the most important thing.  Do you need a giant list of possible color swatches?  Do you need twenty pages of outlines explaining five pages of story?  Do you need a Powerpoint to explain another Powerpoint?  Do you need all this extraneous stuff?

Probably not.  You need enough to do your job so you can make something.  Produce something that speaks for itself so you can get your hands dirty, learn, and get feedback.  Besides people relate better to something solid.

In fact, with creative works, which often have infinite potential, comprehensive documentation is a trap.  You can never be complete.  You don’t have time to document fifty ways to do a training video when you need one.

There is value in documentation, of course, but ask yourself this – what’s the value?  If you spend an hour writing up a proposal that saves you fifteen minutes, but if you don’t write it you spend thirty minutes experimenting to get it right, did you save time?

As an Agile Creative:

  • Focus on delivering the product.
  • The product is where feedback comes from, so a flawed product is better than comprehensive documentation.
  • Documentation has it’s place, but the product is first.
  • There are many substitutes for documentation that are more efficient and effective, such as direct interaction.

EXAMPLE: You’re designing a logo for someone.  This involves an incredible range of colors, options, trademark issues, and more.  To make it easier you keep multiple versions of the logo and send out a new copy every day to the person that wants it – with their tweaks.

Customer collaboration over contract negotiation

You have to work with people to create something – we’ve covered that earlier.  But we also have to come to agreements about how we do things, what we’re doing, and so on.  Sometimes you just want to stop spelling out the minutiae and talk to someone directly.

That’s what you should do.  Collaborate with people, focusing on working together.  Arguing fine details, negotiating tiny elements for hours, gets in the way of working directly with people and getting results.  It’s also far less adversarial.

This may require you to do a lot of psychology.  Or have someone help you with it.  But it’s a better approach than spending all your time in negotiations – which, like comprehensive documentation, can be overdone.

Additionally, you’ll want to work out ways to collaborate.  Meetings, chat programs, feedback, working together.  Make collaboration possible so it can happen – and the more you do it, the less you’ll need to argue fine points that aren’t meaninfgul.

(By the way if someone you work with is all about the contract and not about collaborating, that’s a warning sign.)

As an Agile Creative:

  • Focus on collaboration early on.
  • Develop methods for collaborating.
  • Help the people you do creative work for take a collaborative mindset.
  • Work to eliminate negative and pathological contract negotiations – while focusing on the important parts.

EXAMPLE: You’re doing a cosplay commission with someone who has very specific needs, wants, and deadlines.  You chat with them regularly and give them updates on likely completion times, and ask questions to help them make decisions.  This lets you get to work up front.

Responding to change over following a plan

Every plan you have is wrong the moment you finish it. It may be incomplete.  It will be interrupted.  The only way for a plan to be right is to not spell it out completely.

Now plans are great – I’m a PMP, I’ve been certified in planning.  But reality gets in the way, so you need to focus on being adaptable over following a plan even when it’s gone stale.  This is one reason Agile methods are so helpful, they focus on adaptability, with just enough planning to keep moving.

This may sound weird to warn people about change in creative activities.  We’d like to think they’re wonderful and spontaneous.  This is wrong because creativity, being so hard to pin down, is often crammed into a box of organization and plans to get control of this wild process.

It usually fails.

Ever gotten livid over a requested edit?  Wanted to argue with someone about how they critiqued your art?  Gotten frustrated at a rewrite of a single paragraph?  You know what I’m talking about; because creatives need some control, they often chafe against giving it up.  You need to learn to give up that control and leverage change.

I find there’s a few lessons to help:

First, realize change is a tool – often change happens due to feedback, discoveries, and more.  It’s up to you to use what happens to learn and to adapt and make your work better.  This can be painful, which leads to . .

Secondly, you have to build change into how you do things; make yourself more change-responsive.  Don’t put into ink what can be done in pencil.  Save versions of your work.  Test out what you’re creating earlier than usual.

Third, learn the right level of planning.  This may differ from project to project, increment to increment.  Find what lets you plan but not overplan.  Plan enough get something out but not so much you can’t change.

Fourth, learn how to get feedback.  This helps you change well, change effectively, and perhaps change earliy enough you don’t have to ditch a lot of work and ideas.

As an Agile Creative:

  • Learn to accept change is inevitable.
  • Develop a “Navigating” mindset.
  • Find ways to leverage change to make your work better.
  • Work in way that let you respond quickly to change.
  • Plan the right amount – not so little you’re lost, or so much you can’t shift gears.
  • Develop ways to get feedback.

EXAMPLE: You’re working on an indie game, a challenging market to be sure.  You break down work by major features and priorities, creating vertical slices of “game” that can be quickly played by beta testers.  This lets you get quick feedback while refining code.

The Agile Manifesto For Agile Creatives

So we’ve just been through the Agile Manifesto for creatives.  Let’s sum up.

  • Focus on interacting with people and getting feedback.
  • Deliver things to get that feedback.
  • Take a collaborative approach.
  • Respond to change – and make sure you can respond to change.

There you have it – a pretty good mindset to adapt so you can be productive.  Again you may want to find a method that helps you, but if you keep these ideas in mind it’ll help you find a method AND make it work.

Now, next up there’s also 12 agile principles.  Yeah, I know it’s a lot, but we’ll explore them bit by bit – for creatives.

A Side Notes On Sides

The manifesto notes that it value the things on the left (individuals and interactions, working software, customer collaboration, responding to change) over things on the right (like having a plan).  This doesn’t mean that things on the right are bad, its jut things on the left are more valuable.

there’s a paradox here – we do need tools and processes, documentation and plans.  But they can get in the way of the things on the right.  How do we solve that?

My solution is that things on the right should be used in such a way that they reinforce the things on the left.  Use planning tools and methods that support change.  use tools that support collaboration.  By having these things that can get out of hand become methods of support, you do better and don’t get distracted.

– Steve

My Personal Agile: End Of Sprint

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

The sprint is done. The Retrospective is done. So now what?

You start over again.  Your sprint ended but another one begins right after.  You apply what you learned and move forward.  Agile is about moving forward; its a vehicle not a destination.

Here’s what I do in my Personal Agile when a sprint ends:

  • Look at the Incubator. Add or subtract things as you need.  Re-order them to fit the priorities you have – which probably changed.  I actually do this during the Sprint now, having gotten better at incorporating my lessons.
  • With the Incubator re-ordered, I then look at the Backlog and see what I should add to it from the Incubator, subtract (and maybe even move back to the Incubator), or re-prioritize.  I may also see ways to break down the work in there as well.  Much like the Incubator, in time I’ve come to modify it during the Sprint as I learn.
  • I put any undone work back into the Backlog, and rerank it. A surprising amount of time you’ll find undone work isn’t the highest priority. Sometimes you even decide not to do it and just drop it.
  • I review the Regular Tasks list to see if I need to change it. In time you’ll probably not need to do it because you’ll change it during the sprint and in the Retrospective.
  • I plan a new Sprint – Copying the Regular Tasks and then adding as much of the Backlog as I can do for a month.
  • I start the sprint.

That’s it. It’s back to the beginning. You’re done and you restart.

Now a few bits of advice:

  • A lot of the review at the start and end of sprint will eventually work into your regular work. You’ll just get ideas or discover re-prioritizing you need to do as you go.  It’s possible you will need less retrospective and planning time – but don’t change those times until you seriously review them.
  • You’ll get better at review and planning over time. It’s a real skillset you can develop – that may be useful in life in general.
  • Don’t try to get review and planning perfect. Agile is about adaptability, you do your best and keep getting better.
  • Don’t overload yourself. Its very very easy to do that, especially on the second or third sprint when you really get going.

So there you go, my personal Agile. I hope that’s going to help you out.  I’m going to try to bundle this advice up into a free ebook at some point.

– Steve

 

My Personal Agile: The End-Of-Sprint Retrospective

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

So your sprint is done. Congrats. Now it’s time for the Retrospective!

The Retrospective is a big part of Scrum, and there are variants of it in a variety of Agile practices. It’s simply sitting down and asking yourself “how did it go,” finding things to improve, and improving them.

It sounds simple, and it is. That’s the point. It’s an obvious, common sense thing to do is regularly review and improve. It’s just not common enough in practice.

Think of it this way, it’s great to stop now and then and decide how to get better. You just gotta make room to review and improve, and Scrum – and my personal-life implementation of it – make it explicit.

So here’s what you do.

The Retrospective

First, set aside time for the Retrospective.  It should always be timeboxed, and I use an hour.  If it doesn’t take an hour, fine – if it does, well you stop anyway.

Here’s how I review in a Retrospective:

  • First, ask yourself what worked. What kept you moving forward, getting things done, and what did you do right? It’s good to focus on the positive here, because if you do enough stuff right you’ll do less wrong.
  • Secondly, ask yourself what went wrong. Focus on specific things that went wrong that are improvable. There will be stuff, trust me.
  • Third, ask yourself what work you couldn’t get done and why. Note that’s not necessarily a wrong – maybe something wasn’t needed. But it let’s you figure out specifics.
  • Fourth, ask yourself what work you discovered you had to do that you didn’t realize. Always good to keep yourself aware of surprises.

You probably have a lot of stuff. But now you gotta make it actionable. What I usually do is list down all the items above, prioritize them, and work in addressing what I learned (good and bad) in actionable items.  Don’t just “not” do something, focus on doing better.  Take a good thing and find ways to repeat it.

As you come up with actionable items, there’s a few ways to record them so they get done:

  • New tasks in the Regular Tasks list. Often undiscovered work in my Personal Agile is something that reguarly occupies time at specific intervals.
  • New things in your backlog or incubator – say if you want to edit better, set aside a few hours to read up on it.
  • Habits you need to improve. I keep a list of what to improve and review it every few days.

Sounds overwhelming? It can be. So focus on the important things that you know you can address.  Don’t overload yourself.

You’ll catch it next time.

Velocity

Velocity is a measure of how much work you got done in a Sprint.  As you examine Velocity over time, you learn how much work you can take – maybe.  There’s a few arguments about how to apply Velocity in Agile, so I’m going to give you my opinions.

Here’s how to get and use Velocity:

  • Measure how much work you got done in that sprint. As noted I use hours of work.
  • Keep a record of these hours per sprint (month). I keep a list in the same spreadsheet as my tracking lists. This lets me compare month to month and make notes.
  • This gives you a rough idea over time of how much work you can get done at a given time.
  • * As you plan sprints, look at your past Velocities to help you decide how much work you can do. This keeps you from overloading – or underloading – yourself.
  • It helps you keep a reasonable amount of work, creating smooth, regular productivity.  Note that’s helps because . . .

Here’s the thing, you can’t be sure the numbers are always perfect.  Velocity is a guide, but each month is different, from holidays to illness to vacation.  Each task is different, and sometimes things that take the same time can be mentally taxing or better done in different situations.

So I use Velocity as a a check, a suggestion, and a way to catch me overloading myself.  But each sprint I also do a gut-check if I can really handle the workload I want to do, for those given tasks.  Velocity is just one tool – but a good one.

What’s Next?

What’s next? Your retrospective is done. Time to end the sprint and start a new one!

– Steve