(This column is posted at www.StevenSavage.com and Steve’s Tumblr)
Let me say up front this is one of my favorite Agile Principles (#10 is up there too.). It’s obvious, thought-provoking, and in-your face.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Yes, the Agile Principles state outright that you should find and keep a pace that can be maintained indefinitely, and everyone should have that pace. I’d love to phrase this positively, but let’s face it, it’s a principle about not burning out.
Yes, way back in 2001 the Agile gurus were well aware of the potential for burnout, death marches, and more and made it part of their principles.
Agile processes make sure that development is sustainable – that the inputs, velocity, testing, processes, demands, etc. all are aimed so everyone (and I do mean everyone) involved could keep this up forever. This of course makes sense – once you find a doable pace you’re able to continue, predictably, over time. When there is deviation, you can adapt as you’ve got a stable pace going. When it’s sustainable you can keep delivering value.
This flies in the face of so much we’re taught about work, leisure, and so on. We’re taught to expect death marches. We’re taught to expect rushes. We’re taught to idolize being overworked. This Agile Principle outright states ‘bollocks to that’ and says ‘no.’ Or if we want to put it positively, says ‘yes’ to sustainability.
But I’ve seen so many death marches and overtime pushes I like the “no” part. But let’s get away from negative/positive, let’s talk about why this matters to creatives.
Because it is so important this means . . .
You don’t just say “hey, let’s be sustainable” and it happens. It’s something you work on – this principle reminds us to commit to it, to make sure we find a pace we can all work at, together.
This principle, despite the fact it’s a call to work appropriately, is also a call to work on sustainability. You need to take the time and effort to make work sustainable. You need to educate yourself on principles and processes to make things sustainable. Hopefully this is the collective “you” – all the sponsors, users, and developers in your creative work.
But it might be the lone “you.” Sorry, you might be the lone voice of sustainability and have to advocate. Maybe these columns can help, but let me emphasize that if you’re using Agile, keep reading up on it and researching it. There’s plenty of knowledge out there.
Note that this Principle means everyone in the project. It could just be you and one client, it could be a giant team and users/audience. So let’s talk about how the three different groups – sponsors, developers, users – can promote sustainability on a creative project.
Sponsors are the people asking for the work. It would seem their role is obvious – don’t overload people! Of course it’s not that obvious. Each of the three groups have different interactions on creative projects. So how can Sponsors work with the other groups?
Developers:
Users:
In promoting sustainable development, a good Sponsor is realistic, listens, facilitates – and doesn’t overload Developers. I won’t lie – sometimes you become a firewall or a funnel. Be a good one.
Now a few warnings. Where does this usually go wrong in creative works?
With sponsors covered, let’s get to Developers – which, my guess, covers a lot of my readers.
Developers make the creative work. Also an obvious role, but a Developer’s role is really kind of strange – they’re an expert in making something who often deal with people who aren’t. Thus you’re trying to give people what they want when they don’t know how you do it. Though they probably think they do and it drives you crazy.
Worse, you’re sort of in the middle of the Users and the Sponsors. You spend a lot of time making something for the actual target audience, you do research, so sometimes you end up as a bridge. When the User and Sponsor is the same (say, if you’re doing an art piece for someone directly), they can still seem like two different people and you have to bridge the gaps in someone’s own head.
(Ever have someone argue with themselves about a creative work? Probably.)
Finally, you’re probably the one most aware of any burnout, overload, or unsustainability, and you have to tell people about it. Sometimes those people aren’t happy with you. OK most of the time.
So first up, if you’re a Creative (and you probably are if you’re reading this), get ready to do a lot of psychology for yourself and for others. You do the work others don’t do, see things differently, and are kind of in the middle. However, to make sure your work is sustainable, you have to think about them.
Sponsors:
Users:
A good creative Developer is aware of their process and abilities so they can not only pace themselves, but pace themselves with others, and help others pace themselves. Because you’re where work happens, you’re the most able to understand what’s going on and what can probably be sustained. You just have to make the effort.
Now a few bits of advice for Creative Developers trying to keep a sustainable pace in Creative work.
It feels weird to even go into this part – this is pitched at Agile Creatives. That definitely covers Developers and may cover Sponsors. But Users? They’re the end consumer of a creative product. They may not be that interested in all this.
I include this however because you, doubtlessly a Creative of some kind, will be communicating with Users (and thus you can figure how they can work with you), and probably are a User at some point (and can work better with others). It’s my small way to bridge the Developer-User gap in Creative work. Whatever side you’re on, you can help the other side work better.
One thing Users forget is that they to have to have a sustainable pace, and it’s easy to think “I can handle anything” delivered to you because you want it. However, getting too much of a good thing is not sustainable – you can’t enjoy it, can’t give feedback, etc. You to, even as a pure consumer, have limits, and pushing those does no favors to the people doing work for you.
Sponsors:
Developers:
I don’t have a lot of other advice for Users promoting Creative Agile to use Sustainability except for this – remember you’re part of the process to. Working with others means much better stuff on your end.
Sustainable development requires everyone’s effort – and commitment. In a creative project, this is even more of a challenge. It requires everyone to get on board.
Of course if not everyone is on board, you’ll get to help with that because you’re the one reading this.
So let’s round up what we can learn:
– Steve
(This column is posted at www.StevenSavage.com and Steve’s Tumblr)
We’ve passed the halfway points! We’re now on the Seventh Principle behind the Agile Manifesto. It looks simple, and in fact is simple, which means I’m going to go on at length about it. Let’s take a look:
Working software is the primary measure of progress.
Yeah, it’s pretty clear isn’t it? I’m very fond of it because the idea is the measure of progress is something that actually works. No maybies, no charges, no plans, no mockups. Something that works is how you measure progress.
But let’s tweak it a bit for creatives, since creative work involves a wide range of stuff from art to presentations to films.
Usable products are the primary measure of progress.
There, not much of a change, but we broadened it out. You measure progress primarily by giving people things that are usable.
Now of course, I’m going to analyze the heck out of it.
Your efforts should focus on giving people something they can use and experience – that’s it. It’s usable/working/review-able or whatever you want to call it. That does not mean it is:
You may deliver work that’s incomplete and lousy, but at least each embarrassingly bad delivery there’s something people can use to give you feedback. You will improve it over time.
As you may guess this means . . .
Giving people something they can use, no matter how incomplete or half-baked, at least means you’ll get feedback on it. It may not be nice feedback, it may mean a lot more work, it may mean a change of direction. But at least you know what to do next.
So the more often you deliver, the better you do getting people to their destination – because you learn how to better get there. It’s a lot like navigation – in fact your customer or client may learn about what they really want once they have something they can really experience.
But it’s not just people who give feedback. You and your team give each other feedback. If it’s just you, then YOU give yourself feedback (even if it’s “that was dumb”). You also learn by making something usable as opposed to reaching abstract deadlines and milestones.
There’s nothing like having to make something workable to really learn what you have to do, and what you shouldn’t have done.
Now to do this . . .
So as you’ve probably guessed from reading so far, this Principle really hearkens to iterative development. You measure progress with usable product, so you’ll be delivering useable product over time – probably improvements of previous deliveries. That’s pretty common in Agile, obviously and we’ve already discussed it.
But this means that anything useable you deliver is something you should plan for and keep in mind. Don’t just work on something, work on it in a way that helps you give actual results as often as possible. This could mean:
So you can keep getting work out, do that work in the best way that keeps delivering useable results. Because when you do that . . .
Delivering usable products is the way to measure progress. There’s the obvious ones of “this customer is happy,” but you can also use this to get a bit more mechanical and procedural.
From simple lists of features to complex analysis, usable product is not just a way to measure results in general, but gives you a way to get specific results, maybe even complex ones that need some number crunching. Thinking in deliverables and producing them gives you access to a wealth of data.
Though I wouldn’t overdo it. This is Agile after all, let’s not get complicated.
Let’s review the Seventh Agile Principle for Creatives:
It’s another simple principle, but it’s really great advice – progress is producing something.
Sounds like you could overload yourself with trying to constantly get stuff out, right? Well, let’s move to the Eighth Principle . . .
– Steve
(This column is posted at www.StevenSavage.com and Steve’s Tumblr)
Agile principle #6 is a simple and sweet one about communications. It needs no embellishment:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is obvious. If you want to get the most done, effectively, talk to a person directly. I could probably stop here and you and I have easily discussed 70% of the value of this Principle.
Obviously I’m not done – and we’re talking Agile and Agile Creativity, so there’s some subtleties to go into. So I’d like to discuss this principle in a bit more detail, and focused on creative work. This probably would be faster if we were face-to-face, so revel in the irony.
It’s obvious that you get more done productively if you actually go and talk to people, and in-person conversations convey a lot of information effectively. In-person you can judge gestures, expressions, voice pitch and more. In-person you sync-up with people better.
When you communicate effectively, you say more, hear more, and can work effectively. You can adapt better because you’re actually talking to someone directly and saying so much more. I’ve seen team behavior change and become more productive when face-to-face activities are introduced.
In creative works are challenging to communicate because they involve everything from intuitive interpretation to understanding complex emotions. This makes face-to-face or similar far more important because there’s just a lot to convey. So if you have to collaborate creatively, get talking face to face
(As you may guess, I accept we can’t always get face-to-face, which means) . . .
Communicating with people on your team face-to-face sounds great. It’s also probably impossible at many times due to location, travel, mutual loathing, and what have you. So what do you do? You find the closest-way to face-to-face in order to interact. This could mean:
You do what you can. This may mean when it comes to creative works, you have to get pretty innovative. You may do things like sending people videos and following up with online chat, and it may not be face-to-face, but it’ll be as close as you can get.
Is this somehow violating the ideal? No, because . . .
This Principle is a recommendation and a statement of truth – face to face is the best way to communicate within your team. It’s not the only one, it’s just the best. Agile isn’t big on hard rules and structures.
But sometimes the best is not available, so you do what you can. Don’t fret, don’t beat yourself up over it. Just do what you can.
Does this matter to the solo creative? Actually, hidden within this Principle are two important lessons:
This simple principle is pretty easy to review:
Simple one there. Good, because the next Principle seems simple – but has a lot of depth. In a way it’s a core to a lot of Agile thought . . .
– Steve
(This column is posted at www.StevenSavage.com and Steve’s Tumblr)
All right now let’s get to what the Third Agile Principle and what it means for creatives, and continue our journey to apply the Agile Manifest to creative work.
I’m sorry, Third Principle of Agile Software. In fact, it’s kinda software-heavy Principle, which means for creatives we’ve got to rethink it a bit. Let’s take a look:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This is pretty clear: deliver actual stuff often. It’s just it assumes that you’re delivering software and that you deliver within a given timeframe. As a creative, you’re probably not delivering software, and we know all to well some creative works need delivery in compressed timeframes.
Let’s not constrain ourselves and think of the third principle this way:
Deliver useable work frequently, with a preference to the shorter timescale.
Pretty clear? Let’s break it down and see what it means from you. This one is *dense.*
Whatever you give to a client, customer, etc. should be something usable. It may be rough, it may be incomplete, it may be rather bad. But you deliver something they can use, even if upon using it they think “this needs a lot of improvement.”
So why are you doing this for them – and perhaps to them?
First, usable work gets you feedback. A (somewhat) useable product, like a logo or document, means people can evaluate how you’re doing and give directions – or confirmation. It may mean they can even put your work into use, which means they get feedback to pass on from other people. For creative works, which have so many variables, early feedback is important as it helps you navigate to completion.
(Shades of Principle #2).
Second, focusing on useable work focuses you on making things people want and need. What is the highest priority to do? What makes something “usable” versus just “better?” Asking these questions means you are more likely to focus on what’s important; developing a new logo that looks right is better than slightly tweaking RGB codes to get the perfect blue half the population can’t tell from most other blues.
Third, this focuses you on delivery. You have to figure how tomake whatever you do actually deliverable and accessible – which can be very revealing. Having to make something that people can use means considering everything from file formats to image sizes to spellchecked documents. You have to ask just what to do first and in what order. This is a great way to reign in your creative ideas and focus on something you can actually give solid form.
These three words are a great way to focus on getting the job done – delivering the right thing so you get feedback. It’d be great to get that early, in fact . . .
EXERCISE: Think of one of your latest creative works. What made it “deliverable” – and how much work did that take over doing the actual work?
If you’re going to actually give people a usable result, be it a comic strip or a piece of a costume, you don’t want to wait a long time for feedback. So when you deliver, whatever you deliver, however pathetic (but functional) it is, deliver it frequently.
Frequent delivery of work means the people you’re doing it for give you feedback more often. With more feedback, the next delivery becomes better (and perhaps faster). Frequent delivery means a dialogue, and enhances communications. In fact, frequent delivery can help lower barriers (psychological and institutional) as people get used to communicating and find new ways to do it.
This is very important in creative work as, with so many variables, communications helps direct your efforts.
With this frequent delivery, people also build trust. When a creative provides results to a client, even if incomplete, they’re taking the lid off of their process and giving people a view of how they work. When a client gives honest feedback that helps, the creative can trust them more. In both cases things are much more open and obvious.
This is very important in creative work as, with so many options and directions, and with work often being personal, mistrust or miscommunication can occur too easily.
Behind the scenes, thinking Frequency also means you restructure your work so you can deliver effectively. This can be challenging and even contradictory, say delivering the later chapter of a book earlier as it’s easier to do or more vital. But when you think frequent delivery, you think about how to deliver better.
“Frequently.” That one word in the Principle covers a whole lot.
EXERCISE: Think of someone you worked for where there was a lot of mistrust. How could more frequent deliver or communications have helped lower that mistrust?
Well if you’re delivering all this useable work frequently, getting all that feedback, thinking how to make things deliverable, you also want to do it as often as possible. The shorter the better.
This part of the principle accelerates all of the other benefits:
If there’s a challenge, it’s deciding just how frequent you really need to deliver. This is something to figure out between yourself, your client, any co-workers, and harsh reality.
This “more often” can get pretty common. After all you could optimize work to deliver daily or every other day. You might work directly with a client for a time or for an hour each day. If it works and delivers value then give it a try. In creative work, the more feedback the better.
By the way, I reccomend the timescale you use be regular if possible. Having an idea of when you meet, or when someone is editing a document, or when you have to send a file increases predictability.
EXERCISE: How fast do you usually deliver work to a client, and why do you work in that timeframe? Have you tried other timeframes – or any?
Delivering useable work frequently sounds simple – perhaps one of the simplest ofa the Principles, but it like all Principles it has hidden depths. Frequent delivery of useable work does everything from making you consider your work to enhancing communication. Besides, if you get anything wrong on the work or anything else, you get that fast feedback.
Work with people, clients and co-workers, to get that rapid and effective delivery into your creative works. You’ll be glad you did – or if you aren’t glad, you will be iteratively.
So in review:
– Steve
(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.
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?
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:
So to review:
EXERCISE: Take one of your projects and ask yourself what are five ways it could have been more change-responsive?
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.
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:
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