The puzzle approach – delivering complex software solutions
Like many engineers I like puzzles, for me it’s about using my senses to understand the problem I’m trying to solve, then applying my skills/knowledge to complete the challenge. Over the recent Christmas holiday a friend was given a gift in the form of thick metal wires bent into various shapes with the goal being to separate them, then put them back together. Not a complex problem but the solution to the puzzle was challenging because there was no obvious way to separate them short of applying brute force and the wire shapes were thick enough that that was unlikely to work.
After the puzzles were handed around the room with different people taking turns trying to solve them with no luck I was handed one. My approach was different, I didn’t immediately start trying to twist in different directions, pulling, pushing and straining to separate them. Instead I took a step back and asked myself what holds them together – this allowed me to see that the wires were not the same thickness and that there were gaps in the twisted wires where the thinnest wires would fit through. After a moment or two of sliding the two wires in different directions so the gap fit with the thin wire – viola I had two separate pieces. Okay – that was the easy one. As I was handed the next one and I applied the same evaluation to the problem I saw that with this one the wires were all the same thicknesses so the original solution wasn’t going to work. I did observe that based on the shapes of the bent wire objects I could align two gaps and achieve the same objective – a large enough gap where I could separate the wires. Another couple of moments of twisting I was able to align them and success! I applied this approach for all of the puzzles. At this point our group thought I was a magician and like any good magician wouldn’t reveal my “secrets”. Instead I chose to share my approach, my strategy. Within a few minutes many of the others had applied my approach and solved these puzzles themselves.
Yeah Ron, that’s all interesting but what does it have to do with delivering complex software solutions?
Complex software solutions are like puzzles in many ways – There are many parts, some complex, some simple, it’s not clear how they fit together, how the different pieces will affect each other, who needs to be involved to solve it, when will it be done, how much effort will it take and so on.
I was recently asked to support a large complex software delivery that was critical to my company – I’m purposely going to be vague about the details as that isn’t really what’s important. When I asked to take this on there was some general direction of what the outcome was expected to be, I had a list of names of people to start with, some systems that needed to be integrated and a very firm timeline that didn’t leave me much time. Sound familiar?
Where to start? My approach to this puzzle is what I call the Jigsaw puzzle approach – define the outline of the puzzle. What needs to be done – minimum viable product, how much time do we really have, what’s the priority of this work relative to anything else that’s in flight, what resources do I have to work on it. Once this was defined I could step back and start to form a strategy to tackle the rest of the puzzle.
Despite the fact that I was being asked to come up with delivery dates for this complicated work daily – I resisted, and took the time to understand what I was being asked to do. It took at least a week to see the outline of the puzzle.
Once I had the outline I had to start breaking the work up into pieces to tackle. My first step of that strategy was to throw away the strategy that was formed before I joined the effort. Large meetings to hash out details with everyone involved. Too many resources involved for too little payback.
Using the jig saw puzzle approach I tried to break the solution into different areas – which areas touch other areas, who needs what pieces, what could be done first. With that we were able to focus our efforts into sub groups. I broke the solution down into several pieces that could be done in parallel given the resources we had in place.
I’m happy to say that things are moving forward in a consistent way, it’s predictable and I’m fairly confident about dates. The last steps are still in front of us, the final integration and systems testing but we’re in a good spot. The best thing about this is that we’ve done it without adding resources, moving out the schedule, or working terribly long hours.
