Agile, Scrum, Kanban  -  Demystified

What is agile really about?

Agile is a philosophy, centered around 4 core values and 12 principles. It’s often explained through software development, but it can easily be translated to any industry.
Agile core values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

‍
I won’t go into principles, as those are centered around values anyway, but if you’re interested, you can find it on the official agilemanifesto.org site.

In case you already tried it and you’re still finding yourself confused about the topic, I can only say — it is expected. After all, agile is here to help you with prioritizing what’s more important.

Now that you understand what is agile, let’s get into the two most common “implementations” of it — Kanban and Scrum.

Kanban

Kanban is technically, a Lean tool.

Lean is another philosophy just like agile, but focused on different values, although it still aligns with agile in some sense. Lean is really nothing new —it was made up in the late 40s in the Toyota Production System and was initially used in vehicle manufacture.

Lean is a pull system, just-in-time, with one core idea: Minimize waste while maximizing value.

In pull systems, production is driven by customer demand. Push, on the contrary, is focused on producing as much as possible and then forcing the launch to the market.

So having that in mind, Kanban is a tool designed to maximize value, but also to raise alerts when there is a bottleneck that affects the production. It’s based on a continuous improvement foundation and it’s incremental. Incremental means that the finished work goes into product extension and directly brings value to customers. Continues improvement speaks for itself — the process should evolve to always become better.

How does it work in action?

The workflow consists of 3 major steps:

1. To do,
2. Doing,
3. Done.

‍
You’re flexible as long as you keep those steps fixed. For example, we usually separate step “Doing” into “Development progress”, “Development resolution” and “Testing progress”.

For Kanban, it's important to restrict the work in progress, which leads to “waste” control, as you can easily determine the problem when the limit is reached. For example, when you get a red flag on the Done column, you need to check what’s wrong with the deployment system.

There are some additional principles, but I won’t go into too much detail. Let me just tell you that Kanban also instructs to start with whatever you have at the very moment and you are free to keep the company roles, responsibilities, leadership structure or current processes.‍

‍
Scrum‍

Scrum is defined as a framework for developing and sustaining complex products. But according to Scrum creators Ken Schwaber and Jeff Sutherland, this is not the whole definition. The whole definition consists of Scrum roles, events and artifacts with the rules that connect everything together.

Scrum roles

A Scrum Master, Product Owner and a Development team all form a Scrum team.

The Scrum Master is responsible for ensuring that Scrum practices are followed. A person is a facilitator, known as a “Servant-leader”, who encourages and stimulates self-organization among the Development Team. It sounds hard to do, and it is. Although responsibilities are clear, there’s a certain confusion about the right approach in practice.

The Product Owner (PO) is responsible for maximizing the “return on investment” (ROI) for a product. He/she tries to get the highest possible value for the target group, with the help of the Development team.

In practice, it means that the PO selects the most attractive features for the product, based on the market research, stakeholder input, analytics or forecast analysis. Everything needs to be aligned with the product vision.

The Product Owner puts ideas and insights into the format of a user story, into a list called Product backlog, prioritized by business value (most valuable items go first). A user story is a user-centered requirement, which tells the Development team what and why something needs to be done.

The Development team is a self-organizing, cross-functional team of members that are collaboratively responsible for developing and delivering the product. While the PO tells the Development team what needs to be done, the Development team decides how it will be done, and this is what self-organization stands for. Cross-functional means that it summons exactly those experts that are necessary and sufficient for the development of one product increment. In a mobile application, the Development team at COBE Tech would include a designer, Android developer, iOS developer, Backend developer, and Quality assurance engineer.

Product increment, in this case, is made up of those stories that were done in the current iteration. And the iteration in Scrum is called a Sprint.

Scrum ceremonies

Sprint planning is a meeting organized at the beginning of a Sprint, where the PO explains to the Development team what the most important for the product at the moment and why. The Development team then estimates the effort and selects the amount of work they are willing to commit to. That set of selected items for a Sprint is called a Sprint backlog.

Daily Scrum is a short meeting on a daily basis (limited to 15 minutes), where the Development team synchronizes the work they’ve done. Every team member informs the rest of the team about the tasks that were done yesterday, and about the tasks that they plan on finishing today. If there is any impediment that blocks the progress, the flag is also raised on daily meetings, but the resolution comes afterward.

‍The Sprint review is a meeting organized at the end of a Sprint, wher e the Development team demonstrates to stakeholders the work done in the Sprint. Stakeholders give feedback and in case any change is needed, it goes into Product backlog on the corresponding position, depending on the business value.

The Sprint retrospective is the last meeting in the Sprint, and the point is to reflect on the previous work with one and only goal: to improve the process in the future. The team tries to find the concrete actions that will help to smooth the flow, increase efficiency and productivity.

Scrum artifacts

Scrum artifacts (according to the Scrum Guide by creators) are Product backlog, Sprint backlog and Product increment.

I won’t go into details but let me summarize what we already went through:

The product backlog is a prioritized list of items that will bring business value to the product.

A Sprint backlog is a set of most valuable requirements for the product at the moment, prepared by the PO and selected by the Development team that commits to finishing it by the end of an iteration.

The product increment is a deployment-ready product extension, that contains functionalities given by the stories in the Sprint backlog.

In some literature, you can find additional Scrum artifacts like Product backlog refinement, Definition of Ready and Done, or Burndown chart — so let’s explain those terms as well.

Product backlog refinement is a procedure of managing the Product backlog, so it really holds the most valuable items. PO is in charge, but he/she relies on both the Development team and stakeholders, which give the insights either from a technical or business perspective.

In a refinement meeting, Scrum teams discuss the stories, values, and effort. In short terms, refinements are important as the team gets the opportunity to prepare the stories for the next iteration.

Definition of Ready is the set of conditions that need to be met in order for one story to be considered ready for development. Definition of Done is a set of conditions that need to be met in order for one story to be considered done. Conditions are valid on the product level, they entirely depend on the agreement among the Scrum team, and are up for adaptations along the process.

Burndown chart displays the Sprint progress, evaluating unfinished work versus time.

Sprint process flow

When I first started talking about Scrum, I explained it as a framework for developing and deploying complex products. This sentence doesn’t tell us much, but the definition also includes Scrum roles, ceremonies, artifacts and the rules explained. Now, let’s check how it’s all connected together in the Scrum process flow.

The Scrum process is organized by iterations, Sprints. Sprint is a time-box period, with a duration of 1 to 4 weeks.

The PO manages the Product backlog to make sure it contains valuable items prioritized by value, and that the stories on top are ready for development by Definition of Ready.

The Sprint starts with Sprint planning, where the PO explains to the Development team what needs to be done and why. The development team then selects the number of stories into the Sprint backlog and commits to finishing it by the end of the iteration. The Development team decides how the stories will be done.

During the Sprint, the team meets on a daily basis to synchronize the work. Sprint progress is tracked by the Burndown chart. At the end of the Sprint, on the Review meeting, the Development team demonstrates stakeholders what was done during the Sprint, according to Definition of Done. Stakeholders give feedback. Corresponding work gets delivered in the form of the product increment.

The last meeting in the Sprint is Retrospective, in which a team reflects on the process, in order to find space for improvement, and become better.

Everything together is an overview by the Scrum Master, which ensures that the whole process goes smoothly.

Simple to understand, hard to master

It’s the Scrum that is known as lightweight in theory but complicated in practice, but I would say it can be translated to any of the methods or methodologies.
It’s easy to learn what stands behind each term, but even when you optimistically jump into the process, a lot of things can go wrong. I would say the most common reason for that is sloppy teamwork.

Let’s be honest, without respect or support among team members and a hardworking community, agile stands no chance. When we, at COBE, figured this out, the sky became the limit.
And from that point on any process works like a charm. :)