Delivery in a world of uncertainty

The main success factor of the agile ways of working come from the increase of uncertainty in the world that we live in. Agile gives us a set of good practices that allow us to stay up in our surfing table while going through the waves of life.

This is most critically the case when we involve technology in any product delivery. A product itself has its own uncertainty related to “the hypothesis of value” and “the hypothesis of growth” as Enric Ries explains in one of my favourite books “The Lean Startup”. But when you add technology into the equation, everything gets more complicated (or interesting as I like seeing it).

When thinking about evolution I usually see the world rowing in a small boat and technology passing by in a speedboat always ahead and not even at its full capacity. That’s one of the reasons why tech teams need time in their agendas for learning. In whichever format, be it taking courses, going to talks, reading books or testing new changes in the software they use. But they need to stay up on track with the advances of their specialization. That’s why it also doesn’t make much sense to fix a plan for a tech development months ahead, because meanwhile something new may come up (such as a new iOS release) that changes many variables of your plan, either “for good” or “for bad” when thinking about release timings.

After all this, now imagine that you are asked to develop a new iOS app. Well, we have the different uncertainties before mentioned plus having to adapt to the different iPhone sizes (no iPad support), but as most of apps, so no big deal, right?

What if now we add new technology to the equation, be it developing this iOS app but not only in mobile support? You might be thinking about iPad support, and that would be “easy” as well. Many others have done it before, so there’s lots of documentation on the how to everything.

What if then we switch into app TV development? Or if we want this app to support in-car usage?

Well, definitely not the same.

I don’t know if you know much about it, but after a year working in a project with this exact context, I can tell you that there’s not much information shared, documentation or any other support out there for this kind of development. I won’t get into the tech details as that’s not my specialisation (one of my teammates wrote this article on the topic). Instead, I will share my insights and tips on how to handle such a situation from a product owner’s point of view.

TIP 1: Beware not to set release dates

I know this may seem impossible in some contexts, but trust me that in such a project it’s impossible to be certain about anything. The only thing I did know was what the team was going to be working on during the current sprint and what I had in mind were next priorities. But changes occurred continuously as we advanced in the project as we discovered new information, both from the user point of view (as there’s not many developments for in-car content, user research was key in the process of defining our product), as from the technology point of view.
How did we manage this with stakeholders? We agreed to develop a very minimum MVP (let’s call it mMVP) with which we could investigate, try and test all the incognitos we had at the beginning. This way we had broken all the major walls already while covering in a very basic form the initial needs. From there, we could start talking about more fixed releases and estimated dates as we had more info on what we were doing and what we needed to continue on. I would say, embrace fully the agile mindset and ensure your stakeholders understand the complexity behind.

Being very honest, at first they were reluctant to accept this plan, but I run a little experiment with them (even if they didn’t know it). The team and I estimated how long we would take to solve 2 of the incognitos we had. It was a coin toss kind of estimation as we didn’t have enough information to know how fast we could solve it. After finishing those spikes and being able to complete the first set of satisfactory tests I brought back to the stakeholders the comparison.

The task we estimated we would need 2 sprints for, we ended up needing 3. And the task we estimated we would need 4 to 5 sprints, we finished in just 1 sprint as we found a very easy but not at all predicted solution for it. With this information in hand, they understood the complexity behind what we were doing and they accepted that the team focuses on continuing removing roadblocks instead of spending time doing meaningless estimates.

TIP 2: Get comfortable with spikes

Many times, in product development, teams may need to action a spike to spend time investigating something needed for the continuation of the project. This is very common, but trust me, not as common as we experienced. Our first sprint was practically all spikes and I could say that we had almost a spike per sprint during the rest of the MVP development.

When setting these spikes be sure to be very specific and concise on which question or problem you are trying to solve. Each spike should only be answering 1 question/problem, so avoid those big lists of doubts to be solved at once. Prioritize as you would do with any other user story and ensure the team is focused in only one matter per task.

This may seem obvious as we all know it, but when finding yourself in such uncertainty, it’s very difficult to be concise as you know nothing. What I discovered was that the best way for our team to handle these big uncertainties was to have a spike that fed other spikes afterwards. So, from one initial, a bit more generalist, investigation, we would come up with new and more detailed questions and doubts to be solved that would get us closer to being able to solve an actual user story.

Remember it’s always important to set not only context, but a fixed timeframe for those investigations and even more in the case of those initial more generalist spikes as they could get totally out of hand.

We found many roadblocks, but as we advanced, we got more comfortable with the way we were doing spikes. I usually told the team that I saw them as “wall-breakers”, pushing the limits relentlessly and never accepting a “this can’t be done” for an answer.

TIP 3: Documentation is your best friend

I know, documentation generally is boring. But we all know it’s necessary, so let’s try to change our mindsets around it. This tip is very much related to the prior one. As we would finish any spike, we documented the results so that we could always come back to it when needed. It was very critical as well when new team members would join us. As I mentioned before, we were doing something very “new”, so a good set of documentation made our onboardings much easier.

Beware documentation should not be set in stone but should be maintained as a piece of code. Be agile, so iterate and revise it frequently to ensure it is up to date.

And when you have enough information, share it! There might be other people around the world suffering the same pains as you and finding the same roadblocks ahead as you did, so help them out by sharing how you solved them and your results whether it worked or not. Sharing is caring.

TIP 4: Be ready for “surprises”

Even in uncertainty there’s a moment when you think you have everything under control. Even more as a PO, you have identified with your team all the roadblocks ahead, you have prioritized them… you have a plan. And then something happens. Even if I’m generally a big fan of surprises, I can tell you sometimes they are no fun to deal with. The best tip I can give you in this case is to be ready for them. Do not plan too much ahead of time, as things will change. As I said in another tip before, embrace agile mindset fully and you’ll enjoy it much more.

If you are curious to know which were those “surprises” we found, check out this article from my teammate.

TIP 5: Trust your team

This is my last (in the order of this article), but very first tip I would share with all of you. Over the years in my experience, I have learned that when there is trust, there is greatness. In this very uncertain context, you depend very much on the team, on their knowledge, on their capacity to investigate and find the most efficient way to solve the problems/questions raised.

It can happen that a spike ends up without a solution, or that as we said before, a spike creates a new spike and the user story you wanted to work on is not ready for it yet. If your team tells you they need more time, trust them while at the same time ask as many questions as you need to understand the situation and be able to decide on next prioritizations as needed.

Of course, this is a two-way process and as it can easily happen in a very mature team, it may be more difficult in a newly built team. This was my case at the beginning as we didn’t know each other and we needed to find our space and our way of working together. For this, besides retros which are a very powerful tool I’m in love with, I know that what helped us was setting time for “informal coffees” all the team together. We would always set 30min of daily in our calendars, so that we could start with just a relaxed chat during the first 15–20min and then jump on to work with a better mood.

Have you experienced such an uncertain environment in your product development? Would you share any other tips on how to handle it? I’d be very happy to receive your feedback and any other tips you may want to share with the community.

If you like what you see and you want to motivate me to keep writing:

- Follow me to stay up to date with my thoughts!

- Subscribe to receive my texts right into your mailbox.

And if you want to talk with me directly:

- Let’s talk business? This is my LinkedIn profile.

- Instagram: @merinstyle