A few weeks ago in a meeting with a colleague, he told me that they were developing projects in his workplace using agile methodologies, something that was almost music to my ears.
When I inquired a little about the specific methodology, which he mentioned was “Scrum”, he told me that basically the changes to how they worked previously were at the level of the daily and short meetings that they now carried out.
I was introduced to Agile in 2010, while working at Admios on a project for one of the largest banking aggregators in the world. Before that moment I had heard the term, but I never paid more attention to it than I thought was necessary. Back then, if you had made me explain what Scrum was, it was likely that my answer would be very similar to my colleague’s, full of lack of understanding of the methodology/framework.
#.We are discovering better ways to develop software…
In February 2001, 17 people got together and created what we know today as the Agile Manifesto, which would lay the foundation for the agile methodologies that would formally emerge later, such as Scrum, XP, DSDM, Crystal, among others.
These people found common problems in the implementation of their software projects, which could be differentiated from the projects they usually developed. That is, they reached a common point in differentiating software projects (and other knowledge projects) from projects without high degrees of uncertainty (or complexity). For example: building a road after doing it a thousand times is not the same as building software to solve a specific problem that you have never solved.
Basically, they discovered “better ways to develop software”, as the Agile Manifesto begins, which was tailored to what they really needed. This does not mean that Scrum would work for all cases or that traditional methodologies would not work for some others.
Fig. 1 (The Spectrum of Process Complexity fn-3) shows when the use of Scrum is useful: when we know the problem, but not the solution to this problem. That said, it will always be necessary, as a Scrum practitioner (whether as the Team, as the Scrum Master or the Product Owner), to really understand the problem we are solving more than understanding how we are going to solve it.
#.Empirical Process ControlScrum is based on Empirical Process Control, which allows all decisions to be based on “observation and experimentation, rather than initial and detailed planning”, based on three main elements:
- Transaprence: Which allows everyone to discover everything, in an easy and organized way.
- Inspection: Which allows everyone to know the status of everything, at all times.
- Adaptation: Which allows, according to the inputs (the inspection, which arises from transparency), to evaluate and adapt at all times.
Daily standup meetings, known colloquially as “Daily Standup Meetings” (or Daily Scrum) only involve two parts of this process:
- Allows transparency, since throughout the meeting, everyone knows what is being done at a specific time.
- Allows inspection, since it allows me to evaluate the current state of the tasks at a given time (not as much as other elements of Scrum).
However, it also ignores (if executed incorrectly) the third element, adaptation, since the team may only meet for the sake of meeting and does not generate understanding and knowledge for the continuous improvement of the result.
#.Scrum as an incremental value delivery process
Having analyzed the theoretical spirit on which Scrum is based (Empirical Process Control), it is important to understand that Scrum is a framework, it is a process and as such it has an incremental and constant flow.
Applying Scrum is not only about meeting daily or understanding the way we develop software, it is about understanding the customer’s expectations (not what the customer wants, but what the customer needs) and delivering these expectations quickly, incrementally and iteratively, through a self-organized and collaborative team.
At the value level, it is important to always understand that the prioritization of these deliveries must be focused on the delivery of value, a process known as “Value-based Prioritization”. To do this, the voice of the customer (the Product Owner) must understand the problem that is required, in order to receive a valuable solution in a timely and continuous manner.
#.So how to apply Scrum in my organization?
After having applied Scrum in multiple organizations, the one that has always generated the greatest positive results is the following.
When implementing Scrum, it is best to initially implement it as indicated in numerous previous writings, such as the Scrum Guide fn-1 or the SBOK Guide fn-2 and then, based on Empirical Process Control, execute the necessary Adaptation, according to the needs that arise.
In the end and after many modifications, it is very common that in much more mature teams, practices or rules fn-5 from other methodologies end up being implemented, such as Pair Programming (XP, although it is usually half implemented), Test Driven Development (or Test First, as XP points out), Collective Ownership (XP) or Kanban Boards and Cycles (Lean/Kanban).