There are plenty of agile methodology variations, including Scrum, Kanban, Extremme Programming (XP), Feature-driven Development (FDD) etc, with Scrum being one of the most popular methodologies used by teams. The adoption of older software development methodologies, such as Iterative Model, Waterfall and Spiral, are considered outdated and so are rare to find in modern and evolving development teams.

If we look at Scrum more closely, we can see that the Scrum Guide documentation is quite restrained in it’s detail, when compared to alternative approaches, such as the IBM Rational Unified Process documentation. As stated in the Scrum Guide, Scrum as an approach is lightweight, simple to understand, and difficult to master. The “how” part, meaning the practices implemented, is simple to understand; however the “why” part is nowhere near as clear. Agile methodologies are essentially a reaction to drastically improve older methodologies like Waterfall, and so it is often assumed that development teams are already knowledgeable on the issues found in the practice of these older methodologies, and so have the knowledge or background on the “why” of new and revised agile practices.

For those who understand the pain of getting the requirements and software to be “validated” using common practices in older methodologies, such as using prototyping or screen demo to validate the requirement in the early part of the project, or having the requirement document reviewed by the client, will appreciate and understand the benefits of having a Product Owner (PO) embedded in the scrum team. When we refer to “validation”, we refer to making sure the software will fulfil its intended use, or making sure that the requirement is right. It is often quite difficult to get the proper PO embedded to the scrum team and without understanding the importance and complexity of the issue being solved by this practice, many teams will instead cut corners in assigning the right PO to the project and may come up with a ScrumBut, or workaround, such as a “PO Proxy”. This is detrimental to the entire approach and negates the solution found to the issue raised in older methodologies by agile. An understanding of WHY having the PO embedded in the team is essential to the success of the project as a whole.

If we look at scrum duration in the Scrum Guide, it is written that Sprints are limited to one calendar month, with some explanation that if a Sprint’s horizon is too long, the definition of what is being built may change. Those who have followed a Waterfall development methodology will often have seen that the requirement documentation is written in the first month of the project, followed up by with nearly a year of software construction activities, and finally a UAT. During that time, the development requirements are sure to have changed from those documented in the first month of the project, and may no longer be relevant. The process to then change the requirement can be quite costly.  When following the Scrum methodology, where a Sprint limited to a maximum of one month and each Sprint may be considered a project, the cost of any change in direction of the project requirement can be significantly minimised.

Events are time-boxed in Scrum, including the planning events, meaning that a maximum amount of time is allowed for each project or activity, allowing you to define and limit the time dedicated to that activity. In Scrum, planning activities are also time-boxed and consistently repeated through each sprint. There is not much pressure trying to plan everything in the beginning and having the detail plan be accurate, ensuring that the project can evolve and change with the changing and updating requirements as they are uncovered. This is in complete contrast to the Project Management methodology applied in the traditional Waterfall project and Iterative project. In Waterfall or Iterative Methodology, teams will usually try to plan as much as possible in the earlier part of the project, despite the uncertainties or unknown factors which will undoubtedly influence the plan, making them difficult to account for. This means that any initial plan may fall short in detail or be simply inaccurate due to a lack of detail about the project.

Agile methodologies are developed as a lesson learned from previous or older methodologies. To fully appreciate and master the practices in agile methodologies, it is not enough to focus on the “how” of performing agile practices, but teams and Product Owners must understanding the “why” of those practices and the background as to how they came to be necessary. This is especially important when trying to modify or combine practices from different agile methodologies, as understanding the context or background of particular practices is necessary to ensure the right approach. The “how” and the “why” should work together to create the most successful outcomes in your development team.

Author:
Rommy Rempas – Engagement Manager