For those who could escape my constant broadcasting of the past months: I’ve been working on a musical project since last November that will take place at Agile Testing Days 2024.
One of the first things I was pretty sure I wanted to include when I had the initial idea was a proper lightsaber stage-fighting choreography. With only a couple of weeks left, my partner Veerle and I get into the boiling phase of this part of the musical.
While preparing, I couldn’t help but notice that how we approach this challenge is very similar to how I approach challenges at work in an agile way – and it highlights what people often get totally wrong about solving challenges in an agile way. So I wanted to point these similarities out (which gives me the possibility to write about my most favorite side project again).
Agile doesn’t change the context
I am not a very sporty person. Not really a couch potato (thanks to my dog), but there are a million things I enjoy more doing than physical exercise, and let’s not get started with balls – we won’t become friends anymore.
I’m for sure not a professional actor or martial artist, and neither is Veerle, although she has some advantages with her hobby: viking age battle reenactment.
This sets some hard context and boundaries: Given the people involved, we will just not be able to do an Ewan McGregor movie-level fight choreography.
Due to the fact that we are living in different countries, we will also not have the possibility to practice together until the very day of the event. On top of that, the real stage we will be acting on will not be set up until 1 hour before the musical.
It sounds obvious that these things shape what we can aim for and how we can achieve it. But when we talk about software development, I see it so often that the expectations for the end result are completely ignorant of the given context. We want our own, completely customizable decentralized collaboration solution, built in three weeks by two trainees and a developer in their first year after university.
Don’t get me wrong: two trainees and a junior developer can create amazing things – as Veerle and I can create a stunning choreo. But there will be differences to the Star Wars movie fights.
Approaching this challenge in an agile way doesn’t change the context or limitations. You can’t throw “agile” on top of a situation to “make it work”. The only thing agile can help with is finding a way and a result that is acceptable within the given boundaries.
By being aware of what our context is, we found a couple of solutions (practicing alone with an audio practice track, using crepe tape to simulate the stage) that will allow a pretty cool result.
Agile is not being unprepared or without a plan
When you watch a lightsaber fight from the outside, it usually looks intuitive, improvised, driven by action and reaction, even chaotic.
When you watch an agile project from the outside, it sometimes looks intuitive, improvised, driven by action and reaction, even chaotic.
A lot of people believe what they see, and approaching a challenge in an agile way for them is a synonym for “we just improvise so we don’t need to prepare”.
In fact, lightsaber fight choreography needs a lot of planning and preparation. Above all else, you want to achieve two things: the fight should look spectacular and you don’t want to hurt your partner.
If you try to “improvise” a lightsaber fight, you either need an insane level of experience and practice together with your partner or just look lame and have a very high risk of injuries.
This is the first draft of our choreo-sheet that we will be using:
- There is a system/methodology how to document/communicate different attacks and blocks: a number system where each number stands for a specific attack or block (with variations)
- There is an exact plan for how to sequence the different attacks, even specifying who does what
- There is structure so we can match the attacks to the background music and practice at the exact same pace
This is the exact opposite of being unprepared or without a plan. And still, I say that we approach this challenge in an agile way – why?
Because I was not writing these instructions for the whole fighting scene right at the beginning. We have 6 phases, 4 of which are not fleshed out at the time I’m writing this because we want to learn from the first two phases.
My approach so far was:
- Research what stage fight is and how to do it
- Find a system I can use to draft my ideas
- Practice the basics of that system
- Come up with a major vision of the fight and slice it into different parts
- Draft the first couple of moves
- Test those under realistic circumstances (e.g. with the music we want to fit)
- Adjust that draft, learn what’s possible and impossible given our context
- Draft the first 2 scenes
- Create supporting tools (e.g. audio practice track)
- Practice the first 2 scenes
When we learn enough about the first two scenes, we will be able to make better decisions about how to approach the next four.
Agile software development doesn’t (well, shouldn’t) skip planning, architectural drafts, and all that. It’s absolutely necessary. The difference is that we want to draft, try out, learn, and adjust. All inside a somewhat vague overall plan.
But what about unexpected hurdles?
If we face an issue we cannot overcome, we will change the expected result, because we have an unchangeable deadline. We could also change the deadline and put more time into a solution to achieve our originally expected result. Both options work very well.
What doesn’t work is to adapt neither timeline nor expected result. Agile doesn’t change that, it just makes it more visible.
Agile doesn’t get you quality for free
I guess this is something that will turn into its own post at some point, so I’ll keep it short:
You don’t get quality for free. Agile doesn’t change that.
Just because we approach the challenge in an agile way doesn’t mean we need to practice less or put less work in. If we want to be able to fight at an adequate pace, we need to train until the movements sink into our muscle memory. There’s no shortcut, no magic wand to help us.
If you want to achieve a certain result, you have to put in the work.
One thing agile can help with is not to spend energy in places that don’t help.
If we notice that some hit-combos are too hard for us, we can change the current draft and keep that in mind for the remaining phases. We didn’t spend any energy on memorizing these phases yet, which is great. But we still will need to spend a lot of energy on them.
The other thing an agile approach helps with is a mental one: By slicing and trying out tiny bits we can see progress very, very quickly.
It has helped me immensely to see tiny improvements in my daily lightsaber training. I don’t try to do the full-blown choreo at the final speed on day one.
Instead, I started with the basic moves while standing still. On day 2 I could do slow steps. On day 3 I had no problem memorizing the different attacks anymore.
I am very optimistic that this pattern will continue because I have experienced it in my work. It’s the constant tiny steps and improvements that make you reach the goal, not a one-time heroic effort.
What do you think?
I’d appreciate your feedback and thoughts on the observations and conclusions I shared. Do you see those similarities? What are your experiences? And, most importantly: are you hyped to watch our musical? 😄
0 Comments