Having just finished Austin/Devin's
Artful Making, I've been thinking a lot about freedom and creativity. In the past I've argued we need
creative slack to make anything truly new--and this book backs that up. Beyond that, it shows how slack plus discipline is the perfect recipe for software development.
Software Development is Artful Making
The core metaphor in the book compares software development and the production of plays--and since the theater cited in the book is in the Philly region, I took advantage of going to see the People's Light & Theater Company first-hand for the opening night of Steinbeck's
Of Mice and Men. Before I comment on the play itself--I have to mention this theater company produces 7-9 plays per season--and that sheer volume of new projects is fascinating. I've known development teams that can easily make that many releases in a year--but normally that's for one product line. Is People's Light unique? Just out of curiosity, I also counted plays per season at other local theaters (Walnut St. Theater, 5 each on 3 stages; The Lantern Theater Co., 8; The Arden Theater Co., 7 each on 2 stages; The Philadelphia Theatre Company, 4; The Wilma Theater, 4), and see that this productivity is above par, though all these theaters are producing a lot more new products than a typical software team. Since the director and cast vary from production to production, maybe it's better to compare this high productivity to several different software development teams managed by the same business owner/director. Still, it's impressive that the same producer can support so many new products year after year. For some reason I imagined a lot of theater companies run like the Broadway venues, showing the same thing year in and year out--just like many large businesses run the same product lines for years. As Geoffrey Moore points out in
Escape Velocity, product inertia poses problems as a product nears end-of-life, because business leaders are caught with the dilemma of diverting money from predictable revenue to new product development, but at the same time dwindling revenues make it clear that new products are needed. It is this new product development that requires creativity--and artful making. For these Philly-based theater companies, releasing 5 or more plays per season, they've also got more opportunities to succeed by running more shows, just as the lean startup process teaches us to pivot early and often.
Great Innovation Requires Safety
Regarding Steinbeck's play--I had already heard about the culture at the People's Light, where actors and directors support experimentation, spontaneity, and the creative process in general--but I didn't realize how bold they would go. I was impressed that they included a dog on stage and used a mechanized, slanted set designed to evoke the rugged Western setting. I hadn't read the book since I was in high school so I had forgotten much of the plot--but was reeled in by the re-enactment of the actors. Every character in the play is seeking emotional intimacy, except for best friends George and Lennie, and it is so ironic that each of these people were looking for exactly what Jim & Michele McCarthy said during
Boot Camp: we all seek love. The great thing about a loving team environment is it allows us to voice our scary ideas--and this is what's needed for disruptive innovation. It's clear that the ensemble had shared their scary ideas with each other to execute a flawless performance that was both emotionally and intellectually compelling.
Great Innovation Requires Structure
Compared with software development budgets, a play is run on a comparatively low budget, even though both have to create something that has never been done before, with people who are mostly motivated by the work itself. When software teams work in the same way, the constraints of budget and schedule do not have to limit creativity--in fact, under schedule pressure, we need to relax our ideas of system requirements and move to solving the customer's underlying goal. This gives us lots of room for creativity, learning, and energized/joyful work--assuming management doesn't kill the team spirit.
How does management support the team? Demand iteration--let the team know that the first version is not the final product, and that it will help us see where to go next--we expect we'll need improvement after each iteration. Collaboration goes for both colleagues and managers--software team members often have many skills the manager doesn't, and the manager has to be OK with letting go of control. Straight from the book:
- "don't try to get it right the first time"
- "make it good before the deadline"
- each iteration is a chance to make something a bit better
- artful making (as opposed to industrial making) makes sense only when we have a task that needs to be repeated, it requires innovation, and there's a low cost of iteration
Great Innovation Requires Freedom
The other day an acquaintance who also does work with one of my clients said that this company works people to death--and it didn't really hit me until I noticed what we have in the break room. Does this support personal safety? Why is there a defibrillator in the break room? We're supposed to work until we can't possibly work any more? Why are there no windows in this break room? Why is it so small? Clearly, this employer doesn't want us taking any breaks!
What I've seen in this environment is that people feel like they've got no freedom--they're forced to work in ways that are less than the best they know how, and their passion for the work suffers. Managers are becoming increasingly frustrated by the poor output, and are reacting by adding more rigidity. Though we do need discipline, Scrum teaches us that it must be enforced at the right time and place; Scrum rules keep "chickens" out of daily stand-up meetings and out of the implementation details of the project, as well as off the sprint backlog once the sprint has been determined. In order to really perform, teams need space to create. So forget about project control, let go of your expectations! Release! Reconceive! Promote security, embrace uncertainty, and insist on fiscal responsibility (timeboxes). Give the teams room to create, and get out of the way. Review stories as they finish, so there's room to improve before the end of the iteration--yet if something isn't right by the end, don't accept it. Most of all, insist on finishing something early. Failure to deliver is bad for everyone involved--customer and developer alike. Developers are motivated by progress! Clear feedback will allow the teams to focus on a great product.
Oh and consider how many of the great ideas, the scary ideas, first get voiced during coffee break! Give your teams more safety, structure, and freedom!
On the way to Agile NYC Open 2012, even though I was prepared to be surprised (as per the ground rules of open space, pictured below), I was taken off guard by this surprise. Open Spaces are a meeting format that promote learning and engagement--using simple ground rules like "The law of two feet"--when you're not getting what you need from a particular topic, move on! Other rules help us stay present without judging: "Whatever happens is all that could have"; "Whoever comes is the right people"; "Whenever it starts is the right time" and "When it's over, it's over". Open Spaces can be used at conferences or in the office--they're dynamic and fast-paced, and at Monday's event, learning/decisions were captured during the day in a "news room" as well as reported on in a photocopied packet that attendees took home.
In the past when I've attended Open Space events, I've been a bumble bee. This means I sample one topic after another, moving like a bee buzzing from flower to flower, collecting nectar, and maybe even dusting other flowers with pollen. The surprise for me this time is I felt like being a butterfly. Butterflies don't really participate in the open spaces at all, instead they socialize at the periphery. One could argue the peripheral discussions became their own open spaces--it's just that the topic wandered and wasn't posted at the market place. Part of what makes Open Space so powerful is that there's an opportunity cost to participating in any given topic--at Agile NYC Open, there were always 5-7 topics running in parallel, as pictured below, with 1-hour session slots. This can be frustrating for attendees when there are several interesting topics--but it also means that participants tend to be only where they really want to be--and this fosters open communication, connection, and passionate discussion.
Topics at an Open Space conference can be convened by experts or novices alike. The magic is that the right people show up, and everyone learns. To propose a topic, the day begins with a quick introduction of proposed topics, posting of topic titles on the Market Place (a grid of time & location), then a round of sign-ups or dot-voting to show how many people are interested in the topic. Topics can also be proposed later in the day--it's just that these late topics aren't accompanied by a verbal introduction to the topic. Then at the appointed time, conveners show up at the Open Space they signed up for with a clipboard to record attendees' names and major insights of the discussion.
As I mentioned previously, I was a butterfly this time. I spent most of my time with fellow boot campers Frank Saucier, Dan Mezick, and Venessa Miemis. While there were plenty of topics we discussed, what I'm most excited about is a project we're working on for Agile NE Corridor... ultimately it's a way to find out who's willing to commit to producing great work, who's willing to commit to change in the workplace, and who will help us make work more fun and life-giving. We're working on ideas that anyone can implement now at work, and we'll have a strong bias toward action over theorizing and planning. Stay tuned for more, or contact me to help out!
