Reducing Risk during software development.

They say there is a secret formula in life: Happiness = Reality/Expectations. This means the higher your expectations are the less happy you are going to end up being as a person. I can think of many similar formulas in the software world, one of them would be:

Photo by Kelly Sikkema on Unsplash

Happiness = reality/overoptimistic estimations

Developers seem to be from their nature optimistic people. Tasks always seem to be about “80% ready”. Even very experienced developers have difficulties making precise estimations. There are many things that are wrong about estimations and how we make them, but no matter how we are going to estimate, estimations are required, because we need a “plan” for when we are going to release. Company stakeholders want to see “plans” and estimations are the backbone of every plan.

Plans usually fail. Eisenhower has been quoted to say: “plans are worthless, but planning is everything”. Despite Eisenhower’s words, even the most agile product teams in the most agile companies have to present plans to their stakeholders.

The leading question of this blogpost ist:

“How can we help product teams come up with more realistic, less failure prone plans”?

Our example: a customer journey for applying for a digital loan

Let’s say that we want to plan the development for an application that allows customers to apply for a digital loan. The basic steps in this customer journey would be:

1. Entering the key data for the loan want, these would be: the amount of money you need, the number of months you will need to pay back the loan (this influences the monthly payment of course) and the purpose of the credit.
2. Viewing the offers you will get, after you have entered the data. Now, this is where it starts getting interesting. There are many options we can provide to improve the experience for a customer. Should we let her sort the offers? Should she be able to filter out options? Can she apply more than one filters? Should we provide the option to directly compare two offers? What about comparing three offers? There are endless possibilities we can provide to the customer, all of them increase the development time though, and also the risk of delaying the release of our software.
3. Going through a credit check. This requires from the customer to enter the information required to apply for the credit (this includes personal information like the customer’s salary, whether she has a mortgage, etc.). Here again we have many options with the potential to vastly increase the complexity of our software. How will the customer enter his birthday? Do we provide a date picker provided from the operating system? Does the CI of our company require from us to implement another date picker? How does the customer enter his address? Is it just a textfield? Do we validate the address? Do we provide auto-completion to improve the usability of our customers?

Figure 1: A depiction of a vertical backlog.

Now, based on figure 1, we could proceed and make the cut(s) to the backlog with the sprints shown in figure 2.

Figure 2: A depiction of a vertical backlog with theoretical slices for sprints.

This is basically a “vertical” slicing of the steps required from the customer in order to apply for a credit. After the first sprint, the customer will be able to enter the information required in a credit calculator, after sprint two, she will be able to view a list of offers etc.. An end to end journey will not be possible until much later (sprint 5).

An end to end journey will not be possible, if applying vertical slicing, until much later.

It is also possible that there are risks throughout the journey of which we are not aware yet. For example are we sure that we can integrate with all the systems required in the further steps? What if for example we need some kind of authentication (which we have completely ignored in the beginning) from a user to see the result of her request? So many unknowns.

A horizontal approach for our customer journey

Let us flip the above image and think of another approach to tackle the implementation of our software. Take a look at Figure 3.

Figure 3: A horizontal approach for implementing the customer journey.

We have the same steps and the same stories, but now everything looks more horizontal. Take a look at figure 4, which depicts a different way to slice the sprints with this approach.

Figure 4: A horizontal approach for implementing the customer journey with a slice for an MVP.

At the end of this first slice, we would have a software that doesn’t look polished, offers average UX, and does not have much features. We have enough features to release though so that the customer can have an end-to-end experience. Now, we can start thinking and experimenting in order to improve the customer experience.

Of course we may not want to release this to everybody, but testing ad running experiments in a small group would help us improve our software based on data and real customer and not based on assumptions.

We have eliminated two kinds risks. Technical risks by developing systems that do not integrate well with each other, and business risks by avoiding and optimising software and features that customers do not require.

Conclusion

When beginning the development of a new product, service or feature think of how you can “cut” the tasks in a way that you eliminate risks ASAP. A horizontal visualisation of the tasks you have to implement and the steps required from a customer perspective, can help you find the ideal cut. Applying a technique like user story mapping [1] can help you achieve this result.

p.s. All opinions in this article are personal and based on my experience of developing and designing software for over 6 years across multiple industries (education, start-up, e-commerce, retail and automotive).

[1] affiliate link from amazon