Recently my team and I headed down to New Orleans, Louisiana for a team building trip and to get a lot of face time. Working remotely, it becomes difficult to set aside the time and hash out certain things that weren’t working well. In our case, it’s our JIRA board that was an absolute nightmare. It’s incredibly beneficial to be able to put everything aside and actually work on process improvements.

As a part of this, we got a chance to meet with Heidi Araya - Agile Extrordinaire - to guide us through our journey and figure out ways that we could actually make a transition to a fully Agile environment happen. I’ve always known Agile as a concept, a buzzword, and a “goal” - the same way that me becoming a billionaire and retiring to a private island that’s not too hot and not too cold is a “goal”. It was unfortunate that she had to leave before we went to the escape room, because she would’ve been able to see our team put tangible agile practices to use in order to solve it in almost record time.

The Agile Tangibles

Before I go into how we applied the Agile mindset to our escape room adventure, it would be wise to talk about the reasons for applying Agile as a mindset.

The Before

Our process and methodology could be considered a waterfall approach before this week. Our waterfall was flowing at a mere trickle, however. Everyone was in charge of their own product, everyone was in charge of their own code, and everyone was in charge of their own workflow. If something wasn’t working out for you, then it was up to you to fix it. This was an isolationist policy which put a ton of pressure on us pseudo-dev’s with very little opportunity for reward. By the time you tie in relying on other teams for certain parts of our workflow… needless to say it was chaos.

On our trip to New Orleans, Heidi was able to sit down with us, listen to our concerns, and create a plan to allow our team to be more Agile going forward. She quickly assessed that it was difficult for us to make decisions because we had very little data to inform our decisions and our management of said decisions was highly distributed. By reorganizing JIRA to have 12 columns (up from the traditional 3 “to do”, “in progress”, and “done”) we will now be able to identify where our bottlenecks are and who can step in to help on each product as we push toward a release.

Why Agile?

There are many reasons to adopt the Agile mindset moving forward in any organization, but the two that stuck out in my mind are:

  1. Agile allows an organization to pivot on a dime to make the necessary changes to accomplish a goal via dynamic feedback
  2. Agile flips the org chart - putting custmoers in charge with the workers as the decision makers as opposed to management coming from the top down.

There are many more reasons of why an organization should make the leap to Agile of course, but these were the ones that really stuck with me. Agile also has four main values which help with the mindset. One thing to note about these items taken directly from the “Agile Manifesto” is that we value all of the items listed, but the ones in bold we will value more:

  1. Individuals and Interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer Collaboration over contract negotiation
  4. Responding to Change over following a plan

Through these four tenants of the “Agile Manifesto” we can already begin to see how this is different from the traditional Waterfall approach. With Waterfall, we would gather our requirements, march diligently toward a release, checking off all the boxes along the way. If any problems arose that a checkbox didn’t address, we would oftentime start over, factoring in that deviant idea. The Waterfall approach is very rigid and inflexible, because it tends to value the items on the right side of that list more than the items on the left.

Where are we going from here?

So obviously we are adopting Agile in a hurry. One thing that we have to consistently remember is that Agile is a mindset. It’s not a plug in tool, and it’s not JIRA. We also all have to agree that the process we came up with in our New Orleans trip might not fully realize our goals for the team whenever we all get back to working remotely. Through the Agile mindset we will have to be open and accepting of change while at the same time working together to identify the processes which do not have a flexible and customer focus.

Accepting Agile is a process which requires constant diligence, but our team is able to embrace change. It’s a good sign, since that seems to be the theme of Agile.

The Escape Room

For our escape room we visited “Escape My Room” in New Orleans, which mocked up the DeLaporte home offering costumes, quirky wall decorations, and sweet Jazz from every corner. In case you’re unfamiliar with an escape room, it’s a room that you are locked in with several friends and asked to solve a series of puzzles in order to escape (there’s always an emergency exit button of course). After dividing our larger organization into two teams of 8, we were each taken to the “Jazz Parlor” where we were asked to solve a murder and find the wife of the late Mr. DeLaporte, owner of the estate.

Our team’s makeup consisted of a manager and 7 others from 3 different departments within our company. We had all worked adjacent to each other before, but I can’t remember a time where we were in direct contact for more than an hour at a time. We were a good mix of problem solvers, information gatherers, and tinkerers with a broad range of (mostly IT) skills. Even better, we had a pretty even mix of folks who had been to more than 5 escape rooms, as well as a few who had never been once!

In the talk that Heidi gave about Agile, she gave us a list of behaviors to follow in order to be Agile minded, and I kept it in mind as soon as we walked into our challenge.

Self-Organizing rather than waiting to be told what to do.

Upon our room’s attendant handing a note to one of the team members and closing the door, we immediately broke out and started looking for clues. In an escape room, clues come in all different shapes and sizes and because we were solving a murder we all had our eyes peeled for evidence. Within a few seconds, we already had some clues lined out - well before Josh L had finished reading the card with our instructions and objectives for escaping the room.

As clues landed on a table in the middle, some of us (me included) stayed to research the clue to see what it might unveil while the others continued to search every nook and cranny of the room for more. Anything with text was read aloud by Josh, which we all were processing while performing our individual tasks.

Making our work visible and transparent

Once everything with text was read aloud, we began to call out whenever we had unraveled a piece of the mystery. We didn’t need to come all together as a team to regroup because our open communication kept the ball rolling on everyone’s “project”.

Occasionally, two clues would both indicate the same thing - and those team members would immediately come together and break off to work on their piece on their own. It was a really amazing sight to see, given that we were all virtually strangers.

Breaking things down into bite size pieces

Another strategy that we adopted was breaking out work into easy to digest bits. Suppose one team member held a clue which opened a box, and in that box there were two more clues. Rather than having that one team member attempt to solve both puzzles, we would call out that clues were available and anyone not working on one should come over and pick it up.

Heidi had talked to us about the “pull” method of work. Rather than pushing projects and objectives onto the person who drew the short straw, if work is offered to be taken the person who is free to take that work can go do it without being overburdened. This allowed us to “multi-thread” our throughput inside of the escape room.

Focusing on outcomes instead of output

Rather than having internal fighting of who was putting out the most work on the clues or who was able to open the most doors, we celebrated our successes together and moved forward as a team.

One fact about escape rooms is that you will typically proceed through 2-3 doors before completing the room. In the case of this room, we were unanimous in that once a door was opened, we would all walk through and repeat the processes we did before. Information gathering - collecting all the clues - analyzing the clues - and finally solving them. This turned out to be a time saving approach, since many clues in the previous rooms would trail off - the creator wanting to “stump” you with fake or irrelevant clues.

Tracking our progress

Josh, who had originally read the cards aloud, quickly found himself as the group’s recorder. Any time we would “use” a clue, he would be the one to write it down to mark it as spent, this way we didn’t spend time churning on clues that had already been solved. If we were searching for text or patterns, he would organize the data on a sheet of paper and with a pen take all the notes he could.

Using this approach, Josh was able to float between all of the teams and make sure we had the necessary data to use the clues we would gather appropriately. There were many times where I was trying to figure out what to do with a clue and he could tell me the answer, after having written it down from a previous investigation. This saved us an incredible amount of time since we had that go-between.

Inspecting and adapting using feedback

Changing our mindset while we had a clue in our hands was necessary in order to get the time we did. There was one instance that I remember, where we had a book with chess moves inside of it - but we also had a letter+number pattern combination written down on some fan blades. This is arguably the piece of the puzzle that took us the longest, since we were trying to arrange the pieces in the order on the book, then in the order on the fan blades, then in combinations… One of our team members looked over Josh’s shoulder in order to see what we were working on and immediately exclaimed “Oh, those are chess moves not positions”. Everything clicked.

We proceeded to shift focus, with the initial positions being read out, then tracing the lines as the moves were read. Soon enough, a loud “click” was heard, and a door opened.

Embracing change

With a series of rapid releases in the form of clues, the only consistency we had was change. Each clue solved meant our role would change for the next task. Would we assist others with the clues they were given? Would we find a series of letters or numbers and try and translate them?

Flipping our responsibilities minute-by-minute was a real mental challenge, but the goal was simple. Output as much as you can, as fast as you can. Where you fail, your team will cover and where they fail, you will cover. We each have different strengths, and to capitalize on each strength in a revolving environment is as Agile as it gets.

Conclusion

There are so many more Agile principles than what I listed out here. Realistically, we applied these principles for 35 minutes as we careened through the mental obstacle course. To apply them across an organization from top to bottom and inject Agile into every process… that’s the real task. You have to start somewhere, though. Many people may try to construe Agile into something that it really isn’t. The key to Agile is to learn and grow and respond to change, and it’s up to us to take that back and apply it within our organization.

So tell me, are you Agile? Do you have more questions? As always feel free to tweet at me


Bryce McDonald

IT Pro Veteran and Solutions Engineer specializing in Powershell and automations