Two weeks ago, Daniel Lieske, one of my favourite artists, posted something very interesting in his blog. Daniel works on a graphic novel called The Wormworld Saga of which he has released three chapters so far. For the fourth chapter he has changed the way he works.

Iterative and incremental

On the first three chapters, Daniel worked in a strictly linear fashion. He did some preliminary work (writing the story, …), concept art and then the final art. This has some drawbacks:

This approach puts a lot of pressure into the first few weeks of production because you want to make sure that your prelim is perfect before you go on to the next step.

Ok, so there are drawbacks with this approach, but it already is what we (software developers) call iterative and incremental: Every chapter is an increment that adds value to the final product. Those increments are created using an iterative process: The same steps are repeated for every chapter.

We probably would not call this process “agile” because the iterations are rather long and the anatomy of a single iteration is quite rigid and linear. But for some organizations who introduce Agile this is exactly what they strive for: A predefined process they can follow step by step. But, as I said before, this is not really agile development. Anyway, this fact alone should not drive you away from a process like this: After all it can produce great results. Just have a look at the first three chapters of the Wormworld Saga (I’ll wait here) - They are awesome!

It can be done even better still. You still should be skeptical of long iterations which consist of a linear sequence of steps. Because this can - and probably will - cause problems. Just like Daniel found out.

Time to change

During the work on chapter 4, something happened:

For the first time I managed to totally screw up the writing. As always I presented the first draft to my wife. Normally she would point out a bunch of language issues but would generally like the result as a whole. This time she took a serious look at me and said "we have to work on that!".

This is something that (i guess) happens on every project: Something goes wrong. You created something that just does not work. Maybe you even created exactly what your customers have requested. But now they saw it and realized that they want it done differently.

In some organizations the default reaction to this situation is to simply ignore it. Pretend that it did not happen. In other organizations the development team would have a strict change management procedure: Of course the customers can get the changed functionality. They just have to light the black candle, admit that they were wrong and sign a contract with their blood. And in even other organizations finger pointing and political battles start.

Daniel Lieske works alone, so none of the above would work for him. So he has to do what some (successful) organizations do: Adapt.

Just in time

What I actually realized is that I don't have to arrive at a final version of the prelim in order to be able to do the concept artwork. A first draft is normally enough to line out the set pieces, characters and interiours of a chapter. Additionally, doing the concept art alongside the writing can give you a lot of creative impulses for the writing.

This creates something like short iterations within the longer “release cycles”, where a release is one chapter. While still working on the story, he already creates concept art and final artwork where possible. And he uses the insights he gains in the later stages to influence the story. And for the first time he shared concept art from the chapter with the general public while still working on that chapter. Now this sounds a lot like agile software development to me!

I'm even thinking about going a step further. It turns out that there are certain portions of the prelim that just work straight from the first draft on while others get overworked a lot. What I'm thinking about is not to work on the final artwork in a linear top to bottom fashion as I'm used to but starting the final illlustration process on the finished parts of the prelim and keeping the other parts work in progress as long as possible. That would mean that I could work on the prelim even if I have already started the final illustration process.

I was quite impressed by this blog posting because of two things: First, you can use an agile approach to create a work of art. And second, you can arrive at this agile approach by just reflecting on what happened and applying common sense solutions to your problems. You just have to have the power to change what does not work!

You might be also interested in:

Learn more about how I can help you save money and earn money by applying new ideas to your agile development process.