kanban for planet group case study accenture

Members-only Content

• Monthly Member Events
• Event Session Videos
• Experience Reports
• Research Papers
• Share a Community Event
• Submit an Article to the Blog
• Submit a Member Initiative
• Promote a Training Event

Become an Agile Alliance member!

Your membership enables us to offer a wealth of resources, present renowned international events, support global community groups, and so much more! And, while you’re supporting our non-profit mission, you’ll also gain access to a range of valuable member benefits. Learn more

• Join Us Today
• Member Portal
• Membership FAQs
• Terms and Conditions
• Corporate Members

Agile Conferences

• XP 2024 in Bolzano
• Agile Executive Forum
• Agile2024 European Experience
• All Agile Alliance Events
• Past Conferences
• Become an Event Sponsor

Virtual Events

• Member Events Calendar
• Agile MiniCon
• BYOC Lean Coffee
• Agile Tech Talks
• Member Meet & Greet
• Agile Coaching Network
• Full Events Calendar
• Community Events
• Community Events Calendar
• Agile Training Calendar
• Sponsored Meetup Groups
• Submit a Non-profit Event
• Submit a For-profit Training
• Event Funding Request
• Global Events Calendars

• Events Calendar
• BYOC – Lean Coffee
• Member Meet & Greet
• Agile Training
• View All Events
• Submit an Event
• Meetup Groups
• Past Conferences & Events

Agile Essentials is designed to bring you up to speed on the basic concepts and principles of Agile with articles, videos, glossary terms, and more.

Agile Essentials

Download the Agile Manifesto

To download a free PDF copy of the Agile Manifesto and 12 Principles of Agile, simply sign-up for our newsletter. Agile Alliance members can download it for free.

• Agile Essentials Overview
• Agile Manifesto
• 12 Principles Behind the Manifesto
• A Short History of Agile
• Subway Map to Agile Practices
• Agile Glossary
• Introductory Videos

Recent Blog Posts

Systemic impact of product development

Navigating the ethical waters of Agile coaching with Alex Sloley

Agile – 1 conversation, 2 views

View all blog posts

Agile Resources

The new agile resource guide.

Find Agile services and products from our member companies in our new Agile Resource Guide . Many listings in the guide feature exclusive offers just for Agile Alliance members. View the guide 

• Remote Working Guide
• Event Sessions
• Content Library

Sustainability Manifesto

The  Agile Sustainability Initiative has created the Agile Sustainability Manifesto in an effort to grow awareness about sustainability within the Agile community and inspire a more sustainable way of working. Read and sign now

MEMBER INITIATIVES

• Agile Sustainability Initiative
• Principle 12 Initiative
• Agile in Color Initiative
• Agile Coach Camp Worldwide
• Agile Coaching Ethics

View all initiatives

Your Community

Global development.

• LATAM Community
• India Community

Global Affiliates

• Community Groups
• Community Services
• Member Initiatives
• LATAM Community Development
• India Community Development
• Volunteer Signup

OUR POLICIES

Become a sponsor.

Being an Agile Alliance sponsor is a great way to introduce your company to our members to build awareness around your products and services. The Call for Agile2024 Sponsorships is now open, and there are great options and opportunities still available! Learn more >

• About Agile Alliance
• Code of Conduct
• Board of Directors
• Agile Alliance Brazil
• Agile Alliance New Zealand
• Policies, Reports & Bylaws
• Logo and Media Files
• Become a Sponsor

Experience Report

From scrum to kanban – a team’s journey, about this publication.

Due to the changing nature of the work my team was assigned to, we needed to make some changes to our Agile practices. Since other teams in our company had experience with  Kanban , we decided to make the transition from Scrum to Kanban. This report will discuss the factors that went into our decision, how we made the transition, some lessons learned, and suggested best practices.

1.0 INTRODUCTION

In 2014, my team was in the middle of a very aggressive and complex transition. We transitioned from supporting an established product that had been running in production for 7 plus years, to a team that was developing a brand new product.

As my team tried to respond to these changes, we found that our current scrum paradigm had issues. We had been successfully using Scrum for more than 2 years, but now our Scrum practices weren’t working as well.

As the Development Manager on the team, I observed that morale became an issue as we found it harder and harder to execute successfully on our sprint plans. In general, it was a stressful time for the team as we tried to adapt to the demands of a new product, as well as new technology, and a new organizational structure.

In the Summer of 2014, we decided that we should make the transition to Kanban, to see if it would help mitigate some of our issues with sprint planning.

2.0 MARCHEX AND AGILE

My company, Marchex, is a mobile advertising technology company. Since 2011 my team had supported the Free411 product, a free directory assistance service that was driven by a speech recognition engine. This product had already been in production for several years, but Marchex acquired the company in 2011. In 2013 my team finished migrating the Free411 product into a smooth-running, supportable product in a new data center. At this point, Marchex’s highest priority was to invest the engineering resources of my team into an area that had more growth potential, i.e. search. Search advertising is a multi. billion-dollar business, thanks to the Google AdWords platform. Because Marchex already had an extensive Call Analytics product that was processing millions of advertising campaigns per month, it seemed like a natural next step to expand our Call Analytics product to support Call Analytics for Google and Bing search campaigns. Because this was a brand new product, it was essentially “green field” application development. To minimize change for the team, we tried to stay with our basic scrum structure as we transitioned from one product to the next. But as it turns out, this plan wasn’t as smooth as we had hoped.

Marchex is no stranger to Agile. Our VP of Technology is a strong advocate for the Agile philosophy and the entire product organization has adopted Agile in some form or another. True to Agile, each team is empowered to select the methods and practices that work best for them. Therefore, some teams are strictly XP, some teams are using scrum + XP, and some teams look more Scrumban a combination of scrum and kanban. Many of us had kanban training in 2013, so we were already familiar with the concepts.

In 2014, before we transitioned to Kanban, my team looked like a combination of XP + Scrumban. We had adopted some standard XP practices, e.g. TDD, daily standups, pair programming, demos, and regular retrospectives. We also were using our whiteboard to track our sprint progress, through a Kanban-style board, which helped us visualize the work better.

Since Agile was deeply ingrained into the Marchex culture, we had the support to adopt a new Agile paradigm, if necessary. And by the summer of 2014, it looked like a change was going to be necessary.

3.0 MOTIVATION FOR TRANSITION TO KANBAN

3.1 unfamiliar domain and technology.

Our first problem was our story definitions and point accuracy. One of the decisions we made, as we started our new product development, was the decision to use Scala for application development. Previously, the team had been using C++, Ruby, and Java as their primary languages. Unlike better-established languages, Scala uses a functional paradigm that is different than the more familiar object-oriented paradigm. As we started to delve into our new search domain and adopt the new Scala technologies we found it more and more difficult to write stories with sufficient acceptance criteria, and we were getting worse about assigning accurate points. For example, we had a set of stories around creating a new service. One of the stories was defined as creating an API for this new service. The acceptance criteria for this story were vague, i.e. create an API that is usable by a client application to fetch and push data. This story languished in the same status while the team talked to internal clients that would use the API, and then designed a solution, and then implemented it. Looking at our retrospective notes from the summer of 2014, there were many comments about stories with insufficient information, and underestimating how long it would take to do X. We didn’t have a “yesterday’s weather” type of comparison we could use to accurately gauge story size, so we often didn’t complete the stories in our sprint plan.

All of this was creating a morale problem for the team members, as sprint after sprint the stories were not getting done as planned. Seeing the same stories in the same status day after day, or week after week, gave the feeling of being bogged down. Up until now, the team did their best to plan what they thought they could achieve and felt good when all stories were in the “Done” state at the end of the sprint.

The apparent lack of progress also was causing a problem in how we communicated with our Program Manager. Week after week he saw the same stories on our board, and they appeared to be stalled. As he was also new to the technology and domain, he didn’t know what questions to ask to get better clarity on scope and schedule. The team felt they were on a constant journey of discovery, and each new story was a new area to learn about. Thus, from the team’s perspective, they found it difficult to explain the lack of clarity around their estimates. This lack of clarity around deliverables was also causing some concern from upper management.

3.2 Fluctuating Backlog

Another problem was our fluctuating backlog. For teams that transition from waterfall to Agile, a 2-week sprint seems short and immediate. However, we were finding that 2-week sprints were too long in the evolving business needs of new product development. Our Business Development team was discussing our product to potential customers, and returning with feedback about our offering. In response, we had to constantly adjust our backlog priorities. Sometimes it felt like we were changing priorities on a daily basis. During this time we also went through a major product shift i.e. the product we thought we were planning and executing on, turned out to not resonate with our clients as much as some of the data analysis we were providing for them. So, we decided to refine our product offering in response to this feedback. In this environment, a 2-week sprint plan was difficult to maintain.

Even after our product launch in February 2015, the fluid nature of our backlog still hasn’t changed as our customers continue to ask for additional features. As a result, our product roadmap is still in flux. In this environment, sprint planning feels too awkward, and no longer fits our business needs. Between the rigidity of sprint boundaries, a backlog that is in constant flux, and the constant need to release feature enhancements and robustness, a new paradigm is required.

3.3 Need for Change

After several retrospectives where we noted our inability to finish a sprint plan, I started looking around for ideas on how to mitigate these issues. Many members of the team had kanban training the previous year, and we had taken the initial steps of moving our electronic scrum board onto a large whiteboard in our standup space. This made the work more visible.

Also, as part of our transition to a new product team, my team went from being a single development team working mostly on its own, to part of a 3-team development effort. All 3 teams were required to develop and launch our new product. One of our new sister teams was already using Kanban, and they were very happy with the results. They also had a reputation for being consistently productive.

I spoke to one of the developers who had moved from our team to the Kanban team and asked her how she felt about the transition from Scrum to Kanban. She said she liked the Kanban-style better for two reasons: the team just focused on the top 1 or 2 stories from the backlog, and when they were done they moved to the next story. She said she enjoyed the simplicity of just picking the top story from the backlog and just finishing the work. She also mentioned that their process was more manageable because their stories were much smaller in scope. After talking to her, I was convinced that this was the right direction for my team.

From a logistics point of view, we had to be careful in how we transitioned. We were in the middle of new product development, and customers were being identified. We didn’t have the luxury of slowing down our productivity.

3.4 Things That Didn’t Need to Change

As we considered our transition away from the scrum, there were still some practices that we firmly believed were still productive for the team. As is widely known, scrum is a method of structuring a project, while XP practices are mostly how to develop code. Advocates for XP often adopt scrum+XP. Similarly, we decided to continue using some XP practices, while using kanban for structure instead:

• Pairs-Programming – in 2014, the team had recently adopted pairs programming as the normal way to develop software. We found that in adopting the new Scala language and learning about the search paradigm, pairs programming was imperative to maintain productivity on the team. We assigned pairs at our standups each day, though often the same pair would work together until a story was done.
• Test-driven Development – almost all, new development was created using test-driven development, and we felt that this practice was still the best way to develop software.
• Retrospectives – this is a standard Agile practice that should never go away. We find it useful for the same reasons other Agile teams do – it is our way of doing continuous quality improvement.
• Story points – We changed our point definition, but fundamentally we didn’t see the need to change the idea of using points to estimate story size. We would discuss a story, agree on the acceptance criteria, and then assign points by group vote.

4.0 PROCESS OF TRANSITION

My next step was to talk to the Development Manager of the Kanban team to understand his team processes and some best practices. He is also our Jira Administrator, so I also talked to him about what our new  kanban board would look like. Even though his team had a continuous flow of stories, there were three things he still did on a weekly cadence: (1) planning every Monday afternoon, (2) weekly demos, and (3) weekly retrospectives. He also mentioned that smaller stories made it easier to measure flow, and keep a consistent WIP (work in progress) limit. Though this sounds a bit like a 1-week sprint, the important difference is that his team works off a constantly groomed backlog and reprioritizes as needed throughout the week.

I discussed the concept of moving to Kanban with the team and organized a Lean Coffee (leancoffee.org) style meeting to solicit feedback and address concerns from the team. The Lean Coffee style meetings explicitly solicit feedback from everyone by asking participants to submit discussion topics, and then they are prioritized by group vote. The priority of the topics is organized by the vote count.

The biggest issue that came out of the meeting was story size. It was felt that Kanban would work better if all the stories were smaller and more consistently sized. It would also help mitigate the unknown nature of working with the new search and Scala technologies. As a result of that meeting, we decided on the following processes to support our new Kanban model:

• Weekly 1-hour planning meetings on Mondays.
• Weekly 1 hour retrospectives on Fridays.
• If we started getting low on stories mid-week (i.e. before the next Monday’s planning meeting), we would do a mini-planning at the daily standup.
• New points “measuring stick”- 1 point = 1/2 ideal workday for 1 pair of programmers. Previously our scale was 1 point = 1 ideal workday for 1 pair. This reduced scale helped us keep our stories smaller as a 5-point story meant it was supposed to be done in about 2.5 days, rather than 5 days.
• If, during planning, we assigned more than 8 points to a story, we would break it into 2 or more stories.
• Daily standups would focus on discussing story status and moving them across the kanban board, rather than going around the circle and giving status. This meant our standups were shorter and more focused on the immediate tasks on hand. This change seemed like a natural extension of our move to Kanban, as it underscored Kanban’s emphasis on making work and cycle time more visible.
• We assigned pairs during the standups. We didn’t necessarily change the pairs every day, especially if the pair was in the middle of a story, but we discussed each pairing every day. Given our team size, it only took a minute or two.
• We kept the concept of the 16th minute – i.e. if anybody wanted to discuss an issue in more depth, then we would write it down on our whiteboard and park it for the 16th-minute discussion. The 16th-minute items were discussed after we were done discussing story status on the board and assigning pairs.
• WIP would be 1 for each pair of developers on the team, i.e. 6 developers would mean a WIP of 3 for “In Dev”. We also assigned a WIP of 3 on the “In QA” column. We never changed this WIP, so it seems to suit the team well.

We made the transition from scrum to kanban at the sprint boundary, i.e. we finished our current sprint, and at our next planning meeting, we created a new point “measuring stick” and started planning as if we were a kanban team. This meant that we only needed to scope and plan stories for the coming week, as planning was on Monday morning.

Making the change to smaller stories solved one of our existing problems – the underspecified stories. By discussing stories that had a smaller scope, we also naturally tended to tighten up the acceptance criteria. Since our stories were 8 points (4 days) or less, we discussed the goals of the stories in smaller granularity. For example, instead of having a story that was simply creating an API for a new Service, the new stories were broken down into smaller stories like initialize, publish, validate, logging, finalize. In working on our acceptance criteria for each of those smaller stories, since the scope was smaller, our acceptance criteria also become much more modest in scope and granularity. For example, creating acceptance criteria for a story on logging became very specific. In contrast, the type of acceptance criteria that was created for a story on creating an API was much more vague.

It is true that creating smaller stories also meant creating more stories. Creating a good story hierarchy was critical to making sure that the larger features were being implemented adequately. A story hierarchy is often used to organize sub-stories under a broader-scoped story. The broader story is often called an “epic”. Using this mechanism we can create some order around a larger number of smaller scoped stories.

We were able to easily plan about 1 week’s worth of work in under an hour. This was less than our previous 3-hour bi-weekly sprint planning meetings. Somebody used to fondly call it “poke your eyes out day”. In all fairness, however, our old sprint planning meetings also included a retrospective. Now, we had a separate retrospective each Friday. But breaking the planning and retrospective into two meetings felt more palatable than 1 long bi-weekly meeting.

We started our new Kanban life using the same whiteboard we were using for scrum, with no adjustment to our column names. The column names were:

| In Dev | Ready for QA | In QA | Ready for Release | Done |

Then a couple of weeks later, when we acquired a large screen, we moved to use the electronic Jira board during our standups and planning. This made it easier for the team to see the backlog. At this point, we added the use of 4 additional columns. This was a practice we got from the other Kanban team. The 4 additional columns we added to the Left of our existing 5 columns were:

| New | Bucket | Backlog | On Deck |

New = New stories

Bucket = Unordered backlog

Backlog = Prioritized backlog

Start = Stories that the team feels were ready to implement, i.e. good acceptance criteria and points assigned.

The transition was very smooth, and after 9 months the team is still happy with the Kanban paradigm. The planning is more “just in time” (JIT). The stories are shorter and more manageable. Using the rule of having to break down any story that is bigger than 8 points forces us to keep the stories small in scope. For a while, we From Scrum to Kanban – A Team’s Journey: Page 5 had a picture of our new “measuring stick” posted on our Jira board monitor, and we often referred to it during the first few weeks of our transition. After the first few weeks, the picture continued to hang on our Jira board, but we didn’t have to explicitly discuss it. Also, we find that writing acceptance criteria for smaller-scoped stories makes it easier to write more specific acceptance criteria that are less ambiguous. In other words, our story definitions are tighter.

We never did an A/B comparison in terms of productivity before and after the transition, but the team feels more productive, and morale improved as we were able to see progress each day as we moved our stories across the board. In addition, our communication with the Program Manager improved, as he had a better idea of the status and how long it would take to complete a feature.

Even after our product launch in February 2015, our business requirements are still changing on a regular basis, so this JIT-style planning is still a good match for our environment.

5.0 LESSONS LEARNED AND TAKEAWAYS

There were several factors that made our transition fairly smooth.

5.1 Experienced Team Leadership

The person whose role had the biggest changes after our transition from scrum to kanban was the Program Manager (acting as Scrum Master). Throughout the week he had to stay at least one step ahead of the team in grooming the backlog. Given our fluctuating business needs, this was something he had to do on a daily basis. If the “On Deck” column started looking low, he had to make sure that he had the acceptance criteria well enough defined to add more stories to “On Deck” in case the stories in flight were finished before our next Standup. This meant that instead of grooming our backlog on a weekly or bi-weekly basis, as we did during our 2-week Sprint schedule, he had to constantly keep an eye on the backlog. He also had more stories to manage.

Another challenge as a Program Manager is managing the transition itself. As a team, we had agreed to new practices to support the new Kanban paradigm, but he had to help us adhere to the new practices that we adopted. This meant supporting the team as he guided the team to adopt the new practices, meeting definitions, and story writing.

Since I had been practicing Agile for more than 10 years, the Program Manager and I worked together to groom the backlog and coached the team to the new Kanban world. We were also working with a team that was very supportive of our efforts to introduce change. This leads to the next point.

Another factor that made our transition smoother, was the depth of Agile experience the organization already had. Most of the team was comprised of experienced Agile practitioners. The team was already conducting retrospectives where we discuss how well, or not well our current processes are doing, and made incremental process changes as required. To consider a fundamental paradigm shift did not feel as scary for us, as it might have felt for an organization that wasn’t already practicing Agile. We already had the tools to adjust if our first attempt at Kanban didn’t work. Having weekly retrospectives allowed us to explicitly discuss how things were going more frequently than our previous retrospectives that came at the end of each sprint.

5.3 Kanban Training

The year before our transition to Kanban, the entire development organization had gone through a Kanban training that was offered by Modus Cooperandi. This training introduced us to the concepts of lean and kanban, such as work in progress (WIP), cycle time, etc. When our team started discussing the adoption of kanban we already had a common vocabulary. So, for example, when a team member said, what is our WIP for each column, we already knew what a WIP was in theory.

5.4 Keeping a Weekly Cadence

We found that having a weekly cadence helped us structure our new Kanban life. We had weekly retrospectives, so we could make minor adjustments to our process if issues came up. We also found that keeping a weekly planning cadence helped us feel more comfortable with the process. Book-ending the week with planning on Mondays and retrospectives on Fridays, contributed to the feeling of a good regular tempo. So, even though we eliminated sprints, maintaining a weekly schedule seemed to make sense. However, one weekly cadence disappeared. that was our weekly release cadence that we maintained when we had scrum sprints. Instead, we started releasing features as they were completed, which seems more in keeping with Kanban.

5.5 Experienced Kanban Team In Close Proximity

We were very fortunate, that we were sitting next to another team that was successfully using Kanban. For example, they not only gave us the column name for our Jira board, but they also showed us how to handle “blocked” and “expedite” stories by putting the stories in their own swim lanes. We also emulated their weekly cadence and smaller-scoped stories.

We are still happily doing kanban, nine months after our transition. In fact, it is hard to imagine what it would be like to go back to two-week sprints. As I was writing this report I asked one of the developers if he was still happy with the transition and he said, “Oh yes!” In talking to other developers on the team, they like the smaller scoped stories, and the visibility the Kanban board gives them – both in terms of workflow and also the forward-looking visibility of the backlog.

Looking at some retrospective notes from the time we did the transition (late August . early September 2014) there were comments like, “Kanban going well . stories getting smaller and smaller” and, “Just-in-time planning!”

There is something very satisfying about seeing work items move across a Kanban board. I recently created another Kanban board to track the progress of a series of documentation we are creating for our new product. The Tech Writer was thrilled to see her work appear on a board. The simple representation of her work in progress gave her a sense of accomplishment in a way that was different than looking at a directory of files.

Our business needs still change frequently, but the team feels productive and likes steadily releasing new features. All of our meetings feel more efficient and productive, as we maintain the spirit of JIT planning.

When I shared our Kanban experience with our VP of Technology, he suggested that Kanban was an advanced form of Agile, and I agree with him. Though, Agile has many different definitions, keeping a daily focus on the highest priority stories that support business needs, makes us feel like we were embracing Agile at a new level.

7.0 ACKNOWLEDGMENTS

I would like to thank my co-workers at Marchex, who helped make the transition a success: Andrew Garbutt (Sr S/W Developer), Anna Zeitlin (S/W Developer), Bo Li (Program Manager), Craig Ulbrecht (S/W Development Manager), John Paul Wallway (S/W Developer), Jos Van Schagen (Principal S/W Developer), Kent Henneuse (Sr S/W Developer), and Madeline Heffernan (S/W Intern). I also want to thank Rebecca Wirfs-Brock for all the work she did to shepherd this report, from a session at Agile Open Northwest 2015 to this Practitioners’ Report.

• Download the Experience Report
• Aki Namioka
• Report Source
• Download Report

You must be an Agile Alliance member to download the report. Please log in to your account now, or join us to take advantage of all our members-only events and resources.

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related agile experience reports, what safe doesn’t tell you, less without scrum, transforming into an agile scrum framework, ultimate kanban: scaling agile without frameworks at ultimate software, discover the many benefits of membership.

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Thank you to our valued Agile Alliance Annual Partners

Our new Annual Partner Program offers a new and exciting level of engagement beyond event sponsorship.

Our Cornerstone Corporate Supporting Members

Our Corporate Supporting Members are vital to the mission of Agile Alliance.  Click here to view all corporate members.

©2024 Agile Alliance  |  All Rights Reserved  |  Privacy Policy

©2024 Agile Alliance All Rights Reserved  |  Privacy Policy

• Welcome back!

Not yet a member? Sign up now

• Renew Membership
• Agile Alliance Events
• Agile en Español
• Agile en Chile
• Resources Overview
• Agile Books
• Content Library by Category
• Content Standards
• Privacy Policy
• Cookie Policy

Privacy Overview

• ' styled with css -->

6 Genuine Kanban Examples: The Journey Toward Flow and Agility

Blog / Kanban

Iva Krasteva

Content Creator Expert | Agile Practitioner | Kanban Certified

5 mins read

Published on: June 16, 2023

Last updated: April 18, 2024

Table of Contents:

The Kanban method is a work management approach focusing on visualizing work, limiting work in progress, and improving efficiency. Originating from the Toyota Production System in the 1940s and the manufacturing field, various industries later embraced the approach, including software development.

Its key component is the kanban board to visualize the workflow. Kanban principles and practices of visualizing the work and setting work-in-progress limits are at the heart of the method. All its building blocks emphasize continuously improving the process by enabling teams to work more effectively, collaborate better, and constantly hone their productivity.

6 Kanban Examples Straight Out of the Industry

But don't take our word for the method's benefits. Let's explore some examples of real-world Kanban implementations across various industries.

Kanban Example 1: How Kanban-Enhanced Transparency and Value Focus Improved Operational Efficiency in Logistics

Determined to improve its international purchasing division's agility and operational efficiency, distribution logistics company Encoparts initiated its Agile transformation with the help of the Kanban method .

At the time of the implementation, the most critical challenges that the department was facing included:

• High complexity of the processes involved in international purchasing work management
• Unpredictable work processes and low visibility
• Lack of focus and bad communication

The transformation started by introducing Kanban through the STATIK approach (Systems Thinking Approach to Introducing Kanban). The premise behind the approach is to help teams focus on the entire network of services along with all the interdependencies and connections. Looking at the system from that point of view, Agile teams are empowered to arrive at improvements that would affect global delivery and not just drive local results.

Kanban STATIK implementation steps

Introducing a detailed kanban board visualizing the entire end-to-end work process enabled the very purchasing team members to elevate the constraints of their own work system with unmatched transparency. Using their kanban board to map the complete value delivery process allowed them to identify where value added and non-value added activities were indeed happening in the workflow.

Implementing kanban flow metrics , such as lead and cycle time, provided insights into the purchasing process by enabling team leaders to assess delivery speed, identify blockages, and analyze time spent on purchasing activities.

Consequently, the cycle time and throughput for order fulfillment became consistent, and within the initial two months of measurement, the team achieved an average of 152 work items in 12 days . By uncovering their value-adding and non-value-adding steps, they could also apply improvements, almost doubling their flow efficiency stats from 34% to 67%.

Visualization of reduced flow efficiency within two months of applying Kanban

Source: Encoparts Case Study

Kanban Example 2: Enhancing Flow in Engineering Project Management

Developing an automated intralogistics solution is a complex project with a typical life cycle of 1.5 to 2.5 years, including cross-departmental dependencies, meeting regulatory requirements, and high-quality expectations. To improve the project and portfolio management process, Spanish industry player ULMA Handling Systems set out to implement kanban practices to manage their long-term technological solutions efficiently.

Some of the most common challenges related to the management of ULMA projects and portfolios were related to the following:

• Missing visibility into the work process
• Lack of efficient communication and addressing unforeseen events
• Increased project delivery times

With a commitment to address the pain points, senior management set out to make things much simpler and more comprehensive. The change was initiated by introducing kanban boards and kanban cadences or meetings. The two practices facilitated communication and improved the visibility into the real-time status of work.

Visualizing an end-to-end workflow on a kanban board

To improve their work delivery process further, the pilot projects' team members used the explicit kanban policies practice. They created a smooth and coherent delivery handoff process by defining internal agreements on how work should be done.

The improved understanding of the end-to-end workflow developed a shared knowledge of the workload and the actual team's capacity. Introducing kanban practices also led to improving the way internal dependencies were managed.

Source: ULMA Case Study

Kanban Example 3: Visualizing End-to-End Flow of Work and Boosting Efficiency in the Chemical Industry

With a mission to achieve project agility and drive sustainable results, chemical manufacturer Schlenk started a transformational journey with Kanban. The initiative's main goals were clear - achieve transparency in the innovative project management process and make process bottlenecks visible so they can be addressed.

Some of the challenges that influenced the decision included:

• Inefficient handoffs due to missing links between the different teams and project phases
• Limited transparency into process blockers
• Lack of project performance review

Another milestone was the ability to structure the end-to-end value delivery flow in one place, depicting different organizational levels and how they were linked.

The company started building flight levels on interconnected Kanban boards to scale its flow and improve its overall business agility . The concept of flight levels by Kalus Leopold focuses on managing the flow of work from strategy to execution by visualizing the link between strategic portfolio management, coordination, and daily operations. The interconnected kanban boards made that possible in practice. It allowed them to visualize strategic initiatives and link them to related sub-initiatives and projects down to every single work item contributing to the progress of the project portfolio.

A depiction of the Flight-levels concept to organizational development

Even at the Portfolio level, elevating process blockers using visual signaling allowed the teams and management alike to uncover the process blockers and dependencies. This, in turn, resulted in a better understanding of the relevance of different work, reduced waiting times, and promoted faster issue resolution.

Speaking of tangible results, the flight levels' concept created a perpetual connection between strategy and execution , elevating how every team member contributes to reaching the strategic plan. On the other hand, at the team level, the kanban practice of limiting the number of work items in progress helped one of Schlenk's teams significantly reduce their cycle time from 110 days to 44 days (at the 85% percentile.)

Source: Schlenk Case Study

Kanban Example 4: Increasing Delivery Speed and Managing Engineering Portfolios with Kanban

Fixed processes and compliance regulations give little to no room for changes or flexibility, which is exactly what businesses in industries such as aerospace or pharma face. The aerospace manufacturer Aerosud started their Agile transformation to adopt and spread business agility.

To support this goal, the IT division introduced kanban boards and adopted work-in-progress limits on the individual boards. Along with visualizing impediments and incorporating daily meetings, the practice improved communication and the understanding of the team's capacity. This increased the IT group's throughput from 60 to around 120 tickets within 3 days .

This milestone achieved within the IT area encouraged the expansion of the implementation across the engineering project and portfolio. To do this, team leaders decided to combine kanban practices with the flight levels' concept to establish a natural link between project portfolios, cross-team coordination, and day-to-day operations.

Visualizing the link between top-level projects and project execution on a kanban board

Source: Aerosud Case Study

Kanban Example 5: How Kanban Empowers Digital Transformation

Set out to foster enterprise agility , Brazilian financial solutions provider Boa Vista had two very clear objectives for their digital transformation initiative: accelerating project delivery and becoming more flexible in their response to the changing customer needs.

Creating value-stream-oriented departments and product-oriented teams and reducing the batch size of work items helped reduce the long project delivery cycles lasting from one to six months on the operational level. However, overcoming the missing alignment between team operations and strategic goals was a more pressing challenge.

A depiction of value-stream oriented departments

To help address that challenge, the company adopted the Kanban Maturity Model (KMM) as guidance on scaling agility across the organization. The product team at Boa Vista was also trained in the goal-setting framework OKR . The ability to link team initiatives and company OKRs on the same Kanban board created a better alignment between the different company levels. In addition, introducing kanban cadences further supported a smooth information flow across the organization and strengthened their efforts toward reaching the digital transformation goals.

Source: Boa Vista Case Study

Kanban Example 6: Enhancing Work Coordination & Digitizing Customer Journey with Kanban 

When a company sets out on a mission to combine two business units with different work management approaches, it is no surprise that it faces a formidable challenge along the way. This is the case of the Brazilian telecommunication and IT service company Algar, which took the bold decision of transferring the Integration department to the Business unit.    The Business unit was already dipping its toes into the waters of the Agile mindset and ways of working, while the Integration area was still anchored in traditional work management methods. For this initiative to succeed, the Integration area needed a radical transformation to fit into the new work environment, where digitalization, agility, innovation, and a customer-centric mindset were the cornerstones. 

This is when the digital transformational journey with Kanban for the Integration area started. 

Initially, the department faced various challenges, such as a lack of alignment with the Business unit, no metrics to analyze and track their work, using Excel spreadsheets to monitor tasks, and no central place where the information could live. 

Their transformation started by building kanban boards to visualize the end-to-end delivery processes, spot work blockers, and manage project dependencies across the other teams inside the tribe. They established an even stronger relationship with their customers by sharing their work management boards and showcasing the progress of their work through custom reports.

  Soon after the Integration area embraced some of the Kanban practices, the results were remarkable. With the implementation of new work methods, the teams identified and addressed 12 root causes and swiftly resolved 20% of procedural obstacles, which accelerated the overall project flow. 

Thanks to the delivery metrics they tracked, managers gained more confidence in their decisions. Regular Agile ceremonies fostered a culture of productivity and proactivity, with teams constantly seeking ways to improve the flow of work. Not to mention that the operational agility of the team has significantly increased due to the Lean/ Agile ways of working they adopted. 

Source: Algar Case Study  

Is Kanban the Sustainable Project and Portfolio Management Approach?

With the listed hands-on illustrations, we hope we have demonstrated that flow-based methods like Kanban support Lean portfolio management . Its focus on visualizing and optimizing workflows, reducing waste, and promoting continuous improvement makes it well-suited for sustainable and efficient management of projects.

According to industry data and experience, companies today use Kanban for three reasons: elevating work transparency, increasing delivery speed, and driving continuous improvement. We can generously contribute to this list: Kanban can help standardize work, improve flow management, better team collaboration, align projects and portfolios to strategic goals, scale agility across the organization, and many more.

With a background in Intellectual Property, SEO, content writing, and training in Lean, Agile, and Kanban, Iva is an enthusiastic Agile practitioner who embraces collaboration and flexibility every step of the way. Driven by constant learning and knowledge and fascinated by people's creativity.

In-depth research on how companies can leverage Lean/Agile operating models to their advantage.

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

• SAFe Contributors
• Extended SAFe Guidance
• Community Contributions
• SAFe Beyond IT
• Books on SAFe
• Download SAFe Posters & Graphics
• Presentations & Videos
• FAQs on how to use SAFe content and trademarks
• What’s new in the SAFe 5.1 Big Picture
• Recommended Reading
• Learn about the Community
• Member Login
• SAFe Implementation Roadmap
• Find a Transformation Partner
• Find a Platform Partner
• Customer Stories
• SAFe Training

CASE STUDY: Accenture

Key accenture learnings on scaled and distributed agile delivery.

In the provided case study, Accenture shares its insights on addressing process, organization, and tool challenges, including:

• Solution misalignment between teams
• Integration of Agile with Waterfall
• Different timezones, customs, and cross-team activities
• Different DevOps tools between teams

As many companies struggle to implement Agile at scale in distributed environments, this case study describes Accenture’s experience enabling faster delivery and speed-to-market by implementing Agile programs using SAFe, along with adoption of DevOps principles. The early benefits are compelling:

Early Quantitative Benefits

• 50% improvement in merge and retrofit (based on the actual effort tracked)
• 63% improvement in software configuration management (effort to support SCM activities)
• 59% improvement in quality costs (percentage of defects attributed to SCM and deployment)
• 90% improvement in build and deployment (process and effort to raise deployment requests)

“ Enhanced SAFe processes are key to attaining solution alignment between different scrum teams. ”

“ SAFe is critical to the alignment of delivery timelines.”

Early Qualitative Benefits

• Improved demand management and traceability from portfolio through to Agile delivery teams
• Granular configuration management and traceability
• Integration with Agile life cycle tools to allow story-based, configuration management driven from meta data
• Real-time traceability of status for build and deployment
• Automated build and deployments, including “one-button deployment”
• Developer efficiencies as a consequence of improved tool interaction times and processes

Download Accenture Case Study

Many thanks to Accenture’s Mirco Hering, APAC lead for DevOps and Agile, Andrew Ball, senior manager, and Ajay Nair, APAC Agile lead for Accenture Digital, for taking the time to share their insights and learnings. Their story is an inspiration to all of us in the SAFe community. 

Privacy Overview

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.

• Agile project management
• 4 kanban principles

4 Kanban Principles for Agile Project Management

Browse topics.

Kanban is a visual project management framework that optimizes workflows and increases efficiency through real-time tracking and collaboration. Think of it as Agile’s best friend—always there to track tasks and workflows and gauge the workload.

Four core principles make up the Kanban framework: start with what you know, pursue incremental change, respect the current process, and encourage leadership at all levels. 

In this guide, you'll learn about these four Kanban principles, how they fit into agile software development , how easy they are to implement, and how they improve project management practices.

How is Kanban applied to software development?

The Kanban methodology was originally developed to improve manufacturing efficiency. It has since been adapted for software development to optimize workflows and reduce wasteful behaviors. At its core, Kanban focuses on visualizing tasks, limiting work in progress, and ensuring a smooth flow of tasks from start to finish.

Kanban introduces a visual aid, the Kanban board , to project management efforts. This visual tool helps teams track task progress, acting as a single source of truth.

Agile project management is the go-to approach for DevOps software development teams who crave flexibility and iterative progress. Agile methodology adapts to change and delivers small, incremental improvements, making it easy to handle constant change in the software development process.

Jira offers a ready-to-use Kanban board template that makes it easy for software teams to prioritize, visualize, and manage a continuous delivery of work. 

What are the 4 Kanban principles?

The Kanban methodology comprises four simple principles that form the backbone of the Kanban framework. These four Kanban principles include:

1. Start with what you do know

Kanban starts with the discovery phase, so you don’t invest resources into fixing something that already works. During this phase, project managers pinpoint existing processes and workflows that work well and identify processes, roles, and responsibilities with room for improvement. By focusing on discrete problem areas that need optimization, managers can minimize organizational disruption and quantify ROI more accurately for Kanban improvements.

2. Agree to pursue incremental, evolutionary change

Kanban focuses on small, manageable changes, so think baby steps, not giant leaps. Sweeping changes can overwhelm teams and introduce unforeseen challenges. For instance, suddenly overhauling your company’s entire software deployment process could lead to missed steps, costly errors and downtime, and even team resistance due to the unfamiliarity. 

On the other hand, implementing incremental changes, such as adjusting one phase of the deployment at a time, minimizes risk. Teams have the opportunity to acclimate, leading to more predictable outcomes. By delivering incremental value, senior management will see tangible results quickly, which can improve buy-in to the process.

3. Respect the current process, roles, responsibilities, and titles

Kanban respects the organizational processes, roles, and titles and aims to enhance rather than disrupt the natural order of operations. This synergy makes it easy to weave Kanban into existing workflows. 

By honoring the current structure, Kanban reduces resistance to change and allows for quick implementation because the company does not need to restructure before starting with Kanban.

4. Encourage acts of leadership at all levels in your company

Kanban encourages empowerment: Everyone, from interns to CEOs, takes ownership of their tasks. People tend to be more engaged, accountable, and happier at work when they feel empowered to take ownership of their tasks. Kanban encourages each team member to contribute to the process. For example, a junior developer might identify a bottleneck in the workflow and suggest a solution backed by data.

Are Kanban principles easy to implement?

Introducing Kanban principles should not create disruptive change as they focus on making incremental changes and do not require an overhaul of existing processes. All a team needs to implement Kanban principles is a board and some cards to represent tasks. A virtual board enables remote teams to share information and streamline team communication.  For software teams, Jira offers a robust feature set of project management tools that support any Agile methodology, including Kanban. With Jira’s ready-to-use Kanban template, teams can easily set up their next project and start moving work forward.

Jira also enables business teams, such as marketing, HR, or finance, to take advantage of Kanban principles and oversee and monitor tasks across various projects and operations. In addition to Calendar and Timeline views, Jira offers teams a board view that gives them a clear and easy way to visualize work.

Jira is the shared platform of collaboration across an organization, allowing software developers and their non-technical counterparts to stay connected while using tools curated for their own use cases. Connect projects, documents, and tasks to streamline collaboration and communication, break down silos, and prevent project delays. 

What are the core Kanban practices?

While Kanban’s four principles highlight the reasons behind its efficacy in enhancing Agile-based software development, its six core practices offer a clear roadmap for implementation. This section unpacks these practices to provide you with a deeper understanding.

1. Visualize workflows

You’ve got to see it to manage it

To manage workflows, you need to be able to visualize them. Kanban boards include columns that represent stages in your workflow, such as “To do,” “In progress,” and “Done.” Each card represents an individual task or user story and includes details such as deadlines, responsible team members, and more. Jira’s ready-to-use Kanban template comes with a pre-configured Kanban board so teams can set up their project quickly and start moving work forward. 

Project managers arrange Kanban cards for each project on the project’s Kanban board. They place them in columns representing their current status. A glance at the board offers a wealth of information. The project manager can instantly see what team members are working on, what they have completed, and what is overdue.

2. Limit work-in-progress (WIP)

Bite off only what you can chew

The chaos of multitasking can be a productivity killer, so limiting work-in-progress is crucial. By setting WIP limits for each column on your Kanban board, team members can focus on completing tasks rather than juggling too many. The goal is for everyone to have tasks on the Kanban board that they need to complete but for no one to need to multitask.

3. Manage flow

Let the Kanban board be your guide

The Kanban board is the go-to tool for identifying bottlenecks and roadblocks. For example, if the "Code review" column is consistently full, code reviews are slowing down the process and may need some attention.

It is vital to move cards in real time to accurately reflect work progress and keep the team in the loop.

4. Ensure explicit process policies

Transparency is key

Well-documented processes keep everyone on the same page. Documenting and defining processes involves outlining roles, responsibilities, workflows, and protocols. The master project documentation template is a great place to start your documentation efforts.

5. Deploy feedback loops

Feedback isn’t a nice-to-have—it’s a must-have.

Feedback is the cornerstone of continuous improvement, helping project managers pinpoint what's working and what needs tweaking. This feedback, gathered from team member experiences, interactions with the board, and insights from senior management, serves as the foundation for continuous improvement. It empowers project managers to discern what’s effective and what aspects need adjustments.

6. Improve collaboratively

Improvement is a team sport

Continuous improvement is an ongoing process that involves analyzing performance, spotting opportunities, and making incremental changes. Kanban boards are versatile enough to handle various workflows while ensuring work progress. 

For those looking to dig deeper into performance analysis and root-cause identification, Confluence —a collaboration tool by Atlassian—offers ready-to-use templates for retrospectives and “ five whys ” sessions so you can conduct effective meetings for local and remote teams.

Follow Kanban principles for better project management

Kanban principles and practices go beyond using visual boards and cards to fostering a culture of continuous improvement, efficiency, and teamwork. This holistic approach can significantly elevate your project management approach by refining task execution and augmenting process clarity. 

Jira’s Kanban board view gives agile teams structured frameworks to visualize work, improve efficiency, and enhance collaboration across the organization

Kanban principles: frequently asked questions

What is the difference between a kanban board and a kanban card.

A Kanban card represents an individual task within a workflow. A Kanban board is a visual tool that displays an entire workflow.

Kanban cards include detailed information about each task, including its status, owner, and priority. The Kanban board brings the Kanban cards together to give the team an overall view of a project.

What are the benefits of the Kanban method?

The Kanban method offers a range of advantages that streamline project management and enhance team performance, including:

• Improved workflow: By visualizing tasks on a Kanban board, teams can identify bottlenecks and optimize workflows.
• Increased efficiency: Limiting WIP ensures that team members focus on completing tasks instead of feeling overwhelmed with multitasking. 
• Enhanced collaboration: The visual nature of Kanban boards fosters a collaborative environment, as everyone is aware of their responsibilities and the status of each task.

What is the difference between Scrum and Kanban?

While Scrum and Kanban are both Agile methodologies, Scrum operates in fixed-length sprint cycles, whereas Kanban is a continuous flow method. Scrum teams have predefined roles, such as Scrum Master and Product Owner, and Scrum involves various ceremonies, such as daily stand-ups and sprint planning. Kanban team roles are flexible, and Kanban doesn't require regular meetings, making it adaptable to various projects and team structures. 

However, the principles behind these frameworks are similar, so a Kanban vs. Scrum mindset isn't the way to go. It's best to view these frameworks through the lens of how they can help build better products with fewer headaches.

Kanban - A brief introduction

An introduction to kanban methodology for agile software development and its benefits for your agile team.

4 Kanban Metrics You Should Be Using in 2024

Following Kanban principles is essential for successful implementation. Use this fundamentals guide to maximize Kanban effectiveness.

A Case Study on E-Kanban Implementation: A Framework for Successful Implementation

• First Online: 01 January 2013

Cite this chapter

• Grant MacKerron 3 ,
• Maneesh Kumar 4 &
• Vikas Kumar 5  

4750 Accesses

This paper provides generic guidelines to ensure an electronic supplier Kanban can be successfully implemented across an organization. This approach is based on case study work conducted within a European manufacturing SME. A framework in the form of an eight-step approach for implementing an electronic supplier Kanban, that has been tested, proven, and realized, provides a clear process to follow. These steps provide a clear process from mapping and analyzing the current situation, an analysis of potential suppliers with corresponding criteria, and an analysis of purchased items and bottlenecks in their use within the organization. The stepped approach further reviews the Kanban loop, which needs fully dimensioned, together with relevant information, supplier preparation for using the system, and then the integration of processes to ensure success in its use. Operational issues are comprehensively covered, together with strategic aims and the underlying problems that may impact upon success. The above approach can be used to both introduce new suppliers to the system as well as giving assistance to other companies wishing to implement e-supplier Kanban. This will need to be adapted and contextualized to individual organizational requirements.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Kumar, C. S., & Panneerselvam, R. (2007). Literature review of JIT-KANBAN system. International Journal of Advanced Manufacturing Technology, 32 (3–4), 393–408.

Article   Google Scholar  

Giard, V., & Mendy, G. (2008). Scheduling Coordination in a Supply Chain Using Advance Demand Information. Production Planning and Control, 19 (7), 655–667.

Henderson, B. D. (1986). The Logic of Kanban. The Journal of Business Strategy, 6 (3), 6–12.

Lage Junior, M., & GodinhoFilho, M. (2010). Variations of the Kanban system: Literature review and classification. International Journal of Production Economics, 125 (1), 13–21.

Harrison, A., & van Hoek, R. (2011). Logistics Management and Strategy , (4 th ed). London: Prentice Hall.

Google Scholar  

Christopher, M. (2011) Logistics and Supply Chain Management , (4 th ed). London: Prentice Hall.

Singh, N., Shek, K. H., & Meloche, D. (1990). The Development of a Kanban System: A Case Study. International Journal of Operations and Production Management, 10 (7), 29–36.

Naylor, J. B., Naim, M. M., & Berry, D. (1999). Leagility: Integrating the lean and agile manufacturing paradigms in the total supply chain. International Journal of Production Economics, 62 (1–2), 107–118.

Cagliano, R., Caniato, F., & Spina, G. (2006). The linkage between supply chain integration and manufacturing improvement programmes. International Journal of Operations and Production Management, 26 (3), 282–299.

Mukhopadhyay, S. K., & Shanker, S. (2005). Kanban implementation at a tyre manufacturing plant: a case study. Production Planning & Control, 16 (5), 488–499.

Slack, N., Chambers, S., & Johnston, R. (2010). Operations Management (6th ed.). London: Prentice Hall.

González-R, Pedro L., & Framinan, Jose M. (2009). The pull evolution: from Kanban to customised token-based systems. Production Planning & Control, 20 (3), 276–287.

Monden, Y. (1998). Toyota Production System: an Integrated Approach to Just-In-Time . Georgia: Engineering and Management Press.

Framinan, J.M., Gonza′ lez, P.L., & Ruiz-Usano, R. (2003). The Conwip production control system: Review and research issues. Production Planning & Control , 14 (3), 255–265.

Womack, J., & Jones, T. (1996). Lean Thinking . New York: Simon & Schuster Ltd.

Parry, G. C., & Turner, C. E. (2006). Application of lean visual process management tools. Production Planning & Control, 17 (1), 77–86.

Cimorelli, S. (2005). Kanban for the supply chain: fundamental practices for manufacturing management (1st ed.). US: Productivity Press.

Ramnath, B. V., Elanchezhian, C., & Kesavan, R. (2009). Inventory Optimization Using Kanban System: A case study. The IUP Journal of Business Strategy, 6 (2), 56–69.

Dickmann, P. (2007). SchlankerMaterialfluss (1st ed.). Berlin: Springer.

Waters-Fuller, N. (1995). Just-in-time purchasing and supply: a review of the literature. International Journal of Operations and Production Management, 15 (9), 220–236.

Liker, J. K., & Choi, T. Y. (2004). Building Deep Supplier Relationships. Harvard Business Review, 12 (1), 104–113.

Hadaya, P., & Cassivi, L. (2007). The role of joint collaboration planning actions in a demand-driven supply chain. Industrial Management & Data Systems, 107 (7), 954–978.

Drickhammer, D. (2005). The Kanban E-volution. Material Handling Management, 3 (1), 24–26.

Barkmeyer, E. J. (2007). An Ontology for the e-kanban Business Process. National Institute of Standards and Technology , Internal Report 7404.

Martel, M. (1993). The role of just-in-time purchasing in Dynapert’s transition to world class manufacturing. Production and Inventory Management Journal, 34 (2), 71–76.

MathSciNet   Google Scholar  

Wildemann, H. (2003). Internet-KANBAN in der Automobilindustrie. Consulting News TCW Management, TCW Transfer- Centrum- Verlag GmbH, München.

Yin, R. K. (2009). Case study research: design and methods (4th ed.). Los Angeles: Sage.

Rother, M. (2010). Toyota Kata . US: McGraw Hill Professional.

Leyendecker, B. (2008). Das Zusammen spielver schiedener Optimierungsmethoden in der Wertschöpfungskette. In: Töpfer, A. Lean Six Sigma—WirkungsvolleKombination von Lean Management, Six Sigma und Design for Six Sigma . Berlin: Springer.

Wee, H. M., & Wu, S. (2009). Lean supply chain and its effect on product cost and quality: a case study on Ford Motor Company. Supply Chain Management: An International Journal, 14 (5), 335–341.

Liker, J. K. (2004). The Toyota way: 14 management principles from the world’s greatest manufacturer (1st ed.). US: McGraw Hill.

Lee-Mortimer, A. (2008). A continuing lean journey: an electronic manufacturer’s adopting of Kanban. Assembly Automation, 28 (2), 103–112.

Gross, J. M. & McInnis, K. R. (2003). Kanban made simple: demystifying and applying Toyota’s legendary manufacturing process . New York: AMACOM, a division of American Management Association.

Download references

Author information

Authors and affiliations.

School of Management, Edinburgh Napier University, Edinburgh, EH14 IDJ, UK

Grant MacKerron

Logistics and Operations Management Section, Cardiff Business School, Cardiff University, Cardiff, CF10 3EU, UK

Maneesh Kumar

Department of Management, Dublin City University Business School, Glasnevin, Dublin 9, Ireland

Vikas Kumar

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Grant MacKerron .

Editor information

Editors and affiliations.

Department of Business Systems, University of Bedfordshire Business School, Luton, United Kingdom

Usha Ramanathan

University of Bedfordshire Business Scho, Luton, Bedfordshire, United Kingdom

Ramakrishnan Ramanathan

Rights and permissions

Reprints and permissions

Copyright information

© 2014 Springer-Verlag London

About this chapter

MacKerron, G., Kumar, M., Kumar, V. (2014). A Case Study on E-Kanban Implementation: A Framework for Successful Implementation. In: Ramanathan, U., Ramanathan, R. (eds) Supply Chain Strategies, Issues and Models. Springer, London. https://doi.org/10.1007/978-1-4471-5352-8_5

Download citation

DOI : https://doi.org/10.1007/978-1-4471-5352-8_5

Published : 13 September 2013

Publisher Name : Springer, London

Print ISBN : 978-1-4471-5351-1

Online ISBN : 978-1-4471-5352-8

eBook Packages : Engineering Engineering (R0)

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

Upgrading the traveler experience with NFTs

Banyan Tree Group piloted a digital scavenger hunt at its Laguna Phuket resort to improve its customer experience and boost ancillary revenue.

5-MINUTE READ

Call for change

The travel industry has been hit hard by the pandemic. Patterns of demand for services have changed, while a decline in consumer and business travel has left a revenue gap to be filled. At the same time, customer expectations are evolving. With a surge in the adoption of digital services across industries, digital now dominates customers’ interactions with all brands.

Laguna Phuket is a beachfront resort in Phuket, Thailand, with multiple hotels on its grounds. The resort’s team looked forward to welcoming customers back after the COVID-19 restrictions were lifted and decided to create a scavenger hunt as a fun way to introduce guests to the range of facilities available.

Accenture recommended creating a digital scavenger hunt to provide a Pokémon-like experience. Guests would use their mobile devices to search for digital objects ( NFTs – non-fungible tokens ) and win exclusive prizes while learning about the services the resort had to offer.

View the video

When tech meets human ingenuity

Accenture has partnered with SmartMedia Labs to leverage its BLOCKv stack to create a travel industry solution. The Net New Revenue Platform follows the travel customer journey from end to end. It can manage multi-channel distribution, back office services, self-service reporting and performance management, and deliver engaging, interactive customer experiences. It enables personalized up-selling and cross-selling, opening new ancillary revenue streams.

Leveraging the platform, our team built a proof-of-concept digital “Laguna Phuket Scavenger Hunt” that the resort could trial with guests. NFTs based on the resort’s existing branded assets could be dropped on a map, captured in augmented reality, added to a treasure chest and redeemed for real world value.

We also included media content that guests could interact with, like a welcome message from the general manager. A map helped guests navigate to facilities such as the spa, golf course, volleyball courts, bars and restaurants.

A valuable difference

The Laguna Phuket Scavenger Hunt pilot proved to be fun for everyone. Guests enjoyed capturing NFTs and discovering parts of the resort they might not otherwise have visited, and staff were thrilled to see guests having a good time. Prizes were popular— including vouchers for one night stays at Laguna Phuket properties, massages at the spa, rounds of golf, and credit toward food and beverage spend.

Of the guests who registered, 80% went on to participate in the immersive experience. The resort reported increased foot traffic to the targeted facilities and greater awareness among guests of the services offered.

Overall, the game was engaging, and easy and economical to deploy. The whole experience added value for guests as well as increasing brand awareness and driving sales for the resort.

The pilot also demonstrates the huge potential for the travel industry to use the  Net New Revenue Platform  to boost ancillary revenue and connect with guests in innovative new ways through gamification.

Meet the team

Mike Tansey Managing Director – Strategy & Consulting, Travel, Growth Markets LinkedIn

Aaron Yu Qi Senior Manager – Strategy & Consulting, Growth Markets, Travel Technology Lead LinkedIn

Haritini Kyriakou Senior Manager – Strategy & Consulting - Growth Markets, Travel Industry NFTs LinkedIn

Related capabilities

• Traveler experience
• Travel consulting

This page uses JavaScript. Please make sure that JavaScript is enabled in your browser.

• kanban library
• pricing & sign up

Thank you! We have sent you an email with details about your accounts.

• Kanban Library
• Introduction
• Why Kanban?
• Implementing Kanban
• Kanban board
• Kanban Kick-Start
• Analytics & Metrics
• DevOps Kanban - Basics
• Kanban Results
• Scrum & Kanban
• Personal Kanban
• Case Studies

Case Studies - DevOps

• Suggest a resource »

Over the last couple of years Kanban has been widely adopted by software development teams. Find out what have they learned by applying Kanban to their processes, what do they see as an advantage and what are they advising against doing. Learn from their experience before you jump in.

BBC Case Study of Lean Software Development

This is an insightful case study, analyzing the intricate details of initial applying of a Kanban system to a software development. The case study was focused on a 9-people team, working for BBC Worldwide, over a 12 month period. The study encompasses every aspect of the Kanban-associated change, analyzing the boards, the daily meetings and the accompanying analysis. There is also a look at the importance of the office set-up, the display of information radiators, the right approach to work and of cooperation.

Applying Kanban to IT Processes 2: Support Team

This is a great example of applying Kanban for typical service work - a fictional helpdesk environment, where the team was staring to do Kanban from scratch. Find out how easy it was to get started and how big productivity increase was achieved through very little change and effort.

Designing a Kanban Board – Not as Simple as you Might Think

A Kanban board is not necessarily the most complicated thing under the sun, but if you’ve thought that it’s impossible to fail at creating a good one, you may have been wrong. Here is a great example of what not to do and what to keep in mind in order for the board to stay true to the actual process.

Applying Kanban to IT Processes 3: Short Term Project

In the third article in the series, Eli presents us a situation, in which Kanban is used to track the progress of a short term project while staying on top of the equipment being the project’s subject. The goal here is to manage the project and refrain from generating additional costs associated with software tracking, equipment deploying, training or doubling up the effort.

Applying Kanban to IT Processes 1: Introduction

Kanban can be applicable to many areas of IT, such as software development, technical support and development. This article opens a series on implementing Kanban and improving IT processes by using this method. Here, we’re being shown the historical and new approaches to Kanban, with special applications to many areas of IT in the later parts.

Applying Kanban to IT Processes 4: Software Development

In this Kanban example you will learn how a small development company working in a B2B and B2C sectors modified their current processes and started making significant improvements. Their aims were to provide better visibility and measurement. Learn why establishing valuable measurements, regular revisions and constant improvement is crucial for achieving your business goals.

Our First Kanban Board for IT Operations and Support

This case study showed the implementation of Kanban method at a web development company, that provides wide range of services for large academic publishers. Kanban was adapted by a three-people support team, that was facing numerous problems, particularly tasks sizes varied from couple minutes to several weeks. The team created a blank magnetic Kanban board with cards and set a WIP limit. After a short time, the team members observed significant improvements in task orientation and process visibility.

Applying Kanban to IT Processes 5: Kaizen

In the last article of this series, Eli Weinstock-Herman discusses some of the most popular issues with Kanban implementation and brings the concept of continuous improvement closer to our understanding.

Kanban in Software Development 1: Introduction

Whether you’re a Scrum, XP, Waterfall or any other Agile method’s fan – you’ll be sure to agree, that the one goal of using a visual board is radiating the information onto the team. Meaning – making sure that each team member knows where exactly in the process a task is, how much work is still left to be done, what’s in progress and what has been completed. What makes Kanban different though?

Kanban in Software Development 2: Queues & Limits

Software development teams usually have multiple stages to complete before the software is ready, from requirement analysis and planning, design, implementation and finally testing and maintenance. In this, second, part of Derick’s journey of Kanban introduction to his team, he brings us closer to the splitting up of a process to make it represent the actual work better.

Kanban in Software Development 3: Stage Notifications

Have you ever heard of a software development pipeline? Did you experience problems with communicating to your team members the status of your current tasks in the middle of the process? This article answers your questions about how will you know when work in one column is done and ready to be pulled into the next one. Simple and helpful.

Lean and Kanban for Game Developers

It’s common for game development teams to start the process with Scrum and in later stages switch to Waterfall, ending up with a combination of the two. Clinton Keith wants to introduce the ideas of Lean and Kanban to this situation. There is the possibility to improve such processes with Lean, without abandoning Agile practices.

Why Kanban Suits DevOps so Well?

If you’re running a relatively small team, but your process is built of many steps, it’s clearly impossible to assign one person to one type of work only. Your team is forced to divide their time into different types of work, and this in turn puts an additional strain on the workflow. Find out how Kanban can provide help in such situations and learn of the two basic steps required for its implementation.

3 years of Kanban at Sandvik IT: The Story of an Improvement Journey

This is probably one of the most inspiring stories of Kanban implementation you have ever read. It has all started at Sandvik AB in 2009, with three people who wanted to increase their delivery capability. Today, Kanban method is present in more than 60 of Sandvik’s teams.

How We Mixed Scrum & Kanban to Get the Job Done

After reading Henrik Kniberg’s book “Lean from the Trenches”, Bart Vermijlen and his team decided to test the combination of Scrum and Kanban method for managing a new project for an international customer. In this article he describes how they got started and what they achieved by implementing Kanban board, also what were the problems along the way.

Kanban from a Trench

Kanban is a project management technique used, among others, in software development, known for facilitating good quality deliveries. Matt introduces us into some of the practices he has been using as part of Kanban, while working on the BBC Worldwide team in 2013.

Kanban at Scale – A Siemens Success Story

This case study describes Siemens HS’ switch from Scrum and XP to Kanban. As it turns out, having Agile experience and appreciation can be crucial in a company’s transition to Kanban. Through a highly dedicated, all-in approach, one Siemens group identified the problems they were having with Scrum, concluding that Kanban with WIP limits, Cumulative Flow Diagrams, and scatter plots were the answer they needed.

• Kanban Tool
• Pricing & sign up
• Kanban Tool On-Site
• Kanban Guide
• Kanban Tool Support
• Integrations
• Developer API
• Terms of service
• Privacy policy

© 2009-2024 Kanban Tool ® by Shore Labs . All rights reserved. | All other trademarks, logos and images mentioned on this site belong to their respective owners. | We use cookies on our website.

Kanban Tool is a visual management solution that helps companies visualize workflow, track project progress, and analyze and significantly improve business processes. Kanban Tool provides powerful online Kanban boards with seamless time tracking and insightful analytics. Our Kanban software works perfectly in any business process and is designed for teams that want to visualize work on a Kanban board .

Kanban Case Study

By   Gerard Chiva

September 20, 2020

In this Kanban Case Study we explain one of our success stories with Kanban adoption.

We’d like to show you how we achieved significant improvements with just a few interventions from our expert Kanban consultants .

This Kanban Case Study is just a small part of a full scale Kanban adoption for a telecommunications organization.

We’d like to show the results for one of the teams after just three months of implementing our Kanban Team Kickstart program.

Note: in the charts that you will see from Kanbanize analytics there is an elapsed time of five months, however bear in mind that between mid March 2020 until end of May 2020 we were in lock-down in Spain due to COVID-19 pandemia and the client halted the kanban rollout until they could adapt to remote work. The project was resumed in June, so in reality we achieved these outcomes in only three months!.

So, let’s get started.

Get Your Kanban Case Study

Get your free Kanban Case Study sent straight to your inbox.

The Challenge

• Client: Telecommunications infrastructure and service provider
• The client contacts Aktia Solutions so that we can help them improve their service quality and capability, as well as change their mindset and culture
• Initial 6-month project to roll out Kanban in six teams and at the project portfolio level

The Project

We typically start our interventions with a discovery process in order to understand the context, to meet all the people involved and to make sure we don’t miss something important.

If you want more details on how to get started with Kanban you can check this article .

They main action lines of this project were:

• Initial Assessment
• Lean and Kanban Fundamentals Training for everybody involved, including all senior and middle management
• Kanban Team Kickstart program which begins with a Kanban System Design workshop for every team
• Lean Portfolio Management : we tend to believe that the bottleneck is usually at the top of the bottle . That’s the reason we always introduce and coach the organization into Lean Portfolio Management principles and practices
• Lean Change Management : Supporting the organization in managing the change. To ensure the success of the initiative and the necessary change of mentality, it is essential to create a leadership team.

For this setup we just needed one of our expert Kanban Consultants partially involved with all the teams, supporting the overall change process and coaching at the portfolio level.

We don’t deploy full-time Scrum Masters or Agile Coaches as our approach is always to help leadership and coaching emerge within the organization.

Initial Situation

This client was not a software company, so they didn’t have previous experience with Agile or Kanban .

The situation we found was a typical one: overburdening, unclear direction, poor demand management, frequent change of priorities, multitasking, unpredictability, low productivity, low quality and long lead times.

So, the opportunity for improvement was great.

We agreed to begin the project with six teams: four network administration teams, one architecture team and a systems team.

Following one of the principles of Kanban , we agreed to start from where teams were and promote sustainable, incremental and iterative change.

The first team we started working with right before COVID lock down was one of the network administration teams.

The team was composed by a Project Manager and four network administrators.

If we have the opportunity during the initial assessment we gather some baseline metrics in order to demonstrate improvement thanks to our intervention. However, in this case there weren’t any.

We got started by designing a basic kanban system and implementing it on our favorite tool: Kanbanize .

As this organization was already partially distributed we needed a proper tool like Kanbanize. We couldn’t rely on physical boards or JIRA.

We also introduced a basic Daily Kanban Meeting and Replenishment Meeting . And we performed a continuous improvement meeting every two weeks.

For those of you already wondering, we don’t typically introduce Service Delivery Review meetings until 4th or 5th month working with a team.

Improvements

After the initial Kanban System Design workshop, participating in a few Daily Kanban Meetings and six two-hour improvement sessions we delivered the following improvements:

• 25% reduction of Delivery Time (Cycle Time)
• 33% WIP reduction, which means less overload, less multitasking and better quality
• Duplication of Productivity (Throughput)

Those are just the results for 5 days of full dedication to one team distributed across three months.

In, essence what we want to show you with this Kanban Case Study is that with a few expert interventions you can make huge improvement and save lots of money.

Let’s take a look at the results in more detail.

Analytics Dashboard

The dashboard shows the overall metrics from the day we started working with Kanbanize.

This is just a summary and we must read it carefully as it could be misleading because the first screenshoot includes the whole period of 5 months whilst the second includes only the work started after 1st of July, which is when the improvement started to be noticed.

Take a look at the percentile 85% of Cycle Time (Top Left Corner) and the improvement on WIP Age.

Cycle Time Improvement

In the following Cycle Time Scatterplot we can see both an improvement in Throughput and a reduction in Cycle Time dispersion, which also means and improvement in predictability.

From beginning of July you can see the trend in the cycle time to accumulate below 40 days, and as we enter August the trend is consistent.

Predictability Improvement

In the following chart we can see the reduction in percentile 85% of Cycle Time from 47 days to 35 days, which represents 25%.

In the second chart the tail is longer, but that’s due to the old items which had been aging in the system for a long time. We can consider those outliers as we can see the distribution getting more packed to the left.

What this Kanban Case Study shows is that we can quickly improve predictability in a system and begin to provide more accurate answers to the question “By when will it be done?”

Productivity Improvement

As a consequence of reduced cycle time and WIP we experience also significant improvement in productivity (Throughput).

This actually means a duplication of productivity. In case you can’t believe that, we ran a Montecarlo Simulation taking the initial period as input and another simulation taking the second period as input.

This Kanban Case Study demonstrates that duplicating productivity can be achieved in as little as three months, with just a few interventions of our expert Kanban Consultants.

WIP Reduction

We started to introduce WIP Limits slowly as system liquidity was low, due to specialization.

Besides, there were some team members partially working for other teams. We can see an evolution of WIP going from 30-40 to 20-30.

Cumulative Flow Diagram

In the following chart we can appreciate a significant improvement in the Cumulative Flow Diagram from beginning of July.

Summary of Kanban Case Study

With just a few days and little disruption our Kanban Consultants can achieve significant improvement for your organization.

This Kanban Case Study demonstrates that in order to achieve improved business agility you don’t need a battalion of full-time Agile Coaches and Scrum Masters in your organization.

We can achieve more with less.