At my Agile/Scrum class (product development methodologies) today, I encountered a very lovely book, Artful Making by Rob Austin and Lee Devin. Lee Devin is a director of theater and Rob Austin is a professor at Harvard Business School. The two of them together wrote a book on management, but while it is nominally all about business, there is a great deal in there that is mindful to art as well. (In fact, it illustrates quite well how art and product development can flow in the same manner, and face many of the same challenges. I’ve been aware of this for quite some time, but it’s nice to see it put so eloquently into words.)
I didn’t have a whole lot of time to page through the book at lunch hour, but this paragraph caught my eye in the few moments I had to flip through it:
There are several things to notice about Adams’s approach. First, she intentionally avoids preconceived notions of the play as she enters the process of making it. Rather than trying to get the production to conform to a preconception, she orchestrates the creation of a play that will be a direct function of the available materials, the actors most significant among these.. The play that results from the work of a particular company of actors will be different from the one that might emerge if there were a substitute for even one of those actors. Adams enters early rehearsals with ideas about how things might go, but she deliberately avoids defining her notions in detail. Her process emphasizes immediately reconceiving everything in response to what she sees as newly possible, with each passing moment of a rehearsal, as a result of each thing tried.
Can there possibly be a better expression of an artist’s approach to art? In weaving, as in all forms of creative self-expression, there is a dialogue between the artist and the material, which changes as the work progresses. And a good artist, whatever the medium, has to relinquish desire for control, that clinging to a specific outcome, in favor of improvising in the moment – being flexible enough to seize opportunity when it arrives and to change quickly when the path is wrong. This is true whether you are creating handwoven cloth, a painting, a book, or (dare I say it?) software.
I like the Agile/Scrum development methodology precisely because it emphasizes flexibility, empowerment, and facilitation rather than hierarchy and precise requirements. It is an artistic process rather than a controlling one. In the conventional, “waterfall” method of software development, a detailed set of requirements is constructed, then the software is coded up to match the requirements. Change control is a major requirement for this software development methodology – because the requirements always change during the course of the project, or a needed resource is not available, throwing the whole thing off. This is roughly comparable to, say, starting a wedding dress by specifying everything about it and then trying to weave/build the thing exactly to spec, on a schedule. It doesn’t work. Things happen, yardage is woven and then has to be discarded, the original design turns out not to work and has to be redone. It is little surprise that waterfall projects tend to be delivered late and without all the originally planned features.
Agile development, on the other hand, rely on iterative development in “sprints”. Each sprint is planned to be quite short – a few weeks at most – and has to be a working, testable component. A running list of the “product backlog” (features that need to be built) is evaluated at the start of each sprint, and features selected for production during that sprint only. In this way one is never tied down to a plan for months and months – instead, every few weeks (which is quite a short time, for software development) you have the opportunity to change. This is a HUGE contrast with conventional waterfall projects, which average a couple months to a couple of years, during which only limited changes can be made.
So I am seriously thinking about rethinking the wedding dress into similar “sprints” – starting with the wedding-dress fabric, which is the highest-risk item, and also the one that is most vital, and then moving on to the second most fundamental item, the dress pattern. By breaking it down into pieces and re-evaluating things after each iteration, I’ll be able to maintain flexibility and make sure the highest priority item is on top. I’ll also have a lot of variety in what I’m doing in each “sprint”, which is important given that the project will take about a year (best guess) and my artistic attention span is about six months.
This isn’t so far different from what I had intended to do anyway, but having a framework to set it into is quite helpful – I can actively prioritize what I am working on and break it up into specific periods of work, rather than wandering at random. “In this period I will weave 10 yards of the dress fabric.” “In this period I will design the dress pattern.” And so on.
It will be interesting to see what develops from the second (and, sadly, last) day of the class…
I did title the post intentionally, by the way. It’s not just about creating something (e.g. a play in the theater), it’s about playing as well, while you’re making it. Agile allows room for a lot more playfulness and spontaneity than the other approach. I think this is important to remember, when you’re creating art, and in this respect software development is no different from other art. It’s essentially a creative process, albeit one driven by the marketplace, not by “artistic vision”, whatever that may be.