Search This Blog

Monday, May 27, 2013

Agility outside of Software Development: A case study from a Theatrical Play

In the ever-growing need for agility in today’s business context, the principles espoused by agile Manifesto have emphasized enhanced productivity, increased customer satisfaction, and improved profitability. As noted in the previous blog entries, these principles are so entrenched from the software development practices that one of the foundational agile manifesto principles values working software over comprehensive documentation. Does this mean then that IT projects establish the glass ceiling for the agile principles?

As a member of the Chicago Tamil Sangam’s recent venture to stage a historical play, “Ponniyin Selvan” (n.d.) that was staged on May 4, 2013, we staged a historical play in the Tamil language. Centered on a course of events that took place several centuries earlier, the play presented several unique challenges that were overcome by applying some basic agile principles breaking the glass ceiling demystifying how these principles can extend outside of IT projects.  

The limelight of the play was its backdrop set in 11th century Chola Dynasty in ancient India that weaved several challenge threads, such as the following, that needed to be collaborated to allow the finished fabric shine.
  1. Preparing rich costumes, jewelry, and artifacts to differentiate the Emperor, the Kings, Queens, Ministers, and workers that required coordinated efforts to identify the needs among the actors, procure items necessary from India, and get them shipped from India.
  2. Identifying the needs of the auditorium based on the play requirements, distance, transportability and audience needs
  3. Designing several high-end artifacts that were transportable with easy assembly, such as preparing backdrops suitable for the play, two boats that moved, a ship with effects to display shipwreck, a palanquin as an entry point for the character, and pillars establishing the authenticity of the 11th century
  4. Rehearsing the play spread over five volumes perfecting dialogue delivery, enunciation of words, clarity of voice projection, light cues for various spots on the stage differentiating progress of characters and events through various backgrounds, preparation and coordination of musical clues, singing and dance choreograph appropriate to the characters, body language clues collaboration such as when to pass the message card or the crown, how various characters should see during critical scenes, 3 full length exams including a daylong marathon practice sessions.
  5. Advertisement and marketing efforts on social media, press, and soliciting appreciation from prominent external representatives, such as the President of India, increasing the reach
  6. Subsequent preparation for the main event date with food and supply for the crew, makeup needs, and transportation of goods, stage preparation, and coordination of light clues with the auditorium crew that didn’t speak the regional language, backstage line up of cast during the play informing what scene is in progress
  7. Addressing challenges for audience lineup, food distribution, parking lot and law & order challenges
Do any of these resonate with agile thinking that many reserve for software development projects? Let us revisit the Agile Manifesto (n.d.) and evaluate against this stage play.

Evaluation of the First Agile Manifesto Principle
The first Agile manifesto principle recommends “individuals and interactions over processes and tools.”  While following the audition, the characters were formed, several self-organized teams evolved that took on preparing specific artifacts. While marketing team operated separately from the teams that designed the costumes, prepared the ship, palanquin, backdrop, pillars, and boats, every team led communicated updates through the distribution group, on specific phone conferences, and provided incremental updates. So much was the focus on the individuals and interactions that when one member felt challenged by a work schedule, business trip, or a family emergency, there were so many willing and helpful members that came to assistance. Every team meeting ended up with a summary of the next action items following the same basic principles of what progress has happened, what progress is expected before the next meeting, and what the challenges were trying to create a win-win situation for all.

Evaluation of the Second Agile Manifesto Principle
“Working software over comprehensive documentation, “says the second Agile manifesto principle. While it is true that iterative delivery of working software makes the user experiment with the software mitigating the risk of failure, enhancing speed to market, and satisfying end user experience, can we rethink what software is? 

How many of us will travel on a bridge that is functional for the first 200 yards, but the remaining 100 yards are not yet constructed? How many of us are willing to buy a book that has the first three chapters written but the next 3 chapters are in script review? As you can see, in some cases, the end result has to be a fully functional system or product and not a partially working product. This play required that all the 50 scenes are seamlessly orchestrated and not just partially done. However, the challenges of the working individuals that made up the cast or the stage preparation crew that had overlapping members with cast, required we divide and conquer using iterative releases.

Dividing scenes of the main events in the play, the cast was informed to memorize the lines, rehearse their dialogue, and practice their songs with every weekly iteration and monthly releases over approximately 6 months rehearsing specific scenes in the sequence, making progress in preparing artifacts, checking the costumes, perfecting dance, singing, and fighting sequences of the play. There were even members invited only to provide constructive criticism using index cards presenting the user stories. For instance, one of the index cards read, “As a minister to the King, you should not use too many hand gestures to show your surprise so that the audience knows that you are always composed and thinking of the next scheme.”  Even the venue selection for the 40 individual practice days was so distributed to address geographical challenges to collocate the team to benefit from osmotic communication in that everyone could manage to attend understanding stage movement clues, voice projections under different audio systems, as well as including phone rehearsals to perfect dialogue delivery to combat.

Agile does not say “no documentation” but only “comprehensive documentation.” But the extent of required documentation is left to the individuals in the team. While there was no specific documentation created on how to assemble the palanquin or the shipwreck scenario, there was a substantial documentation created with more than 150 light clues on what area of the stage had spotlight, when there was colored light, when the light flashed to add special effects, etc.  Similarly, there was documentation on the backstage collaboration as stage, scene, and individual props moved seamlessly through worksheets identifying who moved and removed properties to the stage, where they moved, how they moved, and communication protocols to the custodian that gave the cues to the light crew sitting far from the stage.

Evaluation of the Third Agile Manifesto Principle
Agile manifesto values customer collaboration over contract negotiation. Again, real life scenarios such as these stage plays challenge the common thinking of who the customer is.  In business parlance, the customer is the one that pays for the product or service and is the reason why the company is in business. Extending the same terminology would mean the audience that came to see the show or the sponsors that supported the show were the customers. But this stage play extended the notion of customer far higher, such as the following instead of going back to “what you are supposed to have done” contracts based on the rehearsal.
  1. A character is a customer when talking/interfacing with another character. So, even when the lines and body language were rehearsed, the team didn’t wait for the cue words that went missing but filled and moved on.
  2. The light crew was a customer to the character on stage and when the character in the spur of the moment was on the right marked spot to deliver, the light crew attempted to refocus the light.
  3. The cast themselves were customers to the stage crew that required the individual properties to be returned to them for reuse in other scenes. However, when one member missed it on stage or left it on different section of the stage, the backstage crew or the experienced cast members accommodated to keep the show moving without backlog.
  4. The self-organized team was so focused on the goals that lines of who was the director/facilitator (product owner) or who was the process checker (scrum master/coach) never needed to surface. So tightly integrated the team was that they even altered their international and other business trips to attend rehearsals, participated in phone rehearsals from taxis, cabs, and hotels during their business trips. The “How may I help?” message and motivation support was so evident among the cast, crew, organizers, and volunteers.
Evaluation of the Fourth Agile Manifesto Principle
Finally, Agile recommends responding to change over following a plan. Although Agile may promote this value statement, this value proposition is emanating from common misconception of traditional project managers that think, “Plan the work and work the plan.” Fundamentally, such purist project managers are those that came to the profession accidentally thinking that working the Microsoft Project plan and being a task master is all that this Project Management means. Contrary to this belief, experienced project managers whether they follow Agile or Waterfall, know that no project goes by the tasks laid out in the work breakdown structure (WBS) of the project plan exactly. If they do, why is fast tracking and crashing approaches exist? 
  1. In the stage play, several “gotcha” moments existed. A few examples include the following that emphasize how the stage and crew adopted to change instead of reacting to we should stick to the plan. People that failed to project their voice or speak closer to the microphone got directions from the crew or other supporting cast on stage using body language to direct them to speak louder.
  2. Microphones that did not pick the voice adequately from where the throne was located requiring the cast to adjust their movements requiring them to “be in the act” walking closer to the microphones.
  3. Using incorrect clues from the stage coordinator to the light crew that started the scene prior to the backdrop swap was completed requiring to readjust the plan as the volunteers got stuck behind and could not be readily available for the next stage transition.
  4. Realigning the position of the location of the palanquin and using a different spotlight from the originally approved light sequence when the microphone needs challenged the available moving space for the cast.
  5. Altering the movement of the boat movement sequence requires using the entire stage area differently.
Summary
In a nutshell, this stage play is one of the several testimonials that Agility should be in one’s mind first. Agile Manifesto might have started as guiding principles of software development, but its application is not limited to the software development projects.  It is important to understand that everything Agile is subjective and not definitive. This is sine qua non of Agile Project Management. The goal of the iterations or releases are incrementally building progress towards the end goal and the role of the product owner or scrum master is to be authentic in their leadership so that the group buys into the goal becoming a self-organized team. Then, the teams don’t just break a leg! They make history.

References
Manifesto for Agile software development (n.d.). Retrieved May 11, 2013, from http://agilemanifesto.org/
Ponniyin Selvan (n.d.) Retrieved May 13, 2013, from Wikipedia http://en.wikipedia.org/wiki/Ponniyin_Selvan