Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones. – Donald Rumsfeld
A few months ago, we began to replace software some of our staff use on a daily basis. It’s the first step in a process that will completely overhaul our system, but we wanted (and needed) to start small. We picked a small-ish piece of functionality that 3 or 4 people may use during a given workday, and set about re-creating the functionality to fit into our new browser-based architecture. Interviews were done with the users to collect feedback on…usability (of course). “Hey user, you’ll notice the steps in the process are the same, but the flow has improved, right?” We worked and tweaked and followed our style guide.
The end result? Nailed it. Not only was the new product (initially) met with adoration from the users, but it was a tight, textbook example of how to deliver using Scrum. From design to integration, this shiny new piece of software replicated existing functionality, improved the user experience, and moved us one step further away from an aging legacy system (which, all things considered, has performed more than admirably). Once we moved the product into production, it was smooth sailing.
Except that it wasn’t.
We missed something. Well, actually we missed a few somethings.
In our diligence in examining the product we were replacing, we forgot to ask some questions. The backlog was there, with plenty of well-defined stories fitting into a handful of epics. We built what we were supposed to build. But we failed anyway. We recognized our mistakes and fixed them quickly and with relatively little disruption, but still, we didn’t hit the mark.
This thing right here? It’s nasty. It’s an absolute mess. Not only that, it’s dangerous. Seriously. People die on a regular basis in poorer cities across the world where you find things like this. When I say “things”, I mean “solutions”. Yes, it’s dangerous, but it was done because there was a need that was not being met any other way. In the case of this mass of wires, people needed electricity and they weren’t able to get it by calling up the electric company. And the designers of the original system certainly didn’t plan in a way that accommodated the needs of the people in the neighborhood. So the people took matters into their own hands and created this monstrosity.
But if it’s the difference in creating this beast or going without electricity, you create the beast.
That’s what we missed. We are replacing functionality that has existed for over a decade. Let’s assume the people designing the original solution got everything right 11 years ago. No, really. Not a single misstep in design or creation. Even in that scenario, changes to business, or changes to process flow have the capacity to destroy the viability of the solution. In our case, we had a well-designed product that adapted well to the changes we’ve faced over the years, but there were still problems from time to time that simply couldn’t be addressed by the product. So our employees did what most people tend to do. They created hacks. Workarounds. Solutions.
We learned something valuable. When replacing an existing system or piece of functionality, it’s not sufficient to replicate what was already there and add in the new features. You need to account for the ways people are working around a solution that no longer meets all their needs. The workarounds won’t always be obvious. They’ll rarely be documented. But trust me. There’s a giant ball of something hiding from you. It may not kill dozens of people each year, but ignore it and I can promise it will make a few lives very miserable.