Navigating Uncertainty in Software Engineering - The Ready-Learn-Do Approach
Now that I have written a bit more on the abstract side with Potential Space (1) and Leadership and Management (2) I want to have a look at how to actually navigate through that space and towards a solution.
In the beginning, we don’t have the full picture yet and the number of possible solutions is huge. Therefore our goal has to be to narrow down that space. For that, we first have to get Ready.
Ready
This step is about doing one’s homework. We have to understand what kind of problem we are dealing with. In the end, we should have a rough map of the terrain.
What does that mean in practice? Gather information and write them down. Talk to people who know, watch videos, read texts, and understand code. Do whatever is necessary to understand the problem but keep in mind to not waste too much time on it. In my experience, work that is heavy on learning and discovery tends to eat all your time and then some, therefore, commit to a deadline. Your understanding doesn’t have to be perfect. A rough sketch of potential space is enough for now.
By now you should know the following: * Is this problem solvable? Is there a potential path? * Is it worthwhile? What would change for the better and how? * What isn’t clear yet? * What guardrails exist? * What decisions need to be done? * Who are your stakeholders? * What are your resources?
And with that, we reached the first decision point. After you wrote down your findings you, your team, or the organization have to make a decision if it makes sense to invest more time into this endeavor.
Learn
Once you got the go take all your findings and fill in the holes and again we commit to a deadline.
The point of this step is to narrow down potential space even more so we end up with a handful of paths or even just one toward a solution. It is about resolving assumptions and unknowns and reducing risk (aka surprises). It is also another hurdle to check if we actually focus on the right thing.
For that we build cheap prototypes we throw away in the end. We also talk to people again to remove decision points we identified while we got Ready or showed up in the meantime.
By the end of Learn you should know the following: * What does the solution look like? * How do we get there? * How much time will it roughly take? * What will change for the better and how?
You should also have all the necessary resources at this point. That can be a budget, help from other teams, access, etc.
Another decision point is reached. Do we still want to continue? Is it worth our time?
Do
If the answer is still “yes“ we go right into the last phase: Do. Here, we will create the actual solution. But keep in mind to track new unknowns that pop up in the meantime. It has to be transparent to you and everyone else if we misjudged the terrain and have to do more and more Learn(ing). If that is the case, a reevaluation is due, and a decision of whether we still want to continue.
To make sure we have that transparency we report state on a regular basis, for example, every week on a certain day. There is a balance to be struck about the frequency here. Feel out what works for you.
Another signal we get is when we reach the estimated end of the project. Did we finish it already? Will it be done in time or do we miss the mark and have to continue? Coming closer to the end the answer shouldn’t be a surprise if we had regular reports. Now we have yet another decision point. And don’t fall for the lure of sunken cost. It can still be better to just stop and accept that it didn’t work out instead of hemorrhaging more and more of your time. You learned something and that has to be enough.
But let’s assume it all worked out in the end and you get your solution. You are not done yet. It still has to be rollout and you have to prove that this effort was worthwhile. Here, the question “What will change for the better and how?” comes in handy. Release your solution to your users and measure what happens. Did it work? This is yet another important signal. For one, it gives the final validation for our value proposition. But it also tells us if our process works correctly.
If we didn’t make it rinse and repeat. Ready yourself and make a point that it is worthwhile to continue and sketch out a new potential space.
Apply it Everywhere
I used this or similar approaches for different-sized work and at different stages. For example, when you want to fix something which you think takes you roughly 2 days you might hit up a colleague and discuss the What, How, and Why. That might take 15min and you covered your get Ready part. Now you answer those remaining questions like “How can I reproduce the issue in a test?” (“Learn”) and finally you fix it (“Do”). All the while you set yourself some time limits.
And then you have those large projects that take months to finish. The same approach applies now just on multiple levels. While your project itself goes through those phases you will work on different tasks or sub-projects all in their own state. You can repeat that down to a single task.
Another thing where you can apply it is in “normal” team operations. Instead of the usual refinement, why aren’t you picking up on some idea you had and making it ready? When you meet, show your sketch; when it sticks, let’s move into Learn and Do. This way everyone can contribute to the roadmap and influence where the team goes.
This is just to say it is turtles all the way down. I think you can apply the same approach on many levels successfully.
To wrap it up, to better deal with uncertainty and its symptoms like feature creep or never-ending projects Ready, Learn, Do might be a good path out of this hole. It limits the time you invest and gives you as a team transparency where you are at any moment.
Do you think that makes sense? Does this approach bring something new to the table? Let me know
Read on
You found a typo or some other mistake I made in this text? All articles can be changed here. If you want to exchange ideas then simply drop me a message at contact@paulheymann.de.