Agility has been a buzz word for quite some time now. It started in the early years 2000 and curiosity for Agile methods does not weaken. They are still considered as the miracle formula to adapt projects to customer needs and be able to deliver the product of their dreams.
But when you start investigating and getting a closer look it is all not so obvious. My first objective was to identify and understand all existing methods. And I had some surprises!
A screening of existing Agile methods
A simple Internet search gives an exhaustive list of about 15 different
methods that are officially categorized as Agile. Among the most famous ones, you will find Scrum but also Test Driven Development (TDD) or Pair Programming. I had a detailed look at each of them, compared them and came to one conclusion: most of them are not Agile methods, they are even no methods at all.
For example, Pair Programming is a practice. It requires that two developers work on the same computer. One will be at the keyboard while the other will be the observer. So we have two brains working together. They can help each other and identify the flaws. This is a powerful way to obtain an even more efficient code and to allow each developer to raise his/her competence. But does Pair programming allow us to understand better our customer needs? Does it allow integrating new needs or getting rid of some of them? Answer is no. Having a go for Pair Programming is not going to make your team an agile team.
The same is true for many other so called “Agile methods”. Setting up TDD (Test Driven Development) will get you more quickly to an efficient code but is not going to help building an Agile team.
After all my screening, investigation and tests, I firmly believe that the only real method to build an Agile team is Scrum.
Scrum, your framework towards agility
For me Scrum is the only real method because it does more than just formalize one or two good practices, it gives a clear framework.
Scrum won’t tell you how to program but it surely tells you how to 
organize to make our team more agile. The Scrum framework is based on 4 events.
As you probably already know, a team working under the Scrum method organizes its work in iterations called “Sprints”. Each sprint lasts two to four weeks and is structured with the same 4 key events: Sprint Planning, Daily meeting, Sprint Review and Retrospective. These 4 events are team meetings that will structure your sprint and your work.
The product manager has then 4 different areas that are adaptable to customer needs. This is Agility! The real one!
- Your PM can, for example, decide to change the action plan for the next Sprint, move priorities, add or suppress functionalities during Sprint Planning.
- Daily meetings allow him or her to keep the team informed about the product and its evolution and avoid taking them unawares.
- Sprint Review is a privileged moment to collect customer feedback, integrate them in the next Sprint and therefore circle back!
- And retrospective, less focused on customer, allows improving processes and enhancing therefore working conditions for the development team.
All these are very simple meetings, coming from simple ideas, but they are tremendously effective.
Build your own Agilility recipe!
Please note though that Scrum helps defining and detailing processes but it does not explain how developers should work. It does not dictate good procedures for an efficient programing. But that’s also what makes the method so powerful!
It’s like a plain cake. Sorry if that sounds trivial.
You can leave the cake plain and it will be delicious! But you can also decide to add an ingredient for a new flavor! You will keep exactly the same base and just add something that will make your team appreciate your cake even more: chocolate, vanilla or fruit! Your choice does not matter as long as it makes the team happy!
To be more specific and come back to our subject, now that you have the recipe in mind, consider that our base for agility is Scrum. The method in itself is not difficult to adopt and establish, and once you get used to it, it can be satisfactory in itself. But you can also make your recipe tastier, adding Pair Programming to it if your team needs it. By doing so, you improve the process. Pair Programming grafts on the Scrum method.
You will then create your own Agile method, make your own mix, tailored to your team and project needs. Your team will initiate those additional ingredients as answers to the issues met. Test, learn, keep or drop, start again, progress, this is the Scrum method and philosophy.
All you have to do is listen! You will keep what works, optimize what can be and dare suppressing what does not fit with your team. As an example, I though Poker Planning would be great to evaluate development time as precisely as possible. But when we implemented it, I realized that it made no sense for my team. First, the measurement unit was too difficult to understand and apply. Second, and most important, my team was composed of experts. As such, they do not master other experts’ technologies and were therefore unable to evaluate development time for other team members. So Poker Planning which was a good idea in theory was no additional flavor in my own recipe.
I think you now understand my enthusiasm for SCRUM method. I use it as the framework for all my projects. It is very efficient and I can see the benefits in our daily life as we go along, sprint after sprint, and the team gains in autonomy and flexibility.
I hope that I stimulated your curiosity! Do not hesitate to share your experience on agility or your thoughts in the comments field. I will be happy to have your views!