Recently my team and I had a big task in front of us. An upgrade of a third party product, with configurations and modifications done by us. It have been 3 years since the last upgrade and our Configuration Manager had left, and I have been kind of spokesperson for us not needing a Configuration Manager solely responsible for the system configuration, it is better if that is left to the team. So we enter this project with limited prior knowledge, just some documentation spread out on our company wiki. We knew we had some Known-Unknowns and a lot of Unknown-Unknowns, or at least we suspected that there could be a lot of things that might pop up when we started working on this.
We decided that the best way of tackling this project was to get our hands dirty straight away, and just roll up our sleeves and start working. So we did. And we found a lot of Unknown-Unknowns, a lot of uncertainty that we had to continuously report to our Product Owner as new backlog items or change of scope in our ongoing sprints.
So how do you deal with uncertainty?
We started out working in pair, we are four developers and we knew that this upgrade would take a lot of time, but we would still have to deal with bugs and other features that might be temporarily prioritized by the PO, and hence we needed part of the team to be ready to handle this. So we worked in pairs, one with the upgrade and one with bugs and features. Then we switched so everyone would get a chance to work with the upgrade.
The plan was to make the upgrade in steps. First, we needed to get the product installed and configured as recommended by the vendor. Second, we needed to adjust the installation with our configurations to work on one single server. Third, we needed to provide parameterization to be able to install the product on any server.
The first two sprints we managed to get the product installed and updated according to the vendors recommendation. We were continuously documenting our progress since we needed the documentation for future upgrades and we regarded the documentation as one of our deliverables, or artifacts. Since we were only two working on this rather complex/complicated task at the time, and since we had expertise that was required in the regular maintenance of our system this took longer than expected. Summer came and we took a planned break since during summer many of us are on vacation.
After the summer we continued working with the upgrade. But this time we took another approach. Instead of working in pairs, we decided that when ever we had Unknown-Unknowns (higher complexity) we needed to gather all developers to discuss and probe the installation procedure together. When we were able to find any patterns or Known-Unknowns we decided to create backlog items to split up the work and continue working in pairs, in some cases we changed the scope of the current sprint item we were working with. This kind of introduce a transition between what is Unknown-Unknowns into Known-Unknowns which had to be dealt with by an expert or analyzed by us. Sometimes we found Known-Knowns and in those cases we had to make a decision whether we should just continue and solve the issue ahead or add it to the backlog. Whenever we found new Unknown-Unknowns we did the same thing again, gather the developers for perspectives, discuss, try to extract backlog items and then continue. When you work in high complexity (many unknowns) it is important that the whole team understand why it is important to get perspective from others, how to decide when to either change scope of current work or add an obstacle to future work (add backlog item), and the importance not to lose focus on the Sprint Goal or any other expectation from the Product Owner (or any other key stakeholder for that matter). The direction is important and should be the responsibility of any team member, otherwise it is easy to get lost. So the rule of thumb, move forward, keep the direction.
The image above (or some version of it) you might have seen before. I don’t know what it is usually called, by I call it the Unknown-Known quadrant.
When we find unknown-unknowns we perspective from more developers, more diversity. Maybe someone is knowledgable or we can together figure out how to move forward. We gather all developers to help out. This isn’t a call for help, it is just the way we decided to work. We don’t expect one single person to have all knowledge, but we do know that the many diverse perspectives can help us figure it out, or at least how to move forward keeping direction with the aim at the Sprint Goal. When we learn and see patterns, we try to move things, parts, to any other quadrant. When we know that something have to be analyzed further or we need help from an expert, we move it to the known-unknowns part of the quadrant. If we know how to solve it, then it is easy, we move it to the known-knowns part. The unknown-knowns is basically just a way of saying that we didn’t know we actually knew it, that is basically just like knowing it so it’s basically just a transition to the known-knowns. At each finding we discuss whether we should do it straight away, or if it can wait. Is it possible to do a work-around, or should we time-box and just try and see how big the obstacle is?
So this is an ongoing process, which gives us the possibility to navigate, and a language to describe where we are.
Also, in the unknown-unknowns quadrant we work continuously with testing, and experiments, which gives us the following updated quadrant.
So the addition here is Explore and Exploit. When working with Unknown-Unknowns we explore, we probe, we test, we try find an emergent solution, something that works now but maybe lacks quality and must be rewritten in the future. Just to make us move forward. Then we exploit, we use our findings, whether it is testing an idea, using an expert, doing some further analysis.
When I draw this image to show during the demo I just realized that it is pretty similar to the Cynefin framework. Maybe the Cynefin framework were into play even though I didn’t realize it. I must admit I didn’t use the term expert but more of “we talked to this guy in another team who done something similar”. I believe that this was an “aha”-moment for the rest of us, that we now have a method for collaboration, and for navigating in the unknown.