Intro to Agile Methodology: Scrum & Kanban Frameworks

If only creating the digital software were that simple. You just write a piece of code and then make it live.

But, alas, things are much more complicated. Because, after all, you strive to build a successful quality app that would meet the needs of end-users within a set timeframe and budget. And this requires proper management of the whole app development lifecycle.

So, today we will break down Agile methodology and its most popular frameworks – Scrum and Kanban.

Agile Methodology Overview

Agile is a flexible and responsive way of managing projects. It defines a set of principles and values that allow handling the project with changing requirements.

When using Agile methodology, developers build an app in small increments instead of delivering the ready product all at once. As a result, the team can run tests more frequently, reducing bugs or other errors. Besides, this gives the end-users, stakeholders, and other participants a quick understanding of whether the software meets their expectations.

Moreover, Agile enables teams to stay flexible and responsive to change, which is especially important as the requirements might evolve during the development stage.

Agile vs Waterfall: How One Methodology Inspired Another

Waterfall

At the outset, most app development projects relied on the sequential framework known as Waterfall.

Waterfall is linear in nature, and it involves moving to a new stage of the product development only after finishing and verifying the current stage. In other words, the product development process is arranged step-by-step. This approach has the following advantages:

• It’s easy to understand and arrange;
• Phases are carried out sequentially – one at a time, so they are easy to maintain;
• Entry and exit criteria are well defined;
• Results are well documented.

Looks like a perfect methodology to develop tech products, don’t you think? But there is a significant disadvantage that makes the well-planned Waterfall model not that attractive.

You might have the most sophisticated and well-defined plan to manage your IT project. But the reality hits hard when you start implementing every step of the strategy. For example, you might discuss the requirements later than you’ve planned. The client might also change their mind and ask you to consider additional aspects that haven’t been agreed upon before. Sometimes, which is especially true for highly-competitive markets, the planned features are no longer relevant by the release day, and the client might want to make serious adjustments.

‘What’s the big deal?’ you may ask. If you’ve never worked on a project using the Waterfall method, you will never understand the pain of being rolled back to the very beginning when almost everything has been delivered. Because, let us remind you once again, you can’t proceed with other stages of the project if the previous one is not ready. If the client keeps on adding extra requirements, again and again, you may find yourself trapped in a vicious circle with a ‘no release’ date.

Besides, planning the project and collecting requirements might take ages. The first stages might eat a lot of precious time, up to several months. As a result, some features or approved requirements might lose their relevance over time, hurling you back to the starting point.

The need for accurate and detailed requirements awakens another issue – overly complicated documentation. You usually get a pile of files with rules and constraints that are hard to grasp. Problems appear on the client’s side as well. The massive amount of information lulls their attention, so they might miss the requirements that are critical for them.

So, is Waterfall dead? Neah, it is still used in many projects. Especially in aviation and space industries where the requirements are cast in stone and do not change. The primary condition for the successful Waterfall implementation is well-organized and detailed documentation. Any changes to the code are not welcomed and, if any, must be recorded in the additional agreement. In other cases, you risk breaking deadlines or getting out of the budget.

Agile

Agile is not a new concept. It was pioneered outside the IT industry. We can trace the Agile methodology back to the 1930s when Walter Shewhart of Bell Labs started applying the Plan-Do-Study-Act (PDSA) cycles to improve the products and processes. Shewhart shared this method with his mentee, W. Edwards Deming, who extensively used it in Japan during the years of WWII. Toyota then hired Deming to train the managers to adopt incremental development methods.

In the 1990s, when software had become an integral part of every business, companies started looking for more effective programming methods that would enable adaptability, speed, and quality.

In the early 2000s, a team of developers met in Snowbird, Utah, to discuss the new methodologies. In 2001, 17 developers drafted the Agile Manifesto, formally launching this project methodology. Later, it was updated to Manifesto 2.0, containing four major principles:

• Team over individuals and interactions (over process and tools);
• Business value over working software (over comprehensive documentation);
• Partnership over customer collaboration (over contract negotiation);
• Be ready for the change over responding to change (over following a plan).

These principles offered an efficient and flexible way to execute projects. The advantageous characteristics of the Agile approach gained popularity and surpassed the IT sector. These days the Agile methodology is used in many business areas.

So, Agile emerged as a response to the desire to find a more flexible development methodology. Thanks to this method, teams can proceed with the development process even with limited requirements or when the client doesn’t have a complete vision of the product.

The concept of Agile involves breaking down the development process into iterations. A sprint is a period of time allocated to the team for finishing a certain amount of work. It defines the goals of the sprint, velocity, and the required resources.

Agile sprints solve the critical Waterfall issue (long delivery time). They enable to release the product much faster, even when requirements are unclear.

What’s more.

The Agile methodology enables developers to release the app and generate feedback from the end-users. The feedback is a powerful source of information and would give valuable hints on how to polish the code to ensure better app performance. It also allows checking what users would want to fix or see in the app. After all, the cost of the fixes or changes would be significantly lower compared to Waterfall.

Agile has dramatically boosted the success rate and reduced the number of failed projects. See the image below to learn how the situation has changed.

These figures are partially explained by the fact that Agile is a flexible methodology and allows you to adjust the instruments based on your or your client’s values. Considering the principles of Agile that put the business value at the core, it means that every action is directed towards pushing the client’s business forward with cutting-edge technology.

Agile’s Dream Team: What Talents You Will Need to Succeed

Successful implementation of tech projects involves a well-coordinated work of a team.

While carrying out the project according to the Waterfall method, there are team leads and PMs who serve as mediators between the client and the team.

The situation is slightly different in Agile. The main principle reads that the teams are self-organized and self-manageable. It means that there is a lot of communication and coordination within the team without centralized power.

The difference between Waterfall and Agile lies in role distribution as well. While every team member has a specific set of responsibilities in Waterfall, this might not be the case for Agile. The roles might be shared, and one team member can perform different tasks. However, the common Agile team looks like this:

• A product owner is a representative from the client’s side who defines the requirements, communicates with other stakeholders, and sets priorities.
• A Scrum master is responsible for arranging the Agile project, managing all team meetings, and coordinating the implementation process.
• A development team is meant to deliver the ready product, yet may have shared responsibilities like communication with the product owner and other stakeholders.

The image above is definitely a joke, and it shows how you should NEVER organize the processes within the team. Your goal is to distribute the workflows between team members according to their capabilities and skills. Agile welcomes initiatives to help or support other developers who might be struggling with this or that task. Of course, if you have enough resources for that and it doesn’t hinder your responsibilities.

Agile and Iterative Development

Agile projects are iterative in their nature, so they support immediate progression and project implementation.

The whole idea of the Agile methodology in terms of iterative development runs in a rapid start even in conditions of unclear requirements. You should not focus on ‘make it right’ much since Agile allows revisiting the code and polishing it later. You should strive to bring the working feature to the users as soon as possible.

If you are working on a big feature, you can split it into several sprints or even several release versions. Start with the simplest version of the feature, then add some functionality, step by step.

Remember: small steps are more efficient than a never-ending flow of work on overly complicated functionality (which might turn out to be useless for the users, by the way).

An interesting fact.
Many successful startups became popular due to the Agile methodology. And a big idea, of course. They didn’t wait till the ‘perfect’ moment when a flawless app was ready for use. They started with a simple app, made it accessible for the users, and gradually upgraded it with features based on the user demand.

Scrum as an Agile Framework

Scrum is one of the widely used Agile frameworks for developing, delivering, and maintaining digital products in a complex environment.

Initially, Scrum was used in rugby, which stood for the playing method of restarting the game when the team groups together and attempts to gain possession of the ball. So, this framework emphasizes the importance of teamwork and promotes the idea that no man is an island. If one team member struggles with the task, others will do their best to solve the problem as soon as possible.

Scrum Process in More Detail

As a development methodology, Scrum is based on the principles of iterative and incremental development. It’s a fast, adaptable, and effective Agile framework that allows delivering value to the client and users in a short time.

So, the development process is broken down into sprints. Every sprint involves the development of a certain part of the product and preparing it for release within the defined time frame called a sprint.

Note!
You can’t define the duration of the sprint haphazardly. If you set the pace of 2 weeks per sprint, it should be applied to all sprints within the project. You can’t spend 2 weeks on one sprint and 4 weeks on the next sprint.

As it was described earlier, there are several roles within the Scrum framework:

• A product owner;
• A Scrum master;
• A dev team.

Along with delivering the vision of the product, a product owner is also responsible for providing a product backlog. This is a to-do list of features that are yet to be implemented by the dev team. The product owner streamlines information obtained from different stakeholders or other company representatives and sets priorities for the team. The product backlog should be shared with the dev team as they might suggest improvements to obtain the max value. The team is also free to add suggestions to the product backlog. If the team members are convinced that a new feature will add value to the product, they should present this idea to the product owner. But only the product owner can set the priorities for backlog items.

The dev team defines a sprint backlog – a scope of work for the upcoming sprint. The goal of the sprint is to have features within the scope ready for shipment to production. The sprint results should be measurable.

In some cases, it is physically impossible to release a feature within one sprint (for example, an app integration), and it makes no sense to deploy it in chunks.

Sprint Planning

Sprint planning is the Scrum event that kicks off the sprint. It involves the meeting where the team lays out goals, the volume of work for the particular sprint, and how the goals could be fulfilled.

All team members and a product owner should join the meeting. Sprint planning is an important strategic event that would set the team to work. If you miss it, you risk losing track of what will happen during the upcoming sprint.

There are three stages in sprint planning:

• Input
• Sprint planning
• Output

Input

A product owner should take part in the meeting to bring input. If they are not available, you’ve got to obtain the information about priorities and other prerequisites for successful sprint implementation. A product owner also looks through the product backlog to verify the priorities. We also check the product’s status and constraints (if any).

You should pay attention to capacity and velocity during the input stage.

• Capacity involves the availability of resources which helps define the volume of work within the sprint.
• Velocity is the number of story points the team delivered during the previous sprints, which allows estimating the volume of work the team can take upon during the sprint.

Sprint planning

During the sprint planning meeting, the team is supposed to discuss two critical questions:

• WHAT to deliver – the product owner defines the spec of work;
• HOW to deliver – the team decides on the best ways of delivering the set tasks.

Output

By the end of sprint planning, you will get a well-defined sprint goal and the sprint backlog.

A sprint backlog is a set of items assigned to the team from the product backlog for the upcoming sprint. These items are usually represented in the form of user stories. A sprint backlog is not subject to any change within the sprint. Of course, there might be exceptions, but do not abuse the right for a change.

Grooming (Refinement)

Grooming, more commonly known as refinement, is a meeting between the Scrum team and the product owner. Usually, it is carried out on demand to go over the product backlog like features, tasks, user stories, bugs, and more.

This meeting is critical in product management. During this meeting, the product owner announces new items, sets priorities, and discusses technical project details. In other words, the event enables the team to keep the backlog up to date and get backlog items ready for the upcoming sprint.

Grooming is a pre-planning event before the sprint planning meeting. The point of grooming is to discuss further goals, assess whether their implementation is possible, and estimate what it will take to fulfill them. If the dev team believes that implementing a feature will take longer or will bring no value to the user, you can debate it with the product owner during the grooming meeting.

Planning Poker

Planning poker is an estimation technique used for estimating the development effort during the grooming session. The Agile team estimates the time and effort needed to complete each initiative on their product backlog using this technique.

Poker Planning works great for teams with at least 6-7 members. Especially, when two or more, let’s say, front-end or back-end developers are engaged in the project, and they have different perspectives on the estimation of delivery of this or that feature.

The name of this gamified technique comes from the famous game because its participants use cards. Every participant gets a deck of cards with values from 0 to any relevant figure. The figures stand for the number of story points required for every backlog story or task.

The participants discuss the feature. Then, they should select the card that represents their estimation of the number of story points required to implement it. All cards are then revealed at the same time.

If the estimators agree on the same value, that becomes the final estimate. If not, they discuss their suggested estimates. The participants should reselect the estimate card and reveal it simultaneously when the discussion is over. This process can take as long as needed for the team to achieve consensus.

This great gamified technique helps estimate development time frames more accurately and plan the team’s work more strategically.

Important!
If you are going to run the planning poker meeting ahead of sprint planning, you should revise the estimates during the sprint planning meeting. This allows considering additional requirements or new solutions that might have been revealed later.

Daily Standup

Daily standup is a 15-min-long daily meeting taking place at a fixed time.

The goal of this meeting is to learn the current progress of every team member, discuss and address short-term blockers or challenges, and align participants around the sprint goals.

The daily standup agenda should include a sort of a report from every team member:

• What has been done yesterday;
• What they will be doing today;
• Any blockers that stop them from working on the task.

But the daily standup should not be turned into a 1-hour long status meeting. It should be a quick update on the progress of assigned tasks without many details.

Sprint Review (Demo)

Sprint review is a meeting where the team, product owner, or stakeholders come together to showcase that the sprint’s goals have been met.

Sprint reviews are implemented by many teams, while in some cases, product owners or stakeholders might neglect the need for additional events due to the lack of time.

These demo meetings are important as the product owner can verify whether their expectations about the feature are relevant to what they get in the result. In this way, they can give feedback, so the Scrum team understands what they are doing right and what should be fixed.

Usually, the QA engineers hold the presentation as they have a more complex vision. But, in fact, any team member can speak up and showcase the sprint results.

What results should you demonstrate during the sprint review meeting? You should showcase only ‘done’ features. In other words, these are the features that are ready for production. Do not demonstrate a user story when you are halfway through its implementation.

Sprint Retrospective

Sprint retrospective is a meeting of the development team at the end of the sprint where members reflect on what went well during the sprint, where they failed, and what they can improve for the upcoming sprint.

Actually, it’s a sort of a booster for continuous, iterative improvement that stands at the core of the Scrum framework. Sprint retrospective meetings give the green light to the team to reflect on how things have been done and figure out new ways for improvement.

Unlike sprint reviews that focus on demonstrating and analyzing the results of the ongoing or completed sprint, retrospective events put the efficacy of the Scrum framework for the team in the first place.

Anybody can be the facilitator of the meeting. However, all team members should be well-prepared and be open to discussing their experience of wrapping up the sprint.

Important!
There should be no place for criticism. Everyone should feel safe expressing both positive and negative experiences.

By the end of the sprint retrospective meeting, you should work out a comprehensive list of things your team will:

• Start doing;
• Continue doing;
• Stop doing.

There should also be an action item list. These should be measurable action items assigned to a person or a group of people with a well-defined spectrum of responsibilities. The list may include items that could be implemented during the upcoming or several sprints. The next retrospective event should start with an overview of previously written items and updates on their completion.

Retrospective meetings can take place after every sprint or once in two sprints. In case there is a considerable time gap between the start of the sprint and the retrospective meeting, it’s better to make notes to keep all the critical ideas or points in mind.

Kanban

What’s in this image? Any ideas?

That’s the first Kanban board!

As you may have guessed, it was invented in a non-IT industry a long time ago.

It was developed by Taiichi Ohno, an Industrial Engineer in Toyota automotive in Japan in the early 1940s. Initially, Kanban was designed to be a simple system for more efficient management of workflows at every production stage.

These days, Kanban stands for a visual system for managing work. It visualizes the processes and the actual work that passes through the process, spots limit work-in-progress (WIP) and potential bottlenecks. In this way, the team quickly moves work from “Doing” to “Done.”

When to Use Kanban

Kanban is a winning Agile framework for teams that have plenty of incoming requests of different sizes and with various priorities.

It will also benefit projects that require product support instead of active development.

Unlike Scrum, which involves great control over what processes are in scope, Kanban enables the team to go with the flow. So, Kanban boards work great for projects with well-defined requirements that don’t require much discussion.

On the contrary, Kanban can be a winning framework for projects with active product development and frequently changing requirements (for example, the scope changes in the middle of the sprint).

Kanban Board

The work items are represented by cards organized on a Kanban board. These cards flow from one stage to the next one. The common stages include (but are not limited to):

The main Kanban principle reads that one team member can’t have more than two ‘In Progress’ cards. This promotes the speed of the project delivery and eliminates the defocus.

You may incorporate Daily Standup or other Scrum meetings when adopting the Kanban framework, but this is voluntary. In general terms, Kanban is much simpler than Scrum.

So, Scrum or Kanban?

Should you always drink coffee instead of treating yourself to a mug of tea? Should you always choose vanilla ice cream over chocolate? Should you always wear black T-shirts instead of putting on clothes to your liking?

These questions sound insane, agree?

So, when you are asking whether you should manage projects relying on Scrum or Kanban framework only, you lose the point.

Some projects do better with Scrum, others with Kanban. There is even a hybrid framework called Scrumban that combines the best of two worlds to suit the needs of your team.

Regardless of what you choose, you’re well on your way to Agile bliss.

The Final Word

“There is only one way to eat an elephant: a bite at a time.” That’s what Desmond Tutu once wisely said, and this principle has become the core of the Agile methodology.

Agile methodology is a true lifesaver for the development industry. It allows bringing value to business by delivering quality apps in a changing environment in a short period of time.

Scrum is one of the most popular Agile frameworks that allows coping with projects with changing requirements and increasing the quality of the deliverables. Kanban is another Agile framework that visualizes work for smoother workflows and more flexibility.

ORIL relies on Agile methods, both Scrum and Kanban, to accomplish major goals in product development.

What Agile framework should you choose for your projects? It’s up to you. Luckily, now you are equipped with basic information about these frameworks and can make up your mind.