The corn maze is one of my favorite challenges to tackle. It’s an unnerving experience, especially when you don’t have map and you’re doing it with small children. There’s only so much time before someone freaks out because “we’re lost” or loses it because they’re tired and have to pee. And it wouldn’t be any fun if we had a map or GPS to guide the way. The thrill is in trying to figure it out on your own, in discovering every dead end on your way to the maze’s exit.
Software development in an Agile context is very much like navigating your way through a corn maze. Even if you have an expert product and engineering team, you’ve never built this product with this engineering team before. It’s a newly designed corn maze that you’re navigating with your team for the first time.
What approach do you take? How do you avoid getting lost in all that corn (or code)? (I’m tempted to plant a corny joke right here, but I’m sure I would cease to a-maze you.)
How can you ensure that in both the corn maze and the software development project, they end in triumph rather than tantrums?
The Corn Maze
Let’s start with the corn maze. Navigating them can be quite difficult, especially if the designer was being cheeky while cutting it. It only took me a few mild (ahem) complaints from my kids before I resolved to develop a killer strategy. I’ll be generous and share it with you, as I doubt you can patent corn maze strategies anyway.
At a high level, a corn maze is about making a series of small discoveries and decisions that lead you either deeper into the maze or to the end of it. Each time you come to a fork in the corn maze, you face a decision to which path to take. Take the right path on a consistent basis and… victory!
Sounds easy, right? But when you’re stuck inside an endless labyrinth of possible routes, it feels anything but easy. The key to keeping your sanity in a corn maze is to follow a simple, methodical strategy.
As you walk the corn maze together and come to a fork in the road, split up and explore the various paths before you. In the very moment, when a group member discovers a dead end or more possible routes on their path, they must immediately return to the rendezvous point. There they will share their findings with the group so it can be factored into the decision of how to proceed. The group can then deduce that if, for example, two paths lead to a dead end, the third path must be the way forward. Then they all proceed together on that path and repeat the same process.
Continuing this strategy throughout the maze will set up your team for a successful journey through the maze. Even in the most difficult of mazes, a team can work together to effectively deduce the correct way through the maze.
We can sum up this strategy with a simple three-step process. As you walk the maze together, any time you come to a crossroads, you split up and do the following:
- Reconnaissance — Which routes are dead ends and which lead to other paths?
- Report — Share your findings at your rendezvous point
- Resolve — Determine which way to proceed
This forms a reliable strategy that transforms an uncertain impasse into a reliable means to discern the way forward. It harnesses the power of a team in a way that engages each member and yet preserves collective progress.
What is critical to the success of this approach is for the group to agree to do it this way. Otherwise you end up with people shouting from all different places in the maze because they can’t find each other or the correct path through the maze. Or perhaps you all stay together, navigating every twist and turn as a team only to find yourself in an argument about which way to proceed.
Software Development as a Corn Maze
Okay, so I’ve told you my brilliant strategy to solving corn mazes, but how can we apply this to software development on teams?
When working on a product feature, the “dead end” path represents a known outcome or finite task. Like a feature that you’ve done before or one you can complete with minimal effort. The path that leads to more paths is the feature that, once the work commences, seems to balloon in scope or becomes hairier than expected.
Once each developer discovers whether a feature has a known end or requires further exploration, this phase is complete. It’s important that team members commit to reporting back or that a member of the team reels them in. No going rogue to try to save the day and find the enlightened path. This leads to developers getting lost in code beyond the current scope. Or the team having to wait around all day until Rogue One returns so they can move forward.
When a developer determines the scope of the feature they are assigned to, it’s time to report back. They need to return back to the group and report their findings. A technical lead, story owner, or project management software would capture those findings.
The reporting process can take many forms. But the critical element is to provide a clear status update. Did they hit a snag or discover extra items to address? The stand-up in Scrum serves this purpose, but sometimes you need mini-standups or huddles. Especially when approaching a deadline or when features need further dissecting before you can make progress.
The reporting step gives the team insight into how best to navigate the maze of work ahead. It allows for quick pivots and true agility in creating software, as the team can gauge successes or bottlenecks and adjust their efforts. In other words, they can easily resolve what is the best path forward.
It’s then the job of a technical lead, the story owner, or a product manager/owner or scrum master to help the team navigate these issues. They need to maintain a priority focus on what’s needed in the short-term while facilitating long-term success as well.
If the team commits to this approach in navigating the maze-like nature of software development, it will enhance their agility and velocity. It will allow them to produce more features that are of business value.
I trust the strategy I’ve outlined will lead to the most efficient means by which you can escape both the corn maze and screaming, tired children. As well as screaming, tired developers.