Software development is amazingly similar to the theatrical rehearsal process. It used to be that software developers were locked in a small room for months at a time, free of distractions so that they could churn out code as quickly as possible. Of course, one of the fundamentals challenges with this system is that in today’s economy, people’s needs often change before the complete scope of the work is realized. TO combat this, many startups now practice a method called Agile programming. It essentially works like this.
1. Identify the features and elements that add the most value to a product.
In this regard, value is defined by the users of the product. For example, when building software for stage managers, it is the professional stage managers actively working in the field that help to illuminate what is most valuable to doing their jobs most efficiently.
2. Get those features into the hands of users as quickly as humanly possible.
The only way to truly know whether the parts of a product work, truly adding value for users, is to give them the keys and let them drive! This includes the way the features are designed and how well they work. Will there be glitches and bugs? Yes. But the fundamental idea behind Agile is that this highly iterative process will make the development team better and better at preempting those bugs by asking the right questions.
3. Collect feedback, revise, and make decisions for future development based on what’s been learned.
This is the crux of Agile development. By bringing the users into the development process and focusing intently on solving their key problems, the development team can readjust quickly, setting new priorities in building out the systems.
If we’ve learned nothing else over the past few years, it’s that we’ve seen unprecedented shifts in the event technology needs of the industry. And these shifts are not likely to abate anytime soon. By engaging in the principles outlined above, developers can stay abreast of the newest and most user-friendly designs and pivot to meet individual needs more quickly. Agile development doesn’t happen just once. It is continuously happening all the time.
So how do a rag tag bunch of event professionals (that’s us) even start to think like Agile software developers? Well first, we lay out a very simple tenet:
We don’t have all the answers.
In fact, the only way to learn the answers is by actually trying out the product. Or better yet, getting our colleagues to try it out! This process allows all of us to contribute throughout the entire development timeline. We identify issues and mistakes much more quickly and can make immediate course corrections based on feedback. Imagine how wasteful it would be to work for months developing a specific feature only to discover that no one actually finds it useful.
Building Propared in this fashion has led me to some interesting conclusions. Most notably, I am struck by how similar this development work feels to that of a show’s rehearsal process. Rather than everyone practicing their parts alone, actors, directors, and designers begin the journey together on rehearsal day one. Each day after presents new discoveries about the play and characters, informing future choices. A sudden understanding of a key line in scene two may have drastic implications for the second act. Similarly, the design and production team adapt to the realities of the venue, the budget, and the creative discoveries of the director and cast. Even the most complete and meticulous design plans go through multiple iterations (however small) once rehearsals begin. This way of working through the play in an iterative, organic manner allows us to learn together based on broader sets of perspectives and ultimately produce a better show. So maybe we’re better prepared to build software for event professionals after all!
I’m looking forward to to applying these principles at Propared. It means everyone on the team has a good foundation for the workflow and we get to involve the live event community from the very beginning.