I figured out something. I figured out how to learn everything that you need to know about the best practices in software development in 3 days. It's called the Edmunds All Company Meeting.
Allow me to elaborate.
The Edmunds All Company Meeting is the semiannual gathering of all 400+ Edmunds employees. We gather together in the Summer and in the Winter to get the latest information from the CEO, COO and President about the past performance, present state and future direction of the Company.
The 2010 Summer and Winter Meetings, of which I was the producer, were held at the Broad Stage nearby in Santa Monica. The Broad Stage is a very professional venue capable of hosting anything from a traveling Broadway production to any corporate event.
The Meeting is a big deal...a big expensive deal that involves the efforts of many people. We had designers working with the executives creating the Keynote presentations. We commissioned a production company to make a complex graphical video, the Edmunds Way. (The video outlines the future philosophy and direction of the company.) We added extra musicians to support the employee-musicians of the Edmunds Orchestra that plays throughout the meeting. Edmunds employees served as stage hands and production staff.
All members of the meeting, production staff and executives, spent weeks in preparation for the event. The culmination of the preparation was a night spent in the studio in Orchestra Rehearsal and a full day spent in the theater in what we call, "Dress Rehearsal", and then the Day of the Meeting. For all intents and purposes, the All Company Meeting is a fully fledged theatrical production. In terms of a full staffed production, we had 3 days to prepare and perform.
So you may ask, what does any of this have to do with software development?
Software development and theatrical production have a lot of things in common. You get an idea in your head about an experience that you want to create. You spend time, money and lots of people-hours working to make the idea real. Then, after all the money is spent and the preparation work is done, you put what you've done in front of an audience. If the audience likes what you've done, you continue, it not..... well, the show closes.
It's all about curtain time/ship date. All the time invested, money spent, hours worked does not mean squat if the show does not go on. In fact, if the show does not go on, if the software does not ship, the entire effort is one big, expensive waste.
So again, what does all this have to do with software development?
Effective software development teams tend to look like high functioning theatrical productions. The term "they've been bitten by the bug" is applicable to both groups. Individual motivation is high. All participants have a clear, common idea of the production process, what the final product looks like and all understand each individual's role in the production overall. Most times awareness of the production is so pronounced that members can function in many roles and can "fill in" for others should the need arise.
Mitigating Risk: Understudies and Backup
On the practical end, mitigating risk is a continuous undertaking in both environments. Producers/managers are always asking, "What happens if Joe or Jane gets hit by a bus?" In the theater the major roles have understudies. In a well run software development team technological expertise is distributed. No one head holds mission critical knowledge.
No production is ever comprised because an important piece of equipment malfunctions. Nobody goes on stage at a Rolling Stones concert and says "Mick can't sing tonight because we blew the amps!" The Edmunds site does not go down because we lose a server. Just as there is always a back up amplifier, we have backup for all of our hardware dependencies.
For me the most telling aspect that a theatrical production is software development by any other name is the paramount importance of reliability-- that the investors and audience can rely upon the crew and cast to ensure that the show will go on...no matter what.
reliability = (showing up on time) + (being ready and able to do what is expected of you) + (letting others know what's going on with you)
Allow me to elaborate some more.
(showing up on time)
Keeping an entire production crew, theatrical or software, waiting for you to show up to do your job wastes time and costs money. Professionals show up on time, if not early.
(being ready and able to do what is expected of you)
Drunk talent in a dressing room sucks. A developer zoned out playing Mafia Wars sucks. 'nuff said.
(letting others know what's going on with you)
Leaving the theater during rehearsal to go to the bathroom without telling anybody that you are leaving means that the production crew gets to play, "Where's Jerry? He was here a minute ago. We need some lights adjusted."
Going offline during a critical deployment means the development team gets to play, "Where's Mary? Her code is not building. We need to tell her to make a change. It looks like she's on Instant Messaging. But she's not responding."
Neither of these games are fun.
Software Development by Any Other Name
It's been my long held belief that if you can be a reliable member of a theatrical production, no matter the role, large production or small, professional or amateur, there is a good chance that you'll make an excellent member of a software development team. Yeah, you have to know code and code related stuff to do software. But the core desired behaviors exist in both environments:
- being willing to contribute to a common vision
- showing up on time, being able to perform as expected
- being able to take and give direction
- not disappearing unexpectedly
- making a commitment that no matter what, the show must go on.
So as I learned in my 3 days producing the Edmunds All Company Meeting, "The show that does not go on, isn't" and "software that does not ship, ain't".
1 comment: