A common debate Agile teams have is selecting the right development approach.

So, what exactly is the best Agile development approach? What even is an Agile methodology? We touch on all of that in this article.

What is Agile methodology?

The Agile Methodology is a type of project management process, commonly used in web development projects. This helps manage demands, solutions, and collaborative efforts between cross-functional teams. This can be managed whilst using different frameworks and methods. That is what I’m going to focus on in this article.

When a brand new Agile project is on the horizon – the Kanban vs. Scrum discussion will probably pose quite the challenge. Objectively speaking, your teams can benefit greatly from using either framework to manage the product development or service process. But sometimes, one method is better than the other.

In an effort to help teams decide which is best suited for their project, several questions come into play.

• Is the work plannable? (Software development)
• Is the work repetitive? (Service desk/IT help desk)
• Is the work ad-hoc? (Support teams)
• Is the work innovative? (R&D teams)

With these factors in mind, we can use the characteristics of an upcoming project to determine which framework would typically be most effective for the work.

Let’s get started.

What is Scrum Methodology

Scrum is the process framework that disrupted waterfall.

Conceptualized from Scrummage in the game of rugby, Scrum is now the most popular Agile project management method because it:

1. Is used for addressing complex problems while delivering product increments of the highest value
2. Through its design, it is time-boxed (usually from 2-4 weeks) to release a product increment on a regular, and consistent, basis

The biggest difference that teams will immediately notice with Scrum is that it requires a lot more planning. You need to plan the sprint, estimate the items (user stories, tasks, etc.), and you need to choose (along with the Product Owner) the items most important to complete within that time cadence.

Every Scrum team has a max capacity per sprint. This means that user stories (that business stakeholders view as a high priority) will be left out of sprints on a regular basis which falls outside of your capacity. This often leads to over-commitment by the team, therefore requires certain roles, like a Scrum master, to keep the team honest.

The other main difference – Scrum requires ceremonies (meetings) such as sprint planning, daily scrums, sprint reviews, backlog refinements, and retrospectives.

What is Kanban Methodology?

The ultimate just-in-time methodology.

Kanban is commonly used by teams looking for a flow-based practice, the ability to regularly reprioritize work daily, and pivot with no adjustment timeframe.

The biggest difference you’ll notice early on with Kanban is the board is a visualization of the workflow. This is designed to prompt the right conversations at the right time by reviewing the board daily in a stand-up meeting. Also, you’re not restricted to working within a timeframe cadence (a sprint).

The main objective of using this strategy is to complete a continuous flow of work that is deemed as the highest priority at that given time.

Meetings are not required, but almost always necessary – including daily (same as Scrum), planning meetings (refinements or delivery planning), different types of reviews (operations, risk, strategy), and retrospectives to drive continuous improvement. As work is a continuous flow, work does not need to be estimated.

Even though it appears simpler at face value, that doesn’t mean there aren’t complex team challenges. Kanban teams must pay close attention to metrics such as work in progress (WIP) to reduce active work at any given time in an effort to reduce risk.

From experience, Kanban teams are much more likely to create bad habits and inefficient processes. They do not have the timeframe cadence and there are a lot fewer required ceremonies that drive continuous improvement. As a result, it requires more team discipline. This can be mitigated, however, with the recommended roles in place.

How are Scrum and Kanban Similar?

As much as Scrum and Kanban are different, they share a lot of similarities. They’re both empirical, lean, agile, centered around organized teams, and can thrive on empowering the team to seek process improvements.   

What Are the Different Roles of Scrum and Kanban?

For Kanban – no roles are ultimately required.

With that being said, there are a few roles that are traditionally used, or recommended, for a high-performing Kanban team. These include:

• Service Delivery Manager – this role is intended to facilitate change and continuous improvement on the team, similar to a Scrum Master in nature
• Service Request Manager – this role is intended to facilitate the prioritization of the queue, identify/reduce risks, and own policies, similar to a Product Owner in nature

In my experience, you do need these roles for any complex Kanban project. If the workload is very small and work is rudimentary, you may not find these necessary.

For Scrum – the roles are required to form a Scrum team.

Effective roles are crucial for Scrum to succeed. These clearly defined roles are:

• Scrum Master – enforces scrum principles, master facilitator, and protector of the team
• Product Owner – advocate for the customer, manages the product backlog, and priority
• Development team – developers, testers, and content editors who execute the work

Each role is crucial to the success of a Scrum team and serves a specific purpose. From enforcing Scrum principles to driving continuous improvement, you cannot expect to have an effective team if you don’t have full buy-in on these roles.

The Best Tools for Agile Methodology

Jira Software – the benchmark.  

Jira is the best-known and most popular tool for tracking issues and projects in Agile environments. This software has tons of functionality for the issue and bug tracking and overall project management.

It also has additional tools in the suite including a documentation center, service desk, and tools for continuous integration, deployment, and release management. These additional tools make it a powerful choice in terms of overall scalability in large organizations.

For Kanban, Jira has the ability to completely customize your visualized board through story cards, swim lanes, and columns with customizable workflows. Jira also has built-in automation, allowing you to automate responses on stories, change workflow statuses, and automate nearly any manual task that you can think of.

For help desk, Kanban teams (work is submitted by internal or external customers via an online portal), Jira Service Desk is another tool in the Atlassian suite. This powerful tool can redirect tasks submitted to multiple Kanban boards, making it an efficient solution for organizations looking to combine multiple Kanban teams into one online portal.

By tagging the items submitted with a team component, items will be redirected to the appropriate board quickly. 

Better access to tools can make a real difference. Another provided benefit if your organization does use Jira Service Desk is the integration with Slack. By integrating your SD with Slack, you can set up channels for notifications, respond to tickets and automate manual work. It steps up your team’s ability to communicate, increases speed, and simplifies the process.

Honorable mentions: KanbanFlow, Trello, Kanbanize, HeySpace, and Smartsheet

For Scrum, Jira has almost everything you’d want. Version management, backlog refinement/planning tools, estimation fields, and a fully customizable backlog and permission scheme. The only other tool you may require that Jira doesn’t have is an estimation tool such as Planning Poker.

Along with core functionality, there is a wide range of Scrum reports available. From burndown charts, velocity charts, sprint reports, epic reports, flow diagrams, and control charts. You won’t need any external tools to track and report on the work the team is completing.

Honorable mentions: Wrike, nTask, Targetprocess

One underrated feature of the Atlassian suite is the ability to export all issue data.

By exporting all issues (stories/tasks/etc.) to CSV, you can create customized BI reporting using Microsoft Power BI or Tableau to discover deeper insights into your team and how they work.

This may not be necessary for lightweight projects, but for long-term projects in large organizations, this is a useful feature. For more information on how this feature works, or how it can be used, check out a previous post where I cover the process in detail.

The most commonly discussed benefit when using Jira, apart from the customizability, is the scalability. It seamlessly hosts projects with teams as large as 17,000 across large companies.

A few complaints about Jira Software, however, are the amount of effort it takes to learn, configure, and understand the software … as well as the cost. This makes it an ideal option for large-scale, long-term projects, and less-than-ideal for short-term, smaller projects.

How to Build Workflows in Agile

With Kanban, the board is all about visualizing your work. This should provide the team the ability to identify, adapt, and progress items on a regular basis.

The Kanban board (visualization) should include the following:

• Defined workflow statuses at which the team considers things completed
• Individual values or definitions of what type of task each item is
• Policies or rules of how to get work to flow through each state, which could include a definition of ready and definition of done
• Policies for limiting work in progress (WIP)

With Scrum, your workflow can be customized to fit your needs but is focused on the commitment to ship working software in intervals. Common Scrum workflow stages look something like this:

• To do
• In progress
• In testing
• In Deployment
• Done

In the past, the Scrum teams I’ve worked in have customized the workflow by:

1. Adding statuses before “to do” (to indicate that it needs refinement)
2. Removed “in deployment”, since this is done at the end of the sprint, once all items are marked as done

Some Scrum teams do QA testing within the sprint and others always test one sprint behind the development. As a result, some teams release work live one sprint behind the development. This is due to the overhead of releasing code to the QA environment and the lack of time to complete all stories within a sprint. It is possible and ideal to test within the sprint exclusively, however, some strategies to help circumvent this common issue are:

• Add capacity for QA testing
• Automated testing
• Test early and often
• Pair developers with testers to get answers quickly

Start with a simple workflow, and adapt as your team sees fit.

How to Plan Processes for Kanban and Scrum

For Kanban, planning is relatively straightforward as there are no sprints. This also means that tasks are never sized. You have one backlog that team members pull from in priority order. As long as someone is designated to prioritize the queue, you will always have very little guesswork in determining the items to work on next.

It isn’t required, but it is helpful to have backlog refinement sessions on Kanban teams.

Did you know that if you don’t regularly meet to organize the backlog and flesh out details, tasks tend to get “stuck” at the top of the queue? In fact, items with impediments, lack of detail, or lack of direction will come to a screeching halt.

For Scrum, planning is structured into the framework.

Backlog refinements must be held (at least once a week) to flesh out details so the team can grasp a shared understanding of upcoming sprint items. This is also necessary so the team can properly estimate the work. By asking questions often and early on, it gives the Product Owner a chance to arrive at answers they were not prepared to immediately discuss.

When you have a shared understanding, you can then estimate the backlog items, starting at top of the backlog. As previously mentioned, Planning Poker is how I’ve regularly estimated items in the past. Remember you are relatively sizing, do not get too hung up on estimates. If one person voted 3 and one person voted 5, take the majority of the higher figure. Relative sizing is done with story points, not hours. If you decide to use story points, do not map them to hours. Story points are an overall assessment of time, complexity, and risk.

Sprints can then be designed in sprint planning by choosing user stories up to the expected team capacity – an average of story points completed – for the next sprint. This becomes your sprint plan. Remember to account for vacation and out-of-office days during your capacity calculations.

How to Analyze Agile Metrics and Measurements

Productivity and bottlenecks are measured very differently in Kanban than in Scrum.

Since Kanban is a continuous flow of work, key metrics include:

• Lead time
• Cycle time
• Work in progress (WIP)

Lead and cycle time are important metrics for Kanban teams. These will show insights into the amount of time that it takes for a task to move from start to finish. Finding ways to improve cycle time will effectively indicate the success of a Kanban team.

Work-in-progress (WIP) is the other key metric that must be monitored in Kanban teams. WIP limits are regularly put on Kanban teams to reduce the amount of work that can be in progress at the same time and is necessary to achieve flow.  

Service level agreements (SLAs) or service level expectations (SLEs) are also commonly used on projects associated with Kanban workflow. These are the levels of acceptable lead/cycle time it takes (or is expected from a customer) for a task to be completed.

If you use Jira, I would invest some time in creating a custom business intelligence report, using a tool like Power BI.

The reporting tools built into Jira are a good start, but BI visualizations and reporting can be valuable to the team to identify acceptable SLAs and then inspect/adapt based on historical data. Power BI is a cloud-based tool that can be published online and easily shared to provide full transparency.

With Scrum, in a way, it’s a lot easier to measure how the success of the team from a sprint-to-sprint basis, as you always have direct comparisons from sprint to sprint. The most common metric tracked in Scrum is team velocity. This is the number of story points completed in one sprint.

Key metrics of Scrum include:

• Velocity
• Burndown chart
• Defect report
• % automated test coverage

As velocity is calculated per sprint, you begin to have an increasingly more accurate predictor of future sprints as the sample size increases.

The most useful chart to measure sprint progress is a burndown chart.  

Burndown charts are simply story points/time remaining. As user stories are marked as done, it burns down. If story points are added to the sprint, it will burn up. Ideally, your sprint will be burned to completion before the last day available on the sprint.

What are the differences between Scrum and Kanban?

Agile tried-and-true. 

Neither framework is better than the other. It is truly a case-by-case basis to determine which framework will best fit your project. Both are champions of continuous improvement and agile principles.

At Content Bloom, we work on web projects in both Scrum and Kanban, determining which is the right fit on a case-by-case basis. By choosing the right tool, we have improved performance on web projects with some of the largest organizations in the world. 

From my experience, I tend to believe that Scrum is more effective for driving product development and software projects, as teams are continuously setting sprint goals and delivering value in a specified timeframe. While Kanban seems to be more effective and efficient for help desk/service desk type projects, where the stream of work is consistent and needs to be delivered quickly.  

It’s up to you to decide which framework works best for your team. Experiment, seek improvement, and always adapt.  

If you’re in need of professional insights when it comes to selecting the right framework for your business, we can help.