The Agile methodology
'Agile' was born several years ago, but it is a living methodology that has evolved and can adapt to the needs of each moment. Therefore, although it appeared hand in hand with the software giants, the digitalization of the company makes it applicable to practically any sector and to any type of company. Despite of the positive results, especially in software development projects, the 'Agile' methodology is not a whole in itself, but must be complemented with order, techniques and tools, so that the expected results can be achieved.
There is a lot of papers on the web and in the market about agile methodologies and their implementation. Like everything in the world of projects, not only a theoretical framework or an explanation of how Scrum, Kanban, extreme programming, etc. is needed. There is also a need for a framework that allows its implementation accompanied by personnel with the necessary skills that direct agile projects towards success.
Implementing this methodology in the software development process of a company can be a real challenge. If we only focus on the practices when implementing Agile, forgetting about the core, the Agile development objectives that sustain that implementation. It may happen that in the medium to long term, when difficulties arise, the company questions its proposals and abandons the use of the methodology; or even worse, such chaos is generated that everything goes out of control.
The intent of this article is to do a comparison between Agile planning and Traditional planning and their key characteristics and provide basic elements related to them.
Agile planning vs Traditional planning
Agile planning is part of the idea of planning based on business objectives rather than tasks (unlike traditional planning), prioritizing those who bring more value, and waiting to give details to objectives and tasks as it approaches the Moment of construction of these objectives, when the non-determination is being reduced, so that the effort to plan in detail is amortized.
Below, some common concepts and specificities of each of the planning approaches.
There are several basic concepts for planning a project:
• The Iron triangle, or triple constraint. The relationship between the project scope, time and cost, so that any modification in the one of these parameters will generate variation of another.
• If you want to deny this relationship and change any of these parameters forcing to keep the others fixed, there is an impact on quality, understood this as (1) provide the customer what he expects, (2) Minimize defects and (3) have a good internal quality of Product, so that modifications or improvements can be made to the product at a limited cost.
• The associated risks and the actions to be taken to mitigate them.
• External milestones that will condition partial deliveries, versions or phases.
• Functional dependencies and dependencies and integrations between technical components, which introduce precedence to consider in planning.
• The cohesion of the different works that are being carried out, so that they are saved efforts to tackle certain works in a joint way.
Traditional planning takes as a basis the predictive control of a project, which:
• It is based on the initial identification of the tasks needed to produce the product (WBS), an approach that is being modified (replanned) according to the future of events during the project.
• Usually makes a single delivery in its completion, so the feedback that is generated is late and, since it has built a lot of product without having verified its suitability, changes that are Necessary (if large and expensive) can compromise the time and budget of the project.
• At most it performs a single retrospective at the end of the project, so the lessons learned are no longer applicable in the project itself.
Agile planning is based on empirical control of product construction (inspection and adaptation), so:
• Project is phased based on product objectives (iterative and incremental development) prioritized balancing business benefits with respect to their development costs.
• Performs a very intense phase (from 2 to 4 weeks) with customer demonstrations of this product increment, making it easier to make changes that achieve maximum alignment with expectations and create a natural space for replanning strategic objectives not yet addressed.
• It has several levels of planning, since it assumes a horizon of uncertainty from which it does not make sense to plan detailed tasks:
o Strategic level: Product Backlog planning.
o Tactical Level: Task planning for the current iteration (sprint in Scrum) at the iteration planning meeting.
o Operational level: Daily rescheduling of iteration tasks as a result of daily synchronization meetings.
• Performs retrospectives throughout the project, in order to improve productivity and quality within the project itself.
• Makes the team participate in the process, both in the Planning (Project and Iterations) and in the improvement of the work procedure (retrospectives), adding as a quality parameter the satisfaction of the team, which is achieved through its participation Active, so that their involvement and motivation will revert to the outcome of the project.
“Being agile is no excuse for the lack of planning. The problem that development teams are trying to solve with agile methodologies is not to be so strict with planning and changes that may occur. Knowing how to plan enough and when to do it is the key to efficiency.”