Many posit that Agile was born at Snowbird 20 or so years ago, but Agile project management processes have existed in one form or another for a long, long time, nor is there one right way of implementing Agile. From the accounts I have read and people I have talked to, many use the aspects of Agile that work for them rather than applying it in its most distilled form.

This, IMO, is the most effective use of Agile. If you can’t customize a work process, how is your work prioritizing people over processes or results over documentation (supposedly the heart of Agile)?

In my past life, I worked as a costumer, among other theatrical positions. Since that time, theatrical management processes have pervaded my intuitive management philosphies. Come to discover, many of these are Agile processes. So, here are five Agile management processes I learned from the theatre.

1. User Centered Approach: Audience First

“Can you see it from the middle of the house?” is a question as inimical to theater as the phrase, “break a leg.” The house would be the theater, and the middle would be where the majority of the audience resides. So seeing things from the middle of the house refers to the practice of making sure the product is usable (in this case visible) by the greatest concentration of users.

“Seeing things from the middle of the house” refers to the practice of making sure the product is usable by the greatest concentration of users.

This user-centered approach is something that many other arts don’t practice nor is it always common practice among producers of products or services. Can you imagine an abstract artist wondering, as he circles his ginormous canvas dripping paint from a palette knife,* if the majority of canvas viewers will be able to see how even the drip patterns are from the vantage point of five feet in front of a museum wall?

I may also may have heard of the experience of a public relations rep who, having organized a press conference to showcase a new hospital, watched alongside the press with disbelief as hospital staff moved a patient bed into an elevator only to find that the elevators were not big enough to hold the hospital beds…

2. Frequent Iterations

The theatre has build, development, and testing process just like any other product or service. These iterations are seen in so many places throughout the theatre industry it’s almost dizzying.

Before a script is even licensed for a company to perform, it has already gone through multiple iterations and readings in front of audiences to hone its effect.

Every theatrical season offers more than one play with a run of generally a few weeks to a couple months, the response to which will then provide the producers with feedback in multiple areas:

Audience response to a production topic/style
Employee satisfaction with various designers, managers, and actors
Audience engagement with particular actors
Audience experience with the theatrical space or production studio

Every production is a chance for the producers to gain feedback and adjust their product to better achieve desired outcomes, whether that’s profit margin or refinement of production techniques.

3. Working with a Product Owner

The ultimate product owner can really be found in the theatrical (or film) producer. Their drive to see the product not just survive but thrive is no different than the passion and understanding a product owner usually exhibits in representing the intended audience or desired outcomes of their product to the production team.

A producer can have multiple productions going on at once or one main labor of love at any time. The producer works with directors, costume and technical managers, and designers, all of who are essentially extensions of the product owner, rather like the technical, functional, and business analysts on occasion used by an Agile product owner.

4. The Postmortem (aka Retrospective)

Retrospective or postmortem? I really like the term postmortem, but maybe it’s just ‘cause we use it in the theater? A well-conducted post-mortem (OR that most Agile of postmortems, the retrospective) is more than just a dissection of the production process and end product, it’s an evaluation of decisions and practices that worked well.

I did wonder why theatre has a post-mortem and everything else has a retrospective (or that most pedantic of phrases a “lessons-learned” evaluation). My theory is that it has something to do with the fact that medical autopsies and operations were once conducted in a space called an operating theater.

Due to the novelty of autopsies/operating procedures (and dare I say the drama?) and the interest they generated, early operations were often conducted in a gallery-style area constructed like a theater for public viewing and instruction. Technically, gallery style seating or theatrical seating was the original classroom/learning structure.^

Via this association, it’s clear why theatre has a postmortem rather than a retrospective.

5. Scalability

When you initially study or implement Agile practices, it’s difficult to think about it in use on a larger scale but having worked in the theatre with multiple productions in process at any one time involving multiple teams, processes using Agile are very, very scalable. It’s a bit like observing our solar system in action. You may think things will collide, but everything generally runs quite well or is altered (based on frequent feedback iterations and postmortems) to fit the needs for which it is being used.

While any aficionado of the theater can tell you there is generally a lot of drama no matter what the product, it’s also amazing that theatre has survived not only this long, but with a very intact and well-founded management structure.

Considering how many iterations have been conducted in the theatre just for the past 50 years, I’d say the industry has impressively honed management practices.

So if you ever want to spend some time truly working in an energetic, fast-paced, cutting edge industry, try the theatre. You might be surprised what you learn.

*A process used, in fact, by the artist Jackson Pollack https://www.sfmoma.org/jackson-pollocks-drip-painting-process/

^Follow that thought train a little further: What does that make theatre in its original form?

First There Was Common Sense (C)

I’ll admit—when I was first required to learn a “new” project management methodology, I was less than pleased. In my mind project management = common sense, something every organizational fiend pretty much has in hand. But seeing that the tide was not going my way, I determined to hop the band wagon. (I could always offer sarcastic comments a la mode.)

Come to find out, much to the chagrin of others, Agile methodology training was the most validating thing EVER. I MEAN EVAH EVAH.

First of all, these people embrace a principle that every project manager is wedded to: The art of saying no. Here are a few other things we definitely believe in common:

Good project management starts with budget and timeline at top of mind rather than designing the perfect project to build.
Specialists, and the team, should determine the best way to achieve a desired outcome rather than the person “in charge”.
The product owner (or account manager or marketing manager) is the main spokesperson for the product/project/client.
Team members can participate in multiple sprints related to multiple projects.
Scrum is not the only Agile way to manage projects.
More people can be involved than the product/project owner, scrum master, and scrum team—in Scrum they are called the technical analyst, the business analyst, and the functional analyst.

Agile training was like nirvana for geeks experienced in real-life management. (Shout out to the Agile Dad company whose foundations training in Agile is outstanding.)

Agile Helps With Hang-Ups Project Managers Face

Project management can get hung up on all sorts of stuff and Agile methodologies do offer some common-sense ways to cut through the noise. Here are some examples:

Processes & Checklists

As a certified PMP, I can attest to the number of processes attributed to “traditional” project management.* They frequently involve lists and lists of lists. Agile posits that if something has been in a backlog forever without getting done, maybe it should just be removed from that backlog, ‘cause how important is it really?

Agile also suggests making processes work for you. If your team likes a process that is less Agile-based and more team-based, as in makes more sense to the team as a way to do things, then your team’s ideas should be prioritized over codified processes. We value people over processes. (Find this in the 12 principles of the original Agile Manifesto.)

Deadlines

Deadlines can create all sorts of stressors, particularly if you are working with a difficult sponsor who refuses to stay in scope. I have worked with numerous stakeholders that are impulse driven. They personally function much better at the last minute. Unfortunately, I have never seen anything come about through this method that couldn’t be done during reasonable work hours with proper planning. (The theater is rife with this sort of mismanagement.)

Unreasonable hours and expectations also lead to burnout and dissatisfaction. Simply put, the stakeholder’s need for a high rarely results in a better functioning or higher quality product. Production under these methods also frequently leads to a lot of time and resource waste, because impulsive decisions beget fractured vision and lower quality work.

Agile suggests literally completing the simplest foundation for the product or service first that can reasonably be presented and then adding to it over upcoming periods. While this may take the wind out of some ego-sails (who shouldn’t be managing the project anyway), it will result in a higher quality product built through sustainable practices.

Aside: In a recent visit to the San Francisco Museum of Modern Art, I was reminded that the pop-culture artists subscribed to a similar theory—rather than wear their valued selves out as a commodity, these big names started studios where they delegated the production of their work (this might be likened to automation in Agile).

The SFMOMA’s curator summarized it thus:

Such arrangements shifted the emphasis from the creators to the means of production and provoked a dialogue about the nature of art and its position within American culture.^

So did the Agile management philosophies question the traditional project management school of thought.

Scoping & Complexity

Any and all estimates are guestimates. You can scope a project down to the very tiniest details, but there are so many variables that scoping can be truly a time suck. In the particular corners of Agile I explored, the practitioners recommended what they called story points (features or tasks scored by points). The tasks or features could be measured through likening T-shirt sizes to tasks or estimating complexity through planning poker.

I say, just straight up, rate tasks by complexity, which could be defined by:

number of entities you engage with,
difficulty of task,
skill-level, and
the like.**

It may be a hard concept for some team members to grasp as it’s a method of taking abstract or unknown quantities and quantifying them, but I believe everyone can learn it to some extent. (And grappling with playing poker cards based on the Fibonacci sequence, which on the cards go up to 400 pts, can give you a brain fart on an equivalent scale.)

Complexity scoring is also a guestimate, just like every other measure of scoping. There is no perfect equation; HOWEVER, if you have a project manager who has worked with a team for awhile, her gut guesses will most likely ring true. (Or maybe just mine have over the last year or two.) This is because the person engaging with the team’s actual work on a regular basis will have a good understanding of team capabilities and work that can be accomplished.

Stakeholder Engagement

Stakeholder engagement is really so very individuated per product and project, it’s almost impossible to quantify. Agile tries to simplify it by having one product owner who is the speaker for the stakeholders or at most a product owner assisted by analysts. Agile also makes some recommendations for project delivery: Must-haves and then should-haves followed by could-haves and would-likes (MoSCoW acronym as delivered by those Agile Dad peeps).

Personally, I find that getting the foundations of a project done and then delivering something desired (but probably unnecessary) is the key to most stakeholders’ hearts. Appease the revenue makers, but then deliver some frosting on top—find a political goldmine that’s relatively simple and make good on that.

While we (project managers) can’t be the heroes, magically rescuing our stakeholders from bad situations they find themselves in, we can still make ourselves look good if we manage it right. Substance delivered with a little style…

Power to the Vocab

The most fabulous thing about Agile is being able to explain the methodologies to other people. Somehow the vocabulary impresses people. You could have run multiple amazing projects and accomplished feats not truly understood, but until you can also spout industry vocab, you will always be second place.

True Agile aficionados may claim that Agile was born at Snowbird in Utah with the release of the Agile Manifesto in 2001,^^ but the rest of us know that before the alphabet (as we know it) was introduced, other systems and processes have been continuously evolving. (Let me tell you sometime about management processes in the theater. I swear I learned everything I know from working in the theater.)

I do believe that everyone can find significant value in formal training in Agile methodologies, but I also know that practical common sense is an undervalued commodity in business today. And don’t forget the layer that experience adds to the mix. All the training in the world can’t compete with real life experience and/or familiarity with the type of work being done.

So, A may be for Agile and B for its Birth, but C is most definitely for Common Sense.

*Quotes courtesy of the fact that while there is a codified project management philosophy, many of us use combinations of common sense processes that might be classified as the old school way to manage projects, but which are really processes streamlined through experience that use techniques from the whatever-works-best school of thought.
^Taken from curatorial notes at SFMOMA about the pop art exhibit. Feel free to contact me if you want a photo of the text as I took a picture of the exhibit description on the wall!
**Complexity scores were something I learned about via a project management team in the healthcare organization I work in. They are also a measure of common sense. For example, if you are at the grocery store looking for the shortest line, making a judgement based on which line appears to be moving fastest ain’t going to cut it. The interaction between cashier and customer generally takes longer than actually scanning merchandise. Although, really, even self-check out can take just as long…
What’s Up With That: Why You Always Seem to Choose the Slowest Line https://www.wired.com/2014/07/whats-up-with-the-other-line-is-always-faster/ via @WIRED
^^https://en.wikipedia.org/wiki/Agile_software_development

Tag: Agile

5 Agile Practices I Learned From the Theatre