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
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!