A reflection on the agile fail-fast principle

I have decided to write 52 posts on dev.to in 2023 publishing one every week, this is the second post.

This is my reflection on the fail-fast principle and the culture I have seen in relation to interpretation of that particular topic.

My last post received some good responses. I have yet not had the time to reflect and respond to all, but I will get to them. I can only hope that this post will trigger some feedback as well, since it is enlightening to get feedback on what your do and what you perhaps need to do differently in the future, the post is quite opinionated, but I do appreciate feedback, which brings me to the topic of the post.

The fail-fast princiciple in the form that I know is rooted in the agile software development movement.

The idea is that it is important to ship to customers rather that to sit on value propositions, since the feedback is key and essential to iteratively reflect and improve on the value proposition. This is fundamental to the agile methodologies. We need to bring value and we do this is dialogue with the customer rather than via declarations from an ivory tower.

I found an Article on Forbes, which reflect on the dangers of misinterpreting the fail-fast principle, due to the disruption it might cause in an organization. I think the this is the central challenge of the fail-fast principle. I do however want to reflect on a secondary perspective of what the Forbes article touches on, the consequences for the deliverable, where the Forbes article is focused on the organization and the employees, I want to talk about the product.

My current job is as a product manager and I have been following the agile software development movement for as long as I have been involved in software development. The introduction of modern agile software development in the in the 1990'ies coincides with my career since I started working in the 1990'ies with IT.

I do not believe my take on software development is by no means special or unique, but I want to emphasize a few of the points I have observed in regard to the fail-fast principle and the field between software development from a technical and business perspective.

Software development is a production activity. You can frame the activity differently so it meet different outcomes based on you expectancy.

• Prototyping: You create a prototype in order to get a proof of concept. That can be to answer questions perhaps in in regard to:

• Introduction of new components

• Performance measure meaning

• Architectural evaluation

• Demonstration of main goal or gap analysis

When you do a prototype you can leave out a lot of the activities you would normally find essential to do when producing and shipping software, like:

• Documentation
• Monitoring
• Security evaluation and penetration test
• Code review
• Tooling, like installation, backup facilities etc.

You mileage may vary depending on what question you want to answer with your prototype, what framework you are building it in and of course how you want to collect data collected from your prototype.

Because you are going to throw it away.

I believe it is important to throw away the prototype, since it might not have followed all of the standard practices of your development requirements, so it will not live up to the expected standards, it serves only a single purpose - to answer the questions or shed light on a particular uncertainty.

You need to do some documentation, to see if your prototype has answered your questions, whether it has matched up to your original request or has minimized the area of uncertainty. If not it might be necessary to do additional prototypes.

To some managers prototypes are scary, but they do them without understanding why and what value they bring to the table. A situation as the one described in the Forbes article might very well occur and as a software developer you might be met with terms like:

• Time-to-market
• Return-on-investment

As attempts and arguments attempting steer your away from doing a prototype. IMHO prototypes are very important to minimize uncertainty before embarking on development to deliver a value proposition.

Which brings me back to the role of software development as an activity. When we deliver software to end-customers, it comes with a lot of uncertainty. That uncertainty should not be founded in:

• Does the software work?
• Does the software perform?
• Is the software stable?

Yes, we will ship bugs, the software will have issues, that need addressing, but this is not a failure in the sense of failing fast.

We need to ship software that is:

• Stable
• Performant
• Working

And we will be testing and measuring the software all throughout the development process.

• Unit-tests will tell us that the software works
• Integration and load testing will test us if the software is stable
• Benchmarking will tell our how the software performs,

And any combination of all of the above together and together with AB testing etc. will tell us that our software works and can be shipped.

Finally the software has to meet the business.

This can be acceptance testing or the software is shipped to end-users (customers), perhaps a subset of known users doing user-friendly testing. Or the software is presented in to users in setup where their user experience is observed and recorded.

The important aspect where it that when software is delivered it is finished in it's current form.

We should not:

• Treat our end-users as testers
• Bother our users and their use with trivial issues

What we want to measure at this point is whether the software meets it's goal of the value proposition.

As a product manager, I might do prototypes also, but these are of a different form and with a different goal and is to shape the value proposition before it is presented to the developers.

That might be activities as:

• Customer interviews
• Surveys etc.
• Pen and paper prototypes
• Mock-ups and design sprints

These are not software related directly, but are business activities.

Now to get back to our software development activity. Another framing of the software development activity, is writing software to ship to customers, where no prototype is required since you have no particular uncertainties you need to have an understanding of before developing the value proposition.

This covers the most common software development activities. Well if you want to do prototypes prior to actual development, by all means you should, but it should not be necessary to do so if you are building on a a working, stable and performant foundation, unless you have uncertainties that need clarification since then might challenge the value proposition.

The outcome of the development process should be:

• Stable
• Performant
• Working

At the same time we should be aware of:

• Destructive changes
• Regression

The destructive changes are very much a business aspect and it should be a part of the overall value proposition, examples:

• We are removing feature A
• We are replacing feature A with feature B
• We are extending feature A

That is not necessarily the concern of the software developer, but the product manager and the responsibility of communicating this is with the business not the software development team.

Now that we have a a product, which is:

• Stable
• Performant
• Working

And we can clearly communicate:

• Introductions / New features
• Changes to existing features

We can new measure the success of the value proposition, we should not aim at the success of our software development process, that is up to the software development team to measure.

As stated we might encounter bugs, we might experience bottlenecks, but we we should aim to not have this kind of challenges, since we want to evaluate the value proposition, we do not want to muddy the water with broken software mechanics that could have been avoided by being addressed during development.

It is okay to be concerned with the product as product manager, after all you are it's champion, but be aware that if you as a product manager get lured into only measuring:

• Amount of features shipped
• Amount of bugs
• Performance of features

And not:

• Does the software meet it's value proposition

If so you are not covering the main area of the product managers area of responsibility and you cannot evaluate the next or the next iteration of the value proposition.

You should see if the value proposition fails and learn, adapt and iterate.

I know this piece sets some hard boundaries between the development and business, between the product manager and the developers, but these are all just roles playing different parts in the overall SDLC. As a product manager I work very closely with the development teams I work with.

• The moment they are uncertain - I propose a prototype
• When a value proposition (user story / epic) is unclear I try to make it clear, having a call or short a meeting
• When we have discussions or are stuck, I propose inviting their colleagues to gain perspective and suggestions

I do all of this so the software developers can focus on there area of responsibility, software development activities which:

1. Deliver the value proposition
2. Deliver software that is:

• Stable
• Performant
• Working

I am by no means perfect and if you talked to any of the developers, they could probably mention several examples of unclear requirements etc. but I aim to do my best or at least do better the next time and keep an open channel for feedback and dialogue.

I have mentioned the importance of being able to measure the value proposition and the requirement for software meeting certain quality requirements. The last part I want to touch on is the side-effect of not doing so.

What I have observed here is:

• Lacking trust in the system stability and correctness
• Lacking believe in new value proposals

And eventually:

• Lacking involvement in new value proposals

So by delivering inferior quality, you loose your users, you might not loose your customers, but you loose the foundation on which you want to iterate and make value proposals - depending on your business you might loose you customers in the end.

Why should the user welcome the promise of new feature if the existing feature does not work as promised

Users are an asset. If you can build a relationship with them, where you can use them in your product development:

1. What you deliver bring value, so you might not have to deliver so fast, as long as features have a certain quality
2. You meet users requirements and they will provide you with feedback for the next iteration, not spend all of their time reporting issues and regressions

The dialogue will become more constructive and IF you fail occasionally, the users will understand and they will not make a big thing out of it. Whereas if you constantly let your users down, you will loose their confidence and trust and the dialogue will no longer be as valuable as it could be.

Embrace agility and embrace the fail-fast principle, and do not be afraid to fail on value proposals , but do not fail on fundamental software mechanisms where we have methods and tooling to minimize or avoid so.

Iterate and deliver value on the next value proposition based on date from measurements and feedback from your users.

Do not believe that a single new feature can patch a broken system, especially not if you are not sure it even has the quality to stand alone.

Do not only measure:

• That you have delivered
• That you are within an acceptable number of bugs
• That performance is acceptable
• That the systems reliability is with in an acceptable range

You want you users to talk about value not:

• Bugs and workarounds
• Slow and useless features
• System downtime
• Lost productivity

And finally:

• The competitor or another product, who's promises sound so much better

You have the users now, nurture them, listen and your product will become a success.