You and your team just had a brilliant idea for a software that solves your client's problems and you're ready to start. How do you plan the whole project? First, you write down all the software’s requirements. After that, you specify the overall architecture and how the system will behave. Based on that design, you start implementing and, once the code is ready and all the components are finished, you start the user acceptance testing. Then, after fixing all the issues detected by the tests, you finally deliver the product to your customer.
If you are reading this post in the 20th century, the approach seems natural. Otherwise, chances are that you find major issues with this strategy.
The methodology described above is often referred to as the “Waterfall Model”. Under this model, all the development is made before sending the product to the customer. And seriously, how many times had the client come back to you to make changes or add features? So this is definitely one of this model's major drawbacks: the time you lose with the loop of getting feedback and, consequently, adapting to a change.
This was pretty much the standard way of developing software until the year 2001, when a group of developers, who called themselves the Agile Alliance, appeared. They were the creators of the "Manifesto for Agile Software Development", as an effort to disrupt how software was made. More than a set of rules, the document is a set of values and principles to guide an iterative and customer-driven approach to software development.
In my opinion, the biggest advantage of “being Agile” is to deliver more, deliver faster, deliver better. When delivering more often to your customer, you optimize your processes, you test your code away from your home, office or lab safe setup and, most importantly, you get the validation that your development is going exactly as it should. Or, in real-life scenarios, you learn from that feedback and quickly adapt your product towards your customer expectations.
So, should you classify Agile as a methodology? Personally, I consider Agile a philosophy that will help you create your own development methodology. There are, however, a lot of Agile methodologies that you should have a look at and learn from, before implementing it in your workplace. As an example, you have Scrum or Kanban for management practices or Extreme Programming (XP) for technical practices.
So why creating your own Agile methodology instead of using one of the above? Because I deeply believe that it should depend on your company’s goals and product(s) and, above all, it should be adapted to the people that will use it.
At Codavel, while developing Bolina, we started with a scrum-based methodology. Why? Because we love to talk. No, serious. We deeply believe that communication is a vital part of the development, and one of the key aspects of Scrum is having regular meetings.
The sprint at Codavel
The first thing each team does every sprint is planning. This takes place in a meeting with the entire team, where the Team Leader (our Scrum Master equivalent) presents the goals for that sprint and stories are assigned to developers. And although the team leader is responsible for this process, we always listen to everyone’s opinions and take them into consideration.
Then, we have daily stand-up meetings where everyone updates on their work, so the whole team is aware of the current status of the project. We make an effort to meet first thing in the morning, in order to minimize the impact on our daily work (in particular for the developers who suffer more from context switching). Most importantly, we make sure they do not turn into long-term technical discussions about one particular feature and that everyone has a chance to speak.
Finally, we have a retrospective meeting at the end of each sprint with all the engineering teams. At this point, every team shares what was done and what went wrong so that everyone can learn and improve for the following sprints. We also have periodic meetings between the Team Leaders, Head of Product, CTO and CEO to update and prioritize our backlog. This way, the development of the next sprints is aligned with our company’s goals and product needs.
As for the sprint definition, we currently divide our work into one-week sprints. Not only this leads to a more frequent communication between the teams, but it also allows us to quickly detect problems and adapt if something goes wrong. This does not mean we only release new features at the end of each sprint. We are huge fans of continuous development/integration, so as soon as a feature is complete there is absolutely no reason for not pushing it into production.
This is our current setup. And I emphasize the current because it is what it makes sense for us right now: It fits well into our company culture, it fits into our product needs and we believe it brings more benefits than overhead. But in any way are we bound to this methodology.
As our product and team evolve, our needs may change and others approaches may apply better. Kanban may fit better in some scenarios (such as customer support), some XP practices make sense for some teams while they are counter-productive in other, and so on. Although it may be rare, not even waterfall planning is wrong for every scenario.
So, if you ask me which Agile methodology should you choose, will I advise Scrum? No! Because I don’t like Scrum? Not at all. Just because I strongly believe you should find what is better for you instead of strictly following other’s advice. Always think of Agile as a philosophy and of any methodology as a recommendation. The implementation, which will definitely evolve through multiple iterations, is up to you and your team.