Framework: Scrum and Kanban

Magical guide about #productmanagement . Part 4, article #30

So, let’s remember what Agile is — an iterative approach to project management and software development that allows teams to speed up the delivery of value to customers and avoid unnecessary headaches. Instead of releasing the entire product as a whole, the agile team performs work within small but convenient increments (stages). Requirements, plans and results are constantly checked for relevance, so that teams can quickly respond to changes.

What is Scrum?

Scrum is a technique that helps teams to work together. How a sports team prepares for a decisive game (by the way, scrum — Eng. “fight”, an element of the game of rugby), and the team of employees of the company should learn from the experience gained, master the principles of self-organization, working on solving the problem, and analyze their successes and failures in order to constantly improve. Scrum contributes to this.

Scrum methodology is most often used by application development teams, but the principles and experience of its use can be applied to teamwork of any kind. This is one of the reasons for the popularity of the technique. Scrum is often presented as an Agile project management platform. Scrum team members hold meetings, use special tools, and assume special roles to organize and manage work.

In this article, we will look at what the traditional Scrum methodology consists of. Scrum management and David West, CEO of the company, will help us with this Scrum.org . We will also look at examples of how our clients depart from the basic principles in order to achieve unique goals.

It is better to see once than to hear 100 times!)

https://www.youtube.com/watch?v=9TycLR0TqFA

The concepts of Scrum and Agile are often confused because Scrum is built around the idea of continuous improvement, which is the main principle of Agile. And yet Scrum is a method of work, and Agile is a way of thinking. Switching to Agile is not so easy; the whole team must strive to change its approach to creating value for customers. But you can just start using a technique like Scrum. This will direct your thinking in the right direction and help you practice Agile principles in everyday communication and work.

The Scrum methodology is inherently heuristic. It is based on constant learning and adaptation to changing factors. According to Scrum, the team does not know everything at the beginning of the project, but will develop by learning from experience. The Scrum structure includes the freedom with which teams adapt to changing conditions and user requirements. The workflow involves changing priorities and short release cycles, which contributes to the continuous training and improvement of the team.

Structuring does not prevent Scrum methodology from being flexible. It can be adapted to the needs of the organization. There are many theories about how Scrum should be applied to achieve success. However, more than a decade of experience in helping agile teams do their work with Atlassian products suggests that no matter which methodology you choose, its main principles should be clarity of communication, transparency and the desire for continuous improvement. The rest you are free to choose for yourself.

Scrum Artifacts

First, let’s define three Scrum artifacts. An artifact is something we create, such as a tool to solve a problem. There are three artifacts in Scrum: a product backlog, a sprint backlog, and an increment with your readiness criteria. These three constants are present in every Scrum team, we constantly address them and devote time to them.

The product backlog is the main list of tasks that need to be completed. It is led by the owner or product manager. This is an ever-changing list of functionality, requirements, improvements and fixes, from which tasks for the sprint backlog are compiled. In general, this is a list of the team’s tasks. The product owner constantly refers to the product backlog, changes priorities in it and maintains its relevance, because new information may appear or changes in the market may occur, which will make it pointless to perform existing tasks or new ways to solve problems will appear.

The sprint backlog is a list of work tasks, user stories, or bug fixes selected by the development team for implementation in the current sprint cycle. Before each sprint, a sprint planning meeting is held (we will discuss it later in the article), at which the team selects which tasks from the product backlog should be completed within the sprint. The sprint backlog may not be fixed and may change during the sprint. However, nothing should interfere with achieving the main goal of the sprint — what the team wants to achieve during the current sprint.

An increment (or sprint goal) is a ready — to-use final product based on the results of the sprint. At Atlassian, it is customary to present an increment at a demonstration at the end of a sprint, where the team shows what it has done during the sprint. The word “increment” is not so widely found in everyday life. It is often defined as the criteria of product readiness accepted in the team, a checkpoint, a sprint goal, or even a full version or an epic set. It all depends on what readiness criteria your team is guided by and how the sprint goals are chosen. For example, some teams prefer to release something to their customers at the end of each sprint. For them, the word “ready” means “delivered”. However, this may not be practical for other teams. Imagine that you are working on a server product that can be delivered to customers only once every three months. You can still split the work into two-week sprints, but the product will be “ready” for you when you finish working on a part of the larger version that you plan to deliver as a whole. However, let’s not forget that the more time it takes to release software, the less chances this software has to be successful.

As you can see, various options are acceptable, even when it comes to artifacts that your team can give one form or another. This shows why it is important to remain open to improvement, in particular to improving the way artifacts are maintained. Perhaps because of the accepted readiness criteria, your team is under excessive pressure and you need to reconsider these criteria.

Scrum meetings or events

A little more well-known are such components of the Scrum methodology as sequential events, ceremonies or meetings that are regularly held by Scrum teams. It is in the approach to meetings that the differences between the teams are most noticeable. Some teams find it a burden to hold monotonous meetings; in others, work meetings are mandatory. If you are just starting to get acquainted with Scrum, it is recommended to hold all the meetings during the first two sprints to understand your attitude to them. After that, you can organize a short retrospective to decide what needs to be corrected.

1. Organization of the backlog. This activity, also known as maintaining a backlog, is the responsibility of the product owner. His main responsibilities include bringing the product in line with its concept and constantly monitoring market sentiment and customer needs. To do this, the product owner maintains the list, changing priorities in it and keeping it up-to-date based on information from users and the development team, so that at any time it is possible to start working on the tasks included in it.
2. Sprint planning. At this meeting, the development team, led by a Scrum master, plans the work (sprint volume) that needs to be done during the current sprint. The sprint goal is selected on it. Then specific user stories from the product backlog are added to the sprint. These stories always relate to the goal. At the same time, the Scrum team coordinates such stories that can be put into practice during the sprint.At the end of the planning meeting, each member of the Scrum team should clearly understand what tasks can be completed in a sprint and how to set an increment.
3. Sprint. A sprint is an actual period of time during which the Scrum team collaborates to create a ready — made increment. As a rule, a sprint lasts two weeks, although it is easier for some teams to plan the sprint volume for one week or to set an increment with sufficient value for a month. Dave West from Scrum.org recommends planning a sprint the shorter, the more difficult the job and the more unknowns there are in it. But the team always has the last word. Feel free to change the duration of the sprint if it seems that it does not suit you. During this period, the product owner and the development team can review the scope of the sprint, if necessary. This is the key to understanding the empirical essence of Scrum. All activities, from planning to retrospective, are carried out during the sprint. After the time interval for the sprint is determined, it should remain unchanged while development is underway. This way the team will learn valuable lessons from past experiences and apply the findings to future sprints.
4. A daily Scrum meeting, or stand-up. This is a very short daily meeting, which for convenience is held at the same time (usually in the morning) and in the same place. Many teams try to keep within 15 minutes, but this is just a recommendation. Such a meeting is also called a “daily stand-up”, which emphasizes its brevity. A daily Scrum meeting is held so that each team member is aware of what is happening, does not deviate from the goal and receives a work plan for the next 24 hours. Stand-up is a good time to report everything that prevents you from achieving the sprint goal, including blockers. Most often, as part of a stand-up, each team member is asked to answer the following three questions related to achieving the sprint goal: ? “What did I manage to do yesterday?”? “What am I planning to do today?” ? “Can something stop me?” However, such a meeting can turn into people reading out entries from a diary. Stand-up is needed so that all the chatter remains within the framework of the daily meeting, and the rest of the time the team can focus on work. Therefore, if someone starts just reading out their diary, do not hesitate to make changes to the meeting; be smart.
5. Overview of the sprint results. At the end of the sprint, the team gathers to view the increment demonstration (or to study it) in an informal setting. The development team presents completed work tasks from the backlog to interested parties and colleagues to collect feedback. The product owner decides whether to release the increment, although in most cases the team gets the green light. At the outcome review meeting, the product owner also changes the product backlog based on the results of the last completed sprint. This process can move into planning the next sprint. If the sprint lasts one month, set aside no more than four hours for a meeting to review the results.
6. Sprint retrospective. A retrospective is held so that the team records and discusses all the successes and failures of the sprint, the project, the participants and their relationships, tools, or even certain meetings. The purpose of the retrospective is to create conditions so that the team can pay attention to everything that has succeeded and what needs to be improved next time, and not get hung up on failures.

The three most important roles on which the success of Scrum application depends

The scrum team consists of three separate roles: the product owner, the scrum master and the development team. Since scrum teams combine many functions, the development team also includes testers, designers, UX specialists and operations engineers.

Scrum Product Owner

The owners stand up for their product. Their task is to understand the requirements of the business, the client and the market. Based on this understanding, they prioritize the work tasks that the technical team will perform in the appropriate order. The following can be said about effective product owners.

• They make up the product backlog and manage it.
• They work closely with the company’s management and team, informing each participant of the importance of work tasks in the product backlog
• They give the team clear instructions so that its members know which opportunities to put next.
• They decide when to deliver the product, aiming to do it as often as possible.

The role of the product owner is not always combined with the role of the product manager. The owners strive to create all the conditions for the development team to create maximum value for the business. It is important that the product owner is one person. It is unlikely that the development team will want to receive different instructions from different owners at the same time.

Scrum Master

Scrum masters monitor the application of Scrum principles in their teams. They teach teams, product owners and the rest of the company the intricacies of the Scrum process and try to optimize the application of this practice.

The success of a Scrum master depends on how well he understands the work that the team is doing, and can help the team increase the transparency of work and optimize the product delivery process. This is the main coordinator who makes a list of required resources (human and logistical) for meetings on sprint planning and review of its results, stand-up and sprint retrospective.

Scrum Development Team

All the main work falls on Scrum teams. They are specialists in the principles of balanced development. The most successful teams are united, are in one place and usually consist of 5–7 participants. To determine the size of the team, you can refer to the well-known “two pizza rule”, which was formulated by the head of Amazon Jeff Bezos (there should be so many participants in the team that two pizzas are enough for them).

Each team member has their own competencies. Participants train each other to perform different tasks so that none of them becomes an obstacle on the way to the goal. Successful Scrum teams are capable of self-organization, and their approach to projects is imbued with a team spirit. All team members help each other to successfully complete the sprint.

Scrum teams make a plan for each sprint. They predict the amount of work they are able to do in an iteration, using their speed indicators in past sprints as a guideline. Due to the fixed duration of the iteration, the development team can analyze the correctness of the assessment of the complexity and process of product delivery, which, in turn, significantly increases the accuracy of its forecasts over time.

Scrum, Kanban and agile

Scrum is such a popular agile technique that many people mistakenly use the words Scrum and Agile as synonyms. But there are other popular techniques, such as Kanban. Some companies even prefer a hybrid model that combines elements of Scrum and Kanban. It is called Scrumban or Kanplan — in fact, Kanban with a backlog.

Both Scrum and Kanban use visual tools, such as a Scrum board or Kanban, to track the progress of work. Both methods are based on efficiency and the division of complex tasks into small work tasks that can be performed, but their approaches to achieving the goal differ.

Scrum is built around small iterations with a fixed duration. First, you need to determine the duration of the sprint, and then select user stories or product backlog elements that can be implemented during this sprint cycle. In Kanban, the number of tasks (or the amount of outstanding work — the WIP limit) that need to be completed in the current cycle is set initially. Then there is a countdown of the time it will take to realize these opportunities.

The Kanban methodology does not have the structure inherent in Scrum. It has a WIP limit, but all other aspects can be changed to one degree or another to taste. In Scrum, there are several strictly defined concepts: a review of the sprint results, a retrospective, a daily Scrum meeting, etc. Scrum also requires the formation of a multifunctional team so that the possibility of achieving the goal does not depend on third-party participants. Assembling an interpersonal team is not an easy task. In this regard, Kanban is easier to adapt, and the use of Scrum entails a radical change in the way of thinking and the specifics of the development team’s activities.

Why do we love Scrum?

The Scrum methodology itself is simple. It is not difficult to understand the rules, artifacts, activities and roles. It sets the structure, but it has freedom of choice, which eliminates white spots in the development process and allows you to take due account of the specifics of different companies.

Complex tasks can be organized into easily doable user stories, which means Scrum is ideal for complex projects. Due to the fact that roles and planned activities are clearly delineated, transparency and collective responsibility are maintained throughout the development cycle. The frequent release of products motivates the team and guarantees user satisfaction, because they see how the product develops in a short period of time.

Still, it may take some time to master Scrum, especially if the development team is used to the standard cascade model. The new team will have to choose a scrum master, get used to the world of short iterations, daily scrum meetings and reviews of sprint results. This can be a real shake-up of the basics.

But the advantages in the long run outweigh all the difficulties associated with the development of new principles. Scrum is successfully used in the development of complex hardware and software in a wide variety of industries and vertical markets. This is a good argument in favor of implementing the methodology within the organization.

(The matrix is intertwined with Atlassian.com )

What is Kanban?

Kanban is a popular approach to implementing agile and DevOps principles in software development. The methodology assumes a real-time performance discussion and full transparency of work processes. Work tasks are visually presented on the Kanban board, which allows team members to see the status of each task at any given time.

Although the Kanban technique originated more than 50 years ago, it is incredibly popular among modern Agile and DevOps development teams. At the end of the forties of the XX century, Toyota began to use the model of filling shelves in supermarkets in order to optimize the technological process. Supermarkets exhibit a limited number of goods, which at the same time is enough to meet consumer demand. This optimizes the flow of goods between the supermarket and the consumer. If the inventory level corresponds to consumer demand, the efficiency of warehouse management increases significantly, because excess inventory — which also needs to be stored somewhere — becomes less. At the same time, the supermarket still guarantees that the goods needed by the consumer are always available.

Toyota has applied this system in its workshops in order to better correlate the impressive inventory and the materials actually used in production. To track production volumes in the workshop (and interaction with suppliers) in real time, a special card, or Kanban, was used, which workers passed between teams. When the basket ran out of materials used at the production site, Kanban was transferred to the warehouse with the indication of the required material, the required quantity, etc. There was already a new basket with this material in the warehouse: it was sent to the workshop, and warehouse workers sent their Kanban to the supplier. The supplier’s basket with this material was also ready, and he sent it to the warehouse. Of course, in the modern world, messages are transmitted quite differently than in the forties, but the meaning remains the same — everything is based on the process of “timely” production (JIT).

Kanban boards

The work of kanban teams is built around a kanban board, which is used to visualize and optimize the workflow. Although some teams prefer real boards, virtual boards have long been a mandatory feature of any agile software development tool: it is easier to track processes, organize collaboration and access from different places with them.

The boards are needed to visualize the work of the team, standardize the process, and also find and eliminate blockers and dependencies. And it does not matter in what form they are presented — in physical or digital. On a standard Kanban board, the process consists of three steps: “Planned”, “In progress” and “Done”. However, the board can be customized according to the process adopted in a particular team, depending on its size, structure and goals.

Kanban’s methodology is based on full transparency of work and real-time performance discussion. Therefore, the Kanban board should become the only reliable source of information about the work of the team.

Kanban cards

Kanban literally means “visual signal” in Japanese. For teams using Kanban, each work task is presented as a separate card on the board.

Why display the work as a card on a Kanban board? Thanks to this visual representation, it will be easier and more convenient for team members to track the lifecycle of work tasks. Kanban cards display important information about a specific work task that is available to the entire team: the name of the person responsible for the task, a brief description of the work performed, an estimate of the required time, etc. On virtual Kanban boards, screen shots and other important technical details are also often added to the cards. When all team members see the status of each work task at any given time, as well as all related information, concentration increases, full transparency is provided, blockers and dependencies are identified faster.

Advantages of Kanban

Today Kanban is one of the most popular software development methodologies used by agile teams. Kanban provides teams of all sizes with a number of additional benefits related to task planning and performance assurance.

1) Planning flexibility

Kanban-the team concentrates only on the current work. Upon completion of the work task, the team picks up the next task from the top of the backlog. The product owner can change the priority of tasks in the backlog without interfering with the work of the team, since changes occur outside of the current work tasks. If the product owner makes sure that the most important work tasks are at the top of the backlog, the development team will be guaranteed to deliver the most valuable product to the business. Thus, there is simply no need for fixed-duration sprints used in the Scrum methodology.

2) Reduction of cycle time

Cycle duration is a key indicator for Kanban teams. Cycle duration refers to the time a work task goes through the life cycle, from the start of work on the task to its delivery. By optimizing the cycle duration, the team will be able to predict the delivery time of tasks with confidence in the future.

If several people have certain skills, the cycle duration is shortened, if only one — a bottleneck appears in the workflow. That is why teams strive to share knowledge and implement practices such as code checking and mentoring. Thanks to the exchange of knowledge, team members can perform a variety of tasks, which further optimizes the cycle time. This also means that in the event of a bottleneck in the work, the whole team will be able to take it up and restore the normal flow of the process. For example, testing is not always performed only by testing engineers. Developers can also participate.

In the Kanban methodology, all team members are responsible for ensuring that work processes proceed without a hitch, without a hitch.

3) Fewer bottlenecks

Multitasking kills efficiency. The more unfinished tasks, the more often you have to switch between them, and this affects the timing of their completion. Therefore, the key principle of Kanban is to limit the amount of work in progress (WIP). Work-in-progress limits allow you to quickly find bottlenecks and problem areas in the team’s work caused by a lack of attention, people or skills.

For example, a typical software development team can use four states of the development process: “Planned”, “In Progress”, “Code Check” and “Done”. For the code verification status, you can set the WIP limit equal to 2. The number may seem small, but there are reasons for everything: developers prefer to write their own code rather than check someone else’s. The low limit encourages the team to pay special attention to tasks in the verification state, as well as to check someone else’s work before creating their own code verification tasks. This ultimately reduces the overall cycle time.

4) Visibility

One of the core values is the utmost attention to improving the efficiency of the team with each working iteration. Graphs are a visual tool that allows teams not to stop there. If the entire team has access to the data, it is easier to notice (and eliminate) bottlenecks in the process. Kanban teams often use two common reports: control graphs and aggregate flow.

The management graph shows the duration of the cycle of each task, as well as the moving average for the entire team.

Comparison of Scrum and Kanban

Some concepts of Kanban and Scrum are similar, but these techniques use completely different approaches. They must be clearly distinguished.

Some teams combine the ideals of Scrum and Kanban into Scrumban. From Scrum, roles and sprints of fixed duration are taken, and from Kanban, cycle time orientation and work — in-progress limits are taken. But if your team is just starting to use Agile, we strongly recommend choosing one methodology and following it alone for a while. You will always have time to experiment. (The material is borrowed from Atlassian.com )

Conclusion

Today we have considered a flexible approach to project management — SCRUM and KANBAN. We figured out what they are good at and where they can be used. In the following articles we will look at the frameworks of the Lean methodology.

Thank you for your attention ??