I have a lot of ideas; most of them barely stay in my head longer than the remainder of my commute. I often find myself racking my brain hours later trying to put the pieces together again for something which felt so clear and certain a few hours earlier, but ends up dismissed and forgotten about.
A few lead to real action; I might write the idea down, do a little research, record something even. ‘Striking whilst the iron is hot’ works for me, knowing full well that once my attention wanes, so will my creativity. That happens a lot actually. I have over forty years’ worth of half-written songs, stories, craft projects, sketches for ideas and plans. Almost all of which never get shared with anyone, which I ascribe to knowing that I’ll probably never finish it anyway, and wondering what people would think once they realised how ‘flighty’ I really am.
One such project was something I started in about 2008, nearing the peak of my zeal for Agile and Scrum. I knew I wanted to write something, but didn’t feel remotely qualified to preach about how to work with Scrum, and saw no value in simply regurgitating the words and ideas of someone else. The idea brewing in my head was about choice; it always struck me that there was no clear right or wrong in how to start working in an agile way. There are simply choices to be made every day in the way we work together, organise ourselves, and communicate. Those choices have consequences, which cumulatively make a particular outcome more or less likely.
It reminded me of the ‘choose your own adventure’ books I loved as a child. Turn left or right? Follow the shadowy figure in the jungle or call out and confront them? Stow away on the spaceship or try and negotiate for passage? Never quite knowing where each choice will lead you, until you find yourself in either a treasure room surrounded by riches, or gasping for air on an inhospitable planet watching the ship fly away from you.
So, I set about writing a ‘choose your own adventure’ book for Scrum. Originally written from the perspective of you, the protagonist, a new Scrum Master, facing everyday situations and challenges as you try and support a team. I had so many ideas and routes for the story lines, not to mention plans to rewrite it from the perspective of a product owner, or team member too. It was going to be epic! It was also, as it turns out, really, really hard! Keeping track of loose ends and plot lines – a mad, tangled spider web of story snippets, became more of a chore than the fun, inspiring project it had started out. So, I parked it, and eventually retired it to the pile of half-done creative ramblings.
Then in 2018, I thought of it again, and was frustrated by the fact that I still believed in the original premise; no right and wrong, just choices and consequences. I started to think about other ways I could demonstrate that point, make it more interactive, team based, where people could make choices and see the effects of their decisions in real time. That’s when I realised what I was really thinking about was a game. An RPG, where instead of playing as an Orc or an Elf you were an engineer or a product manager, and instead of teaming up to go on a quest to slay a dragon, you worked together to get your product to market and as many users as you could.
There was one problem with my plan however;. I’d never actually played those games, other than Neverwinter Nights on the PC many years earlier. As much as I knew I could read up and learn the mechanics of how to make it work, I wanted to make it feel authentic. Something that simulated working on a software team, but captured the strategy, excitement and game play of a real RPG.
A few months earlier I’d been asked by one of our consultants, Sasha Bilton, to help review an article he had written comparing the role of Scrum Master to Dungeon Master. “Aha!” thinks I, “This is the person I need”. In a bold move (for me at least), I started sharing the idea around a little and a few of our people were inspired by it too, and wanted to get involved.
So Sasha, Odhrán McConnell and I set out playing with dice, scribbling on cards, trying out rules and calculating probabilities. We actually spent more time coming up with mad ideas for event cards (zombie apocalypse anyone?) than we did on the probabilities calculations, but we worked it out, mostly through guesswork and trial and error.
What came to light quite quickly, is there were so many things we could do with the game, so many ways to play it and content we could create, the challenge would be cutting it down to something simple and accessible, while still conveying lessons around working in an agile team.
I ran test games with handmade cards, iterating on the rules as I went, playing with client teams of 50 people at a time and with my eight-year-old daughter’s friends. I took input and ideas from anyone and everyone willing to sit through me droning on about this awesome thing we were creating. All feedback was valuable and acted upon, compromises were made and future development planned until finally, we were ready to print.
The end (and arguably the beginning again!)
Danny and his team at The Circus did a great job with the design and packaging; everyone loves the tins and giant 20-sided dice particularly. When we launched officially at Agile Cymru in July, I gave a few packs away, and have already had some great feedback from people playing the game back in their own companies and with clients.
I wanted it to be possible to play a simple cards and dice game – the way the kids’ beta test team played – or as a learning tool, modelling the complexities of delivering a product to market. In a short sample game with half a dozen or more teams playing at once, it’s not easy to explore all of the intricacies and usage potential.
So that’s the story of how we got it done! Next I’ll be sharing a series of articles on how to get the most from the current version, how to develop and adapt it for your own team and learning needs, and our plans for future development.
Agile 101 is available to purchase now on Amazon. GAME ON!
*A quick thank you to everyone who contributed, shared ideas and helped get the game to this point: Sasha Bilton, Odhrán McConnell, Danny Waters, Mike Dixon, Andy Muir, Erik Schmeigelow, Kelly Waters, Nathan Gloyn, and my favourite beta testers: Frankie Mistletoe Hopkinson-Spark, Caitlyn Gloyn and Oliver Gloyn.*
In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights