The life cycle of agile Software Development

The software development methodologies are still in the early days of their evolution.

The goal of any software development team should always be to deliver a solution to a user’s problem in the simplest way for both parties. However, building a simple solution that fixes a user’s problem is not as easy as it might seem.

I believe we still have a lot to discover in the field of building projects as a team. We transitioned from the homo sapiens era where we were leaving our caves to hunt and collect to an era where we realize that not every hunt goes on as we planned. We also moved from a generalist way of building projects to more specialized approach and therefore, the need for new rules and guidelines to work together arises.

The waterfall was our first approach to software development methodologies. Our paintings on a cave’s walls were what helped our leaders tell us their visions and plans. Scrum and Kanban came as a new strategy from experienced leaders – survivals from painful hunts. It is a strategy that takes into consideration changes in the initial plan because things sometimes don’t go as we plan. We became more Agile.

While the transition to Agile was a big improvement. We need to plan, write, code, build, test, deploy, maintain… together as a team, in a much more efficient way. Still, there is room for improvement.

Even when we follow an agile methodology, we are still going to do a lot of inefficient tasks. Most of our tasks are related to fixing our errors, planning our next moves, communicating and over-communicating, to prevent more errors.

The majority of our time is not spent on adding more value to our users, known as features.

The majority of our time is spent on fixing or preventing errors. We politely call them scope changes to our project, and they immerse from feedback loops and reported bugs.

The bigger a project grows the fewer features we deliver. The bigger a project grows the more time a team spends maintaining and fixing problems, and the less agile the project becomes.

Even though, we must always aim to work by an agile methodology. Why? Because the alternative is following a strict plan that will eventually fail. Even the most documented plan – based on months of investigations – is not good enough to prevent a failure. Why? Because as soon as we build something we gather new information by doing it. Information that may put the perfect plan in check. As soon as we show the result to end-users, they will react to that information.

Having said that, we have to first accept that a lot of the time we spend on our projects will be ‘a waste’ and that we don’t always know the best solution for our users. The best solution is most of the time found during the process of building. When we start, we think we have the best solution and of course, we should start building based on that first vision. Or we will be blocked by analysis-paralysis. However, we must also be aware that the plan based on that first vision will be misguided by the lack of information that may only appear after some user feedback, some proof of concept, or some MVP user interaction.

Other times, the plan will be misguided by missing communication between team members. Getting everyone on the same page can also be a hard task. Sounds like a good plan when we write extensive documentation and share knowledge with every stakeholder. But the more we write on that document or pitch to everyone, the harder it gets to make everyone pay attention to detail. The more people get involved in the decision, the harder it gets to reach a common vision.

So even the best plan will eventually fail or at least need a few changes.

Having that settled, we will be better aiming to fail as soon as possible.

The faster we know we are wrong the sooner we adjust to a better direction. A small correction at the beginning of our project will bring more advantages than a big change later in the game. It is better to aim for an approach that makes us more agile and prepared for the unknown – for future changes – an approach that is also error friendly.

So, we need to be Agile to protect ourselves from the waste of time, resources, and energy. That’s why we start seeing new projects growing in the field of development methodologies. Projects that help us reduce our errors. That bring a hybrid approach between man and machines, in the name of saving lost projects.

We now have Product Discovery that helps us validate our vision with more information.

We now have an Ideation phase to improve our creativity when doing brainstorms.

We now have Scrum ceremonies to help us manage an agile team.

We now have Kanban to help us maintain a flow of work looking at our team’s life cycle.

We now have Code Complete tools, that based on AI are ready to show us the most common and better way to do our code.

We now have data-driven decisions that help us decide on data and prevent us from doing leaps-of-frog as completely blind.

We now have Code Quality tools to prevent code smells and enforce some code standards.

We now have Devops to automate our build, test, and deploy tasks.

We now have Automate Test tools to prevent us from breaking things that were stable.

Technological projects will continue evolving bringing new challenges and increased complexity. I believe that development methodologies will be a class for our kids in school and I see a great and exciting future ahead in what regards to the evolution on the way we do things. Technology will continue pushing us forward, daring us to go beyond what we know and we need to be prepared with the best methods for the hunt!