Agile and Lean methodologies are widely used nowadays in software development and, when we use this kind of methodology, knowing how to change a big and complex problem into small problems is a fundamental skill. Only with small problems, it will be possible to create the many small frequent versions of a product and keep the focus on continuous improvement.
In a summarized way, I would say that the problem with the waterfall methodology is long planning time, that results in long development time, and any misunderstanding on the planning phase becomes an exponential problem for the resulted product. If that was a problem, why do I see more and more people insisting on getting all the answers to a problem before starting the development? Isn’t it a step back to the planning phase of the waterfall? How can we find a good balance between a good view of the whole scenario to have a good product and the abstraction of the details for not getting stuck in a planning phase?
Ok, one question at a time. First I will try to explain how I deal with complex problems. After having a good understanding of the problem, I try to break it down. This problem can vary from a new feature in an existing product to a whole new product, and the approach I use to divide the problem will also depend on that. Since a new product tends to be more complex, let’s consider this scenario.
At this point, we don’t need to go over each edge case. This is where the abstraction power takes place. We need to be able to identify the difference between what we need to understand now and what we can go deeper later since it can prevent us to go forward. I worked on a product in which it was important to explain to the developers the flexibility the final product would require. I had to explain to them the different behavior of the system for each country we had active business. We started with the country “A”, but the system architecture needed to be prepared to grow without the necessity of changes in the foundation of the system. And we only had all the details of the problems to be solved for country “A”.
In most cases I worked on, it was possible to focus on problem part “A”, without going deep on the whole problem. If you are working in a SaaS, for example, you can isolate each server to decrease the dependence between them as much as possible. On the business side, I analyze the dependency between the functionalities of the system, the integrations that may be required, and also the value that it will bring to the stakeholders. With all this information I select an initial piece of the product that we can start with, our MVP scope.
Software development is all about building something small, learning with it, improving it, and go back to the first step. This interaction will show us how to deal with edge cases, will answer open questions, will bring more questions, and at the end will result in a solid product. And besides the abstraction, the ability to assume the correct risks will help to make this an enriching process. Let’s fail fast, learn faster, fix it, and move forward.
What does it mean to take the right risks? I use a lot of my experience for that. As I worked a lot in financial systems, it is easy to make the decision on which risks to take. It is a mix of experience and gut feeling. And for that to work, the developer team must trust the PM.
I once had a developer questioning me with many “why’s” that I didn’t have the answer he was looking for, because my decisions where made based on my previous experience and my researches and did not come from an expert in the subject. As I was new in the team we decided to first hire an advisor, and at the end most of the risks I wanted to take on the decisions I made were correct. Not all bad, since now we were sure about how to move forward but we could have been more productive.
And once again I go back to the topic of trust between developers and PMs. But this is a big topic and I will still write about it in another post.
Now that we have our MVP (our next piece of the puzzle) defined, we can break it down again in small stories and start the development.
Long story (and long post) short, there is no perfect decision or perfect plan. What will make a good product is how we deal with the problems we face, how we work as a team, and how we trust each other in this journey. Maybe also teaching the new IT generation about the old methodologies would help them to understand the problems it caused and show them the importance of the abstraction.
