Working Agile: The Success of a Failure
Why should you invest your time in something that may be disposable? This is a question that developers often ask, and also a crucial part of working with an Agile mindset. I like to see it as the success of a failure, and I’ll make it clear why through a real experience that I’ve gone through at OutSystems.
A couple of years ago, my team had a new and very ambitious project at hand. We had to support millions of data transactions, and a considerable amount of data, processed at a daily rate. At the very least, this would take us two years to achieve, but here’s the thing: we knew that the opportunity existed and that it could deliver value to customers, but we couldn’t say exactly if it would have the expected adoption.
The Agile Mindset: Incremental Deliveries
To tackle the challenge ahead, we got together and started designing a solution with several things in mind: non-functional requirements (NFRs), avoiding impact and monoliths, full control over the solution, among many other things. Now, this would be the kind of thinking that would get us in trouble!
When designing a solution, it’s great to keep everything in mind. However, it’s even more critical to split into prioritized blocks of different technical functionalities. Effort should be balanced with value to create two different plans: one to build immediate value and another one for the long term solution.
A lot of people believe that big problems require big solutions. This is wrong. Big problems can often be solved with small solutions. This is possible because of the asymmetry between Actions and Results reflected in the Pareto Principle (or 80/20 rule): 20% of what you do addresses 80% of the problem. At OutSystems we use this principle coupled with an Agile approach to get stuff done.
Our goal was to have lots of customers contributing to millions of data transactions per day, so we knew our system needed to focus on scalability. However, it wouldn’t be wise to set up a system supporting that many transactions out-of-the-box if we wouldn’t have that large an amount right from the start.
So, why not do it incrementally?
As the graphic shows, that’s what we did. While the development team scaled the number of supported requests, we would onboard new customers for the already supported threshold.
Building The Agile Architecture
To build a solution that would grow incrementally, we had to tackle a different challenge: how could we keep changing the system without compromising it?
Through every step of the architecture design, we focused on developing small technical pieces — a small system, a code snippet, or a component, for instance — that came together and could be replaced at any time. You can think of them as a set of boxes, of which you only know what goes in and out.
You only need to design your system inputs and outputs, and the contract of each communication inside the system. A contract represents the specifications of what goes in and out of each box, and also what they should do from a functionality point of view. As long as the contracts aren’t broken, everything can change quickly and without impact.
The Agile Feedback Loop
We’ve seen that it’s best to have the architecture and development done incrementally. However, that’s not the end of it. Product releases can and should be incremental.
If your product provides real value to customers, chances are they’ll be interested in experimenting with it and giving you feedback. So, why not start with a minimum viable product (MVP)? You won’t invest too much time and effort in it — it took us around two months to build the MVP with OutSystems — and you’ll add immediate value to customers. At the same time, you’ll also collect valuable insights that’ll allow you to incrementally perfect the solution as you go!
This is an excellent opportunity to test your interfaces and usability, but your real focus should be on the customers. Is your solution addressing their needs? Are you missing something? Should you invest more in a specific functionality, or is it not worth it at that time?
For this project, we decided to start with an internal early access program (EAP), where we had a few of our teams use the product, as would our end users. Feedback loops are faster when these trials are done internally, and it allows us to evolve the product enough so that we are confident that it’s ready to go public.
Fail Fast, Learn Fast
After iterating with some customers, we realized that while we had created value for some of them, we wouldn’t reach the desired adoption in the expected time. Does this mean that we failed? Not necessarily.
If we had designed and implemented the whole system and realized that it would never face proper growth, we would have wasted at least two years of a six developers team, all for nothing. But since we started the project with an MVP, broke it in modular pieces and iterated progressively, we learned the lesson in far less time, with far less risk, taking those lessons forward to our next project.
It was our Agile approach that allowed us to turn this into a success. When working in small increments, your system components have independent life cycles, you can accelerate delivery and feedback cycles, and you’ll simplify the architecture of your solution. However, the main benefit is that you’ll always look at a project as proof of value.
You’ll continuously iterate alongside your customers to understand if the solution has value for them. At any point, you can realize that you don’t have enough data or value to continue solving the problem. Then, you can either drop it and cut your losses or invest in more discovery to get a better understanding of how to bring more value to your customers.
Why not try this approach the next time you kick a project off? Take a look at this online course and learn more about the Agile approach and how we use it at OutSystems!
