Agile Methodology: the Aikido of the Companies
What do the martial art Aikido and Agile software development have in common? Embrace change as a core value. Aikido lays out that, like water, one must adapt to changing situations. One must join the adversary to redirect the attacker’s energy and achieve in this way the control of the situation. You must be one [...]
What do the martial art Aikido and Agile software development have in common?
Embrace change as a core value.
Embrace change as a core value.
Aikido lays out that, like water, one must adapt to changing situations. One must join the adversary to redirect the attacker’s energy and achieve in this way the control of the situation. You must be one with your opponent to achieve harmony.
In the same way, agile methodologies include Change as an element present throughout all stages of a project. One must know how to adapt to the changing situations and business scenarios that are common today. One should focus on listening to what the client needs and work with him in order to achieve his needs. The customers and the team that builds the software should be a unique team to achieve project success.
Different from other methodologies so called “traditional” or “waterfall”, Agile model uses an iterative approach. A deep analysis at the beginning of the project is not done, but instead planned deliveries with general functionality called “Releases” are presented. The scope of each of this deliveries is negotiable along the project lifetime. This highlights the core value that Change is Good and should be accepted at any stage of the project. This Release Planning generates a high-level schedule required for macro management.
Furthermore, tasks are planned and executed in constant time lapses between two and four weeks long, called Sprints. When starting a Sprint, the requirements are prioritized in conjunction with the customer in order to define the scope of the current sprint. Then all together define what will be built in that time frame based on the team’s available time or “team capacity”. This provides a more detailed planning of a short-term needed for better monitoring.
Also, there are short daily meetings with the complete team, for not more than 15 minutes, called “standup meetings”. This meetings have this name because the idea is that people do not feel comfortable standing still, in order to achieve the objective that the meeting must be focused and of short duration. During these meetings each team member comments three things: what they did the previous day, what problems were found and what they will do today. This provides an overview of the daily progress of the project tasks to all team members.
The above clearly shows that in an agile project, contrary to what is often thought, there is even more planning activities than on a traditional “Waterfall” project. A high level schedule is done by defining Releases. Sprints are used to plan in the medium term. And daily standup meetings are used to plan in a short, daily basis.
Due to the iterative approach and the objective to provide working software at the end of each Sprint, analysis, product development and testing tasks are performed throughout the whole project and not in consecutive steps. An important advantage of this approach is that errors or defects are detected early in the project. This decreases the additional maintenance costs that are generated by finding an error in an advanced stage of the project.
In “Waterfall” methodologies, when the testing phase is included as one of the final stages, these costs are inevitably generated. This is so, because when a bug is reported, it needs to be considered the time that will take the Developer to remember or analyze the functionality that will be fixed.. Additionally, analyzing and understanding the source code written to fix the error. And update the documentation in the case that it existed. And if the developer that corrects the error is not the one who codified the component, the time increase. Furthermore, to demonstrate that the product meets the requirements, at the end of each sprint a demonstration of the features added to the product is done. This moment is also used to perform a retrospective of what happened during the sprint. Here each team member has the opportunity to mention which things were done well and which things need to be improved.
This concept of generating a working product in each Sprint, forces to look at quality from the very beginning, encouraging continuous improvement sprint after sprint by doing the retrospective meetings.
Perhaps the most important concept in this methodology is the team spirit. The project is carried out by a single team. The customer and the supplier are part of a single team, because if one fails, the whole project fails and everyone loses. This causes a high interaction, providing transparency and visibility of project progress to the client and constant feedback to the development team. Therefore, team spirit, flexibility to respond to change and good communication are essential virtues for this way of working.
In Argentina, there are emerging initiatives (communities, courses, events) that seek to disseminate and share Agile experiences of this type. Globally, the U.S. and Europe are pushing the use of this model increasingly harder.
Why are many companies reluctant to use this methodology? Fear of change is one of the main reasons. Morihei Ueshiba, founder of Aikido used to say to his disciples that one must be like water from a stream, which adapts its shape and course to the river and then the ocean. Those who understand will be closer to Aikido and the Agile methodologies, and ready to adapt to new challenges.
@Diego Fidel Ferreyra
0 comentarios:
Publicar un comentario