Know the difference between agile and traditional methodologies and understand how to apply Scrum and Kanban, agile methods that help teams around the world to produce twice as much in half the time.
This post is intended to help you apply scrum and kanban, bringing the difference between concepts that involve agile methodologies in a simple and direct way and, above all, how to include them in your team's routine.
Agile methodology vs waterfall methodology
According to Jeff Sutherland, in his book Scrum: The Art of Doing Twice the Work in Half the Time, there are two ways of conducting projects: the old "waterfall" method and the new, agile method.
The waterfall method is basically one that provides a sequence of steps that must be followed strictly, from the requirements survey stage to the customer's ok at the end.
This method, as beautiful as it may seem, mainly due to the various Gantt diagrams that are usually made and that detail exactly each step that will be performed, does not represent what happens in reality.
Unforeseen events happen and, as the waterfall method does not consider that unforeseen events may occur, it ends up taking much more time, consequently, more money and possibly not delivering something that solves the problem properly.
That is, the big problem with the waterfall method is that it does not take into account how people actually work and the various unforeseen events that can occur along the way.
For this reason, agile methodologies such as Scrum and Kanban emerged. As the name implies, these are methods that help teams to be much faster in their deliveries, saving money and, as we will see later, due to their routines, with a much greater probability of delivering something of value to the customer or organization.
Before we talk about the difference between Scrum and Kanban and how they work, let's talk a little about the agile manifesto, values and principles that guide Scrum.
What was the Agile Manifesto and what are its principles
In search of finding better ways to develop software, in 2001, Jeff Sutherland, Ken Schwaber and fifteen other leaders in software development, raised the fundamental values to help in this task, which became known as manifesto for agile:
Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan;
In addition to these values, they defined 12 principles that must be followed by agile teams:
Our highest priority is to satisfy the customer through early, continuous delivery of value-added software;
Changes to requirements are welcome, even late in development. Agile processes take advantage of changes for a competitive advantage for the customer;
Deliver working software frequently, from a few weeks to a few months, with a preference for the shortest time scale.
Business people and developers must work together daily throughout the project;
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and between a development team is through face-to-face conversation;
Working software is the primary measure of progress;
Agile processes promote sustainable development. Sponsors, developers, and users must be able to maintain a steady pace indefinitely;
Continuous attention to technical excellence and good design increases agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective and then refines and adjusts its behavior accordingly.
As we'll see below, Scrum is a framework that adheres to each of these values and principles.
What is agile Scrum methodology
Who developed Scrum, when did it start, and why?
Scrum was created by Jeff Sutherland and Ken Schwaber in 1993 and arose from the need to develop better ways of developing software, since countless projects, which until then followed the waterfall methodology, required a very high investment, took years, and did not deliver often. the expected value.
The context that motivated Jeff and Ken to create Scrum is presented in the book Scrum: The Art of Doing Twice the Work in Half the Time. In the book, Jeff Sutherland gives several examples of projects that had disastrous results in the past for not applying the agile values and principles foreseen in Scrum. The book's audiobook is also available from Audible, Amazon's audiobook company.
If you are interested in reading other materials about Scrum, we recommend the Scruminc blog, a company founded by Jeff Sutherland that helps hundreds of organizations and more than ten thousand teams achieve better results by successfully transforming the way they work.
How to form teams in Scrum
Scrum is just a means for teams to be able to deliver more value in less time, but without a well-trained and careful team, there are no routines and roles that are sufficient to generate results.
For this reason, understanding the most important characteristics in building high-performance teams is essential. At the article "The New Product Developement Game", professors Takeuchi and Nonaka listed 3 characteristics they found in teams in the best companies in the world:
Transcendent: Have a sense of purpose. They know why they do what they do;
Autonomous: have autonomy to decide how to do what needs to be done;
Multifunctional: they have enough knowledge on the team to carry out the delivery completely.
Being aware of these 3 characteristics will certainly help in the formation of your team and how to manage it.
Another important point is that the teams are small, from 3 to 9 people. More than that already makes communication between members complex, due to the increased number of communication channels, and can easily make the team unproductive.
Pillars of Scrum
But from a more technical point of view, what are the pillars that support Scrum and allow teams to work much better than through the traditional method? In line with the agile manifesto, Scrum has 3 pillars:
Transparency: Information must be available and accessible to all team members so that they have the necessary information to contribute to improvements;
Inspection: Stopping to evaluate what and how it was done is what allows teams to deliver more and more in less time;
Adaptation: Changing the route as unforeseen events happen is what allows something of real value to be delivered at the end of the project.
We will now see how these pillars translate into the routines and roles established in the methodology.
Scrum Ceremonies
Basically there are 4 ceremonies in scrum:
1. Sprint
Inspection and adaptation are evident pillars through cycles called "sprints". A sprint is the period in which the team works on a delivery before carrying out an inspection and collecting feedback and usually lasts 1 or 2 weeks (with a maximum of 4).
At the beginning of the sprint, the planning meeting takes place, when the team establishes the amount of tasks it believes it can accomplish during the cycle. That is, the tasks contained in the backlog are surveyed, which is the name given to the group of pending activities in the project, which must be executed in the cycle and passed to the "To be started" column of the Kanban.
At the end of the sprint, after the team's work on these activities raised for the cycle, the objective is to have something that can be tested and validated, so the concept of the Minimum Viable Product (MVP) is used, so that immediate feedback is received from the consumers.
2. Daily Scrum
The Daily, or daily meeting, aims to bring the status of what has already been accomplished and, mainly, to be a moment for alignment and support among all team members.
The Scrum Master (we will talk in more detail in the part related to roles) should ask the following questions for each team member:
What did you do yesterday to help the team complete the sprint?
What will you do today to help the team complete the sprint?
What obstacles are holding the team back?
In addition to answering these questions, the Daily Scrum has 3 other features:
All of the team must be present. Setting the same fixed time every day helps with this;
It should last a maximum of 15 minutes;
Everyone must actively participate. Holding the meeting standing is a technique that helps. So everyone just focuses on the meeting and tries to be as objective as possible.
3. Sprint Review
This is the moment when what was done in the sprint is presented. It is not necessary that a complete product be presented, but at least some complete feature, something that is capable of adding value already. In this meeting, other people from the company or client can participate, so it is not limited to the Product Owner, Scrum Master and Team.
4. Sprint Retrospective
The sprint retrospective is the time for the team to examine its interactions, practices and processes and identify where they can improve. Questions like these are answered during the retrospective:
How can we work faster?
Why didn't we anticipate that problem?
By answering questions about the team's way of working and making the necessary improvements for the following sprints, productivity grows, as what is wasting the team's time is being eliminated.
It is worth mentioning that the objective is to find a solution for how to improve and not to find guilty. For this, the team needs to feel safe to express their opinions and always in a constructive way.
This is one of the moments that highlight the importance of trust within a team. To go deeper into how trust impacts a team's performance, we recommend the publication in which we talk about the book 5 Team Challenges, written by Patrick Lencione.
Scrum roles
There are basically 3 roles in Scrum. The person can only be part of the team, be a Product Owner or a Scrum Master.
Product Owner
The product owner is responsible for defining "what" is to be done. He owns the backlog, what goes into it, and how his activities are ordered. That is, he is responsible for maximizing the value generated in the sprint, so to assume this role it is essential that he be someone who puts himself in the customer's shoes and is aware of their pains and desires.
A recurring doubt is the difference between the product owner (PO) and product manager (PM). The first difference is that the PO is a role, whereas the PM is a position. The second is that the PO aims to translate the business needs to the development team in order to consolidate the backlog and order it, while the PM aims to connect the product actions being carried out today with the company's vision of the future, or that is, it has a much more strategic function.
For those looking for certifications as a qualification to work as a product owner, Scrum.org (content in English) offers for different levels:
Scrum Master
Unlike the Product Owner, who focuses on "what" to do, the Scrum Master focuses on "how" to do it.
The Scrum Master has the role of helping the team to continuously improve the way it executes the sprint. He is responsible for conducting the meetings, ensuring that there is transparency and checking whether there is anything hindering the progress of activities.
As well as for product owner, Scrum.org also has certifications for Scrum Masters:
In addition to Scrum.org, other recognized institutions such as the Scrum Alliance e PMI have certifications in agile methodologies.
Using Kanban to Organize and Control Activities in Scrum
Kanban vs Scrum
Many people know that Kanban and Scrum are agile methodologies, but they don't understand that one does not replace the other. The truth is that they have very different objectives and can (and should) be used at the same time.
While Scrum helps in conducting work by establishing routines and roles among team members, Kanban is a framework that helps in the way activities are organized and visualized by the team.
The Kanban model is basically composed of three activity status blocks: To do (to do), In progress (doing) and Done (done).
Using Kanban gives clarity of the status of all project activities, sense of how fast it is going and gives transparency to all team members and allows them to make contributions, as it should be accessible to everyone.
Obviously Kanban is just a reference, other steps or groups can be added depending on the context of the area, project or team preferences.
We saw in the case of Scrum that we also need the Backlog group, which are pending project activities that should be worked on in future sprints.
How to scale Backlog tasks
In the book Scrum, Jeff Sutherland comments on how difficult it is to scale the time to perform tasks in hours. Either because we sometimes do something relatively new, with some specificity or due to unforeseen circumstances.
But the truth is that we don't need to be so accurate in sizing time, what we really need is to correctly sizing activities with a clear difference in execution time.
An alternative given by the author is to use the Fibonacci sequence: 1, 1, 2, 3, 5, 8, 13, 21... Using numbers like this helps us to have opinions about the size of a task and reach a consensus. It is much easier to discern a task that takes 5h from an 8h task than one that takes 5h and 6h for example.
Another point mentioned by Jeff is that the only people who can set the time for a task are those who will execute it, so don't delegate this task to other people.
This determination of the time of a task is very important so that, at the end of the sprint, the total time of all completed tasks is accounted for and thus having a sense of the team's speed and asking the following question: what is preventing us from working more fast? The retrospective is the ideal moment to answer this question and raise improvements in the way we work.
Tools for Applying Kanban
There are several tools that allow the application of Kanban, such as:
These are online tools that allow the registration, control and transparency of activities, but nothing prevents the team from using a whiteboard and post its for that too.
Step by step to apply Scrum in your team
In summary, for you to be able to apply Scrum and Kanban in your team, the following sequence of steps must be performed:
Define a product owner;
Choose a team;
Define a scrum master;
Create the backlog and order the tasks according to priority;
Refine and estimate the completion time of each task in the backlog with the team;
Hold the sprint planning meeting;
Make work visible through a Kanban;
Carry out the daily scrums;
Perform the sprint review through feedback of what was developed;
Conduct the sprint retrospective and improve the way the team works.
Brazilian graduated in Civil Engineering from the Federal University of Santa Maria (UFSM). Worked as a management consultant at Falconi on projects in the public sector, automotive retail, healthcare and pharmaceuticals, focusing on the application of PDCA to improve operating results. He is currently working as a Mkt Ops Business Analyst at RD Station, the largest SaaS company in Latin America.