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:
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:
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
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 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!
Read more about agility, incremental development and small steps in my book “Quick Glance At: Agile Anti-Patterns”: Buy it now!
You might be also interested in:
- We don't need a foreman: Several reasons why the idea that agile teams need a "foreman" is misguided.
- What is an estimate, anyway?:An introductory blog post about estimating development effort.
- Quick Glance At: Simple Design: A series about simple software design.
- Improve your Agile Practices: A FREE course that teaches you how you can improve as a software development team