What Dance Production Can Learn From Agile Software Development

In 2001 a group of software thought leaders met at a skiing resort in Utah (to ski) and discuss
wide ranging problems in software development. They noticed a trend in traditional software
: Deadlines were amiss, business requirements were not being met, and the
software developed would immediately outdated according to constantly evolving audience
tastes. This gave birth to The Agile Manifesto; twelve principles for product development which put the user at its heart. Agility at its core, the manifesto looked to ensure development was constantly evolving to audience and market needs.

These key principles of agile development transcend software development and have been
adopted by multiple industries. The core principles of improvement, iteration, and self
organisation are easily applicable to any development process. Software development is
commonly perceived as dull technical work, but code is a language with its own poetry. Software development is a creative process and artists of all disciplines can apply agile principles to compliment the creative process.

Dance and theatre production works identically to software production: creatives come together to build a product, perform it for audiences, and improve the product after audience feedback. It is very rare for a production house to present an identical performance on its premiere night and its final night. Constant iterative improvements are integral to the performing arts, and integral to the Agile Manifesto. As audiences and their tastes are constantly evolving, a dance production regularly tests material during the development process in the form of Research & Development sharings. Dance production is fundamentally agile, but does not apply agile frameworks to accelerate the development process.

A common framework used in conjunction with agile is Scrum, a formalised agile methodology. There are three roles to a Scrum team: A Product Owner, A Team Member, and a Scrum Master.

A Product Owner owns the creative vision. Within dance this role would belong to the Artistic
Director. Each project begins with a ‘definition of done’: the Artistic Director defines what
success looks like at the very start of the project with clear requirements. Every team member
must understand this definition of done, ensuring the team is unified towards the same vision.

The eleventh agile principle is particularly apt in dance production:
“The best architectures, requirements, and designs, emerge from self-organizing teams”

Each member of the team is equal, with no direct management. Individuals are motivated to
contribute to the creative journey and teams are cross functional. Within a dance production this includes the whole cast: from the set designers, to artists, to the composer. Each individual is trusted to excel in their creative field, while the Product Owner ensures everyone understands the vision.

The final role is that of the Scrum Master. The Scrum Master oversees the overall development
but acts as a coach and facilitator, not as a manager. The Scrum Master ensures the team are
communicating and motivated, and identifies any potential barriers to development (referred to as blockers, or impediments). This role would belong to the Producer: overseeing financial risks; ensuring resources are managed; assessing possible injuries; and ensuring all aspects of the production are coming together.

Aside from the overall product vision, Scrum teams work in short “sprints”, focusing solely on the development of the product in a short time frame, with a clearly identified milestone. At the beginning of a Research & Development phase, the Artistic Director (Product Owner) creates a list of objectives and features to achieve at the end of the R&D phase (this sprint). During this planning session, facilitated by the Scrum Master, the creative team discusses every feature they would like to achieve by the end of this milestone. Team members may suggest creative features.

The efficacy of Scrum emerges at this point: the Product Owner assesses each recommendation against the product vision and assigns a value to each feature. The Scrum Master assesses the overall list of recommendations and decides a realistic number of features which can be prioritised within this sprint in alignment with available resources. There are many formalised prioritisation matrixes and grids to do this using everything from fibonacci sequences to diagrams, but essentially this comes down to assessing Value against Effort.

As an example of the Scrum process, the Artistic Director has defined the overall product vision at the beginning of development as the following:
“An outdoor contemporary Bharatanatyam performance to bring public awareness of the
effects of climate change to a wider audience.”

The team is in its second sprint: the second Research & Development phase. A dancer would
like to include a classical Bharatanatyam technical motif within this R&D; while the lighting
designer would like to create a lighting design to reflect melting ice caps. The Scrum Master
defines the effort required for both as an assessment of available resources within this R&D. (For example this can be the financial cost of each requirement; or the time involved, or the number of team members required.) An assessment is made: the cost of a technical Bharatanatyam motif is lower than the cost of outdoor lighting equipment.

The Artistic Director assesses the value of each requirement against the effort. While the lighting may have a higher monetary value, the lighting design provides more direct value towards the creative vision by representing melting ice caps. The dancer’s requirement will use less resources, but will also provide less value to the overall creative vision of the production as the technical motif won’t directly relay the vision. The Director may choose to prioritise the dancer’s requirement and make some amendments as to how this requirement can align with the overall creative vision.

At the end of the sprint, the team meets again to discuss the development process and to learn how to improve before they continue development in a Scrum ritual called a “retrospective”. Often, this coincides with a demo to key stakeholders and users.

At the end of an R&D phase, there is often a sharing with core funders and stakeholders in the
audience. The Artistic Director will receive some feedback, and will begin to plan the next phase of development. Often this process will involve just the Director and the stakeholders, this formalised team retrospective is overlooked. The retrospective phase is fundamental to
production: if the product vision has changed as a result of a performance, the whole team need to be aware of what the new vision is and why this has changed.

Scrum is one specific formalised structure of agile, and not all aspects of Scrum need to be
applied to dance. Some may find Scrum too rigid and compartmentalised and this may be a
hindrance to their creativity. Dance production however is naturally agile, and creativity can
flourish by applying agile principles to create an iterative and audience focused production.

The problems identified at the 2001 software conference apply directly to dance today:
audiences are constantly evolving and their tastes tend to misalign with the artistic vision
originally scoped in funding applications. Resources are scarce and the creative product
changes after every performance. The implementation of Scrum has led to some of the finest
software development in the last sixteen years, bringing us to the finest period of digital
creativity. By applying some of the agile framework to dance production we can see similar
growth and innovation across the arts.