Table of Contents

1. Introduction to Kanban
   1. 1603: Kanban’s beginnings
   2. 1940: Lean Manufacturing at Toyota
   3. 2003 – 2008: Kanban in the Software Industry
   4. 2009: the golden year for Kanban
   5. 2010 onwards: Kanban for all
2. Kanban for what?
   1. Determine if Kanban is right for your team
      1. Visualize the workflow
      2. Limit work in process (WIP)
      3. Measure and manage flow
      4. Define explicit policies
      5. Implement feedback loops
      6. Experimental evolution for collaborative improvement
3. How to start
   1. Demand Analysis
   2. Map Product, Business, Equipment
   3. Analysis Products or Services of the equipment
4. Shall we switch to Kanban?

Introduction to Kanban

1603: Kanban’s beginnings

In 1603, after the almost constant military conflicts of the 14th century and Japan’s social turmoil, the country entered a period of stability and economic growth. As the Japanese economy prospered, city streets filled with local stores and businesses, seeking the attention and awareness of customers. It is in these streets where the term Kanban was born.

Kanban comes from two Japanese words, “Kan”, meaning signal, and “Ban”, meaning board. As the streets and stores became busier and busier, store owners began to make personalized signs to attract the attention of passersby and tell them about the services each store offered.

Gradually, the Japanese began to use these cards with different designs, so it is very common to find Kanban cards in the shape of fish for fishermen’s stores, or in the shape of a wooden pipe, for pipe stores.

All these cards had one thing in common between them and with respect to the Kanban cards we know today and visualize in our work tools like Jira, they communicate a message in a clear and concise way. The message in this case was to know how many people were inside the stores, or in other words, to control the capacity of public spaces or stores.

1940: Lean Manufacturing at Toyota

Produce only what is needed, when it is needed and in the quantity needed (Taiichi Ōno).

In the 1940s, Toyota never imagined it would become the industrial giant it is today. After World War II, the automobile industry was stagnating. Toyota found itself unable to compete with U.S. automakers like Ford, the company was only making losses. Since it had no profits, it was also unable to hire more personnel. It was then that Toyota’s CEO, Kiichiro Toyoda, realized that his company’s gap with the Americans (the Americans produced ten times more) would not be fixed by hiring more staff, the solution was a bit more complex.

Toyota is committed to innovation and optimization of work organization. This change in business culture paved the way for Taiichi Ōno, a young industrial engineer. Ōno had a strict character, what we would define as “soft but firm”, which allowed him to rise quickly in the company’s hierarchy. In 1949, he became a machine store manager, where he began experimenting with new tools and principles of work organization. In 1954, he was promoted to the position of director.

Ōno identified and categorized 7 types of waste, or what is known at Toyota as Muda:

Of the 7 wastes identified by Ōno, overproduction and raw material inventory were the ones that most concerned him. What did Ōno do after this analysis? Produce what was needed when it was needed. A logical response for today’s world, but revolutionary in the 1950s.

This required keeping inventories to a minimum while ensuring a smooth workflow throughout the entire process. But how were they to identify when a new product would be needed? More importantly, how would they notify the production line and raw material suppliers? Inspired by retail stores and their Kanban cards, Ōno decided to visit the Piggly Wiggly supermarket chains in 1956 and was impressed at how they kept the shelves stocked with just the right amount of product. When he returned to Japan, he started using Kanban cards on paper to pinpoint and track demand at the Toyota factory. This is how the Kanban system was born.

Toyota used Kanban cards on each finished car, so that when the car was delivered to the customer, the card went back to the production line. Workers could only work on a car when the card identifying a demand came back to them in the workflow, and only when the number of outstanding Kanban cards reached a defined threshold. In the same way, each material used in the production chain had its own card, so that the demand signal would flow down through the entire production chain, ending up with external suppliers.

This system reduced inventories, improved throughput and provided high process visibility. Its use spread like wildfire throughout the machining division. In 1963, a plan was developed to spread it throughout the company, and soon after it was adopted in almost all of Toyota’s processes.

Toyota went from operating at a loss to the global competitor it is today. Ōno rose through all the company’s senior ranks, becoming executive vice president in 1975. His work gave rise to the new meaning of Kanban and laid the modern technical foundations of management, known as the Toyota Production System.

2003 – 2008: Kanban in the Software Industry

As the Toyota Production System gained popularity, project managers from different types of industry tried to apply the system to their jobs.

At this time, project management in the software world was gradually moving away from cumbersome and inefficient processes towards a lighter and more agile approach. It was in 2001 that the Agile Manifesto was published, where, among other things, the acceptance of changes in requirements and the frequent delivery of functional software are promoted. Even so, the Manifesto does not specify how to achieve this. This is when several management systems begin to fill this gap, the best known currently being Scrum, eXtreme Programming (XP), and Lean Software Development.

The three work methods had a significant impact on what was about to become the Kanban method.

• ScrumMany Scrum teams used boards with user story (US) cards to display and visualize information. During Sprint planning, each US or feature was written on a separate card. Together, these cards formed what we know as the sprint backlog and were placed on a large board in an office space where the entire team could see it. Each team member could approach the board, look at the US and choose the card he/she was going to work with. When they completed the work, they returned the card to the board, with the words crossed out. This system was simple but effective. It provided high visibility of progress, allowing synchronization of work between programmers and improved workflow as each developer could choose the type of feature they felt best working on.
• Lean Software DevelopmentLean Software Development: In 2003, Mary and Tom Poppendieck published the book Lean Software Development: An Agile Toolkit, where they translated the principles of Lean manufacturing from the Toyota Production System to software development and knowledge work. The book focuses on waste elimination, value stream mapping and pull systems. In 2007, the same authors published the book Implementing Lean Software Development: From Concept to Cash, which further explores the use of queuing theory to reduce software delivery times and Kanban boards as an element of the visual workspace. In 2005, Jim Sutton and Peter Middleton published Lean Software Strategies, where they identified the 5 principles of lean production in software development:

1. 1. Define the value
   2. Mapping the value stream
   3. Implement the flow
   4. Maintain a pull process
   5. Seek opportunities for improvement

• Agile Management: apart from Scrum and Lean, other concepts on how teams could become more agile were also explored. In 2004, David Anderson published the book Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, covering concepts such as flow, bottleneck, visual control and cumulative flow diagram, all of which are later incorporated into the Kanban method. At this time, teams using Scrum boards adopted these new techniques and reorganized their boards by introducing columns representing the different stages of the work, thus giving rise to Kanban boards.

Kanban boards, combined with:

• Lean Software Development Methods and Agile Management;
• Pull Programming;
• Limitation of Work to Capacity; and
• Flow Measurement

…gave rise to Kanban-style software development. This early Kanban was accepted as its own system, as it helped with all those things that Scrum was not particularly good at, such as shortening the cycle time from customer request to delivery, ensuring a steady flow of work.

As the adoption of Kanban software development grew slowly, a few pioneers helped spread the word and shape its ultimate future.

Microsoft was among the first to introduce Kanban principles. To increase productivity, they added elements of Scrum and Kanban as an extension of the existing model of
Feature Crew
model and the
Bug Jail
. This resulted in the first Scrumban project in 2004.

David Anderson, Dominica DeGrandis, Corey Ladas and Daniel Vacanti introduced the Kanban system at Corbis in 2007, where they introduced the concept of swim lanes to keep related work items together. The successful implementation and dissemination at Corbis sparked interest in the Kanban method in other companies.

Karl Scotland heard about the Kanban method at an Agile conference in 2007 from David Anderson, so he decided to introduce it to his team at Yahoo! as they were having a sprint duration problem with Scrum. The implementation was so successful that Karl became one of the first and most prominent advocates of the Kanban method.

2009: the golden year for Kanban

In January 2009, Corey Ladas published the book Scrumban: Essays on Kanban Systems for Lean Software Development, an attempt to merge Scrum, Lean and Kanban.

In April of the same year, Henrik Kniberg publishes Kanban vs. Scrum: A Practical Guide The article covers the principles of Kanban in an easy-to-understand manner.

In May, at the Lean Kanban 2009 conference organized by Anderson in Miami, the latest developments in the application of Lean Thinking to software development were presented. After this conference, the Informal Limited WIP Society was formed, with the mission to unify and spread knowledge about the Kanban method. This partnership provided a platform for aggregating articles on Kanban, which helped to further increase awareness of the method.

Also in 2009, the first web applications for managing projects and business processes with the Kanban method were launched: Agile Zen, Kanban Tool and LeanKit Kanban.

2010 onwards: Kanban for all

As the knowledge and use of Kanban became more popular, it became clear that Kanban works in software development and also in any process that contains iterations (manufacturing, sales, marketing, recruiting, etc.). Even the U.S. military began to adopt its principles.

In March 2010, Henrik Kniberg and Mattias Skarin published
Kanban and Scrum – Making the Most of Both
. In April of the same year, David Anderson published Kanban: Successful Evolutionary Change for Your Technology Business. In 2011, Jim Benson and Tonianne DeMaria Barry published Personal Kanban. Gradually, numerous other books and online articles about Kanban began to appear, documenting individual experiences and their various applications.

In 2016, Essential Kanban Condensed was published, where the 5 practices of this method that we will explain below are distilled.

Kanban for what?

As we have seen in the previous section, the Kanban method can be used in a variety of contexts to improve management and workflow.

Determine if Kanban is right for your team

In the Scrum methodology, after Sprint Planning, the backlog is frozen, so that no changes can be made to it. Such a state usually lasts about 15 days, which can lead to frustration for both developers and end customers.

What do we do if there is an emergency and a specific function needs to be implemented ASAP?

What do we do with all the bugs discovered in the live product: end customers need to wait two weeks to a month to get them fixed?

How do we handle processes that are more dynamic in nature, such as website marketing or server administration?

The Kanban method, with its Kanban boards and focus on flow, becomes an answer to these doubts, providing a highly structured, visible and flexible way of managing work.

Other questions you can ask your team to see if Kanban is the model that best fits your needs are:

• From an Agile Master, Agile Coach or Product Owner perspective:
  • Does the team know how to identify and visually capture the workflow?
  • Do they have bottlenecks? Are they identified?
  • Are they aware of the work they do with each other?
  • Do they demand flexibility to adapt to the unpredictable demand that is constantly running over them?
  • What level of structure are you looking for in project and process management?

• Questions to ask the team:
  • Do you have difficulty managing Sprint tasks?
  • What estimation method do you use? Do you think it works for you?
  • Do you have a visible and shared job board? Do you understand?
  • Do you consider that there is transparency and communication in the team?
  • Are we willing to commit to continuous improvement and begin to experiment with change?
  • Would you like to have more autonomy and responsibility for your own work management?
  • What aspects of the current process would you improve or optimize?
  • Are there team agreements?
  • Do you share the same vision and do you understand the same for each work status?

Kanban is much more than a pretty board with colorful Posits moving every day. It is a tool that allows us to optimize a process through its visualization. It helps us to improve workflows in any production process.

The 5 practices in the Essential Kanban Condensed book are:

1. Visualize the workflow
2. Limit work in progress
3. Measure and manage flow
4. Define explicit policies
5. Implement feedback loops
6. Experimental evolution for collaborative improvement

1-Display the workflow

Visualizing the workflow is crucial, and one of the essential principles of the Kanban method. With visualization, we obtain transparency. By having a single dashboard with all work items visible to the team and the organization, everyone is clear on what needs to be done, what I am or my colleagues are working on, when the work is expected to be completed, and what we have delivered.

Visualization will help you get a good understanding of how the team is currently working, which in turn will allow you to discover why things are done this way and then you can make concrete and objective decisions to improve.

How do we visualize the workflow?

The workflow is the sequence of steps that the tasks or product goes through from initiation to completion or delivery. In Kanban, flow visualization means mapping distinctive work steps onto the columns of the Kanban board and following the work items as you move through these states. The simple act of naming these states can reveal facts about your flow that you didn’t know, even detect bottlenecks.

The steps to identify the value stream are:

1. Identify the flow: flow mapping is the process by which we name the states through which the task passes, states that add value. You can help by verbalizing the activities (analyze, develop, test, etc.). The flow should provide clarity, making it easier to know which actions to focus on and which to minimize because they do not make sense for the end customer, what we would call “waste”.
2. Identify the scope of work: once the value stream has been drawn, the team has to decide which parts of it we control, what we want to focus on and how we will visualize it on a Kanban board. If we consider the flow as a map, we must mark the path along which the tasks pass. The tighter and more uniform the team working in the flow, the simpler the management of the work will be. Try not to include any step in the process over which the team has no say or impact, as it will create uncertainty and confusion.
3. Associate workflow stages to columns on a dashboard: you can rely on a physical and visible dashboard in the office or use a digital tool such as Jira. Divide the board into columns, each of which will be a stage of the flow, from right to left. If you have different classes of service, you can use swimnlanes to divide them into horizontal rows.
4. Define the types of work and what “Done” means for the team: the first step is to define the types of tasks the team works on and differentiate them with icons or colors. Make sure the team knows what each color or icon means and what definitions you have agreed upon for each work item.
5. Define on a card template each work item: for each work item, define with the team what essential information is to be seen and what is expected on each card. Different card templates can be defined depending on the types of work or deliverables we have, where the minimum essential information exchange is highlighted and facilitated.
6. Get to work!Now that you have defined colors, formats, icons, columns and swimlanes, and the template of the cards, you can start placing them in the relevant columns of the board, according to their current working status. Within the individual columns, sort the cards according to priority. The most urgent card should be at the top followed by the second most urgent and so on. With this, we solve the classic problem of if everything is urgent, then nothing is.
7. Track the flow and review the process periodically: tracking the flow of states will allow you to see bottlenecks, blockages and states where the team is overloaded. It is crucial that the board is visited daily and that the cards are updated for visibility.

2-Limiting work in progress (WIP)

Limiting WIP (Work in Progress) is a fundamental feature of Kanban. It may seem counterintuitive at first.

Are we telling teams to work less?

No. Limiting the work in progress means limiting how many tasks can be performed simultaneously, not limiting the work to be performed. With this, we reduce waiting times as well as cycle times.

Why limit the work in progress?

• Encourage a culture of work completion: start finishing, stop starting. What would you prefer, to have 40 products halfway to launch or 25 launched and generating revenue? Limiting work means focusing on those 25. The limitation helps to focus on tasks, which promotes earlier completion and monetization. How does this help us with blockers? Imagine that your team is working on all 40 products at the same time, if there is a serious incident, they will have to stop working on those 40 products. Isn’t it better to paralyze 25?
• Minimize multitasking and chaos: by limiting work in progress, we reduce noise and better manage chaos. If I throw you a tennis ball, you will easily catch it with both hands. If I throw two balls at the same time, you can catch one with each hand, catch only one, or catch none. What if I throw 10 balls at you at once? You probably wouldn’t take any of them: chaos. The same is true if we work on many tasks at the same time. Maintaining constant focus on a task improves the quality of work.

How do I start?

1. Observe the process and identify bottlenecks: observe the board, see if the equipment is overloaded, so you can identify bottlenecks.
2. Adjusts the WIP limit: limits the work in progress to the capacity of the slowest flow state. Talk to the team, analyze why a bottleneck is created at that step (are resources lacking? Is it permissions? Maybe external dependencies?).
3. Analyze and review the limits: as the process changes, as the team grows, shrinks or changes, you may need to adjust the limit.

3-Measuring and managing the flow

But what is flow?

Flow is the path through which work passes through various departments or various levels of production. It is the unique experience of each job that travels through the process.

Can a task move through the states smoothly, or can it have some interruption in a state?

Surely at some point you have been frustrated when starting a task and having to pause it once or several times because you need someone to confirm some detail, to give you permissions, or even because another more urgent task has come up that you must solve immediately. In these cases, the flow is interrupted.

In the first practice we have seen how to visualize the flow, in the second, how the tasks move through the flow. By measuring and managing the flow we analyze how these two routines impact the flow and improve it.

How do we measure it?

With daily meetings or Daily Kanban. In these meetings, which usually take place first thing in the morning for 30 to 45 minutes, we analyze how the work is moving from one state to another. You can help the team identify how long it takes for a task to move from one column to another. When tasks get blocked or stuck in columns, we have to ask ourselves why. From there, we can begin to think about what actions we are going to take to remedy it.

The important thing is not that the tasks move fast, but how smoothly they move from start to finish, i.e. without blockages.

I propose some questions to ask in the Daily Kanban:

• Is anyone blocked?
• What can I/we help you with to get unblocked?

What metrics can I use?

• Cumulative flowchart: with this metric you will be able to see the amount of work in progress in each state. The uniformity of this diagram will tell you how uniform and predictable your equipment is.

• Lead Time and Cycle Time: Lead Time measures the delivery time, i.e., it averages the time between starting work on a task(In progress) until it is delivered(Done). The Cycle Time measures the time from when the task enters as a request in the backlog(To Do) until it is delivered(Done). With these two metrics you will be able to know and predict the time it takes for the equipment to produce.

Managing and measuring flow will help you:

• Improve the overall process and stop putting out fires;
• Improve the predictability of the process;
• Mature the process and help you understand that it is less important; and
• Objectively forecast times.

4-Define explicit policies

People tend to make assumptions about everything around us. Sometimes inconsistently, sometimes conflicting. This often leads to misunderstandings and ineffective teamwork. The repetitive process and the quality of the execution of each step is what completes the success of the work performed. It also guides the team on how to make decisions in a way that allows them to move forward in the process in the best possible way.

What do we mean by policy in Kanban?

A Kanban policy refers to a common understanding of what needs to be done at each work state in order to move on to the next. The ultimate goal is to make it routine for the team, so that it helps them keep the flow going.

Please note the following:

• We own the process, not the other way around. The processes do not belong to us.
• Be pragmatic when defining policies.
• Create a visual control that allows you to see what work is running and what steps follow each status.
• Policies should help teams to be self-organizing and to develop relationships.

Imagine your team’s policies as the Golden Gate Bridge, they have to be strong for the work to flow smoothly and without future incidents. When you see that tasks tend to get stuck in some state, take the opportunity to ask questions about what we can improve or introduce so that this does not happen.

Policies need to define what we need to be done from each state in a simple and visual way. The following questions can help you establish policies with your team:

• Is the team clear about the workflow, where a task starts and where it ends?
• Does the team know what the quality control steps are?
• Does the team understand the same thing by “finished” at each stage of the flow?
• Does the team know how to prioritize an urgent task and the implication it has for them and the flow?
• Is the team clear on how to deal with unplanned tasks and how to fit them into the flow?
• How are incidents encountered in the process handled? Do they stop what everyone is doing and fix the bug? Do they put the incident task back to the backlog?

5-Implement feedback loops

“Kanban should lead to daily improvement, improvement for everyone and improvement everywhere.” (Masaaki Imai)

Kanban is a methodology that takes each iteration as a new opportunity for improvement. With Kanban you do not need to change immediately, but start exactly from where you are, simply by observing, from here, you can work on the 5 step approach of the Theory of Constraints:

1. Identify bottlenecks: look at the dashboard and how the work flows to identify where the workflow changes drastically and stagnates.
2. Exploit bottlenecks: bottlenecks do not match the capacity of other working states. Knowing that the rate at which the bottleneck completes work is the rate at which the entire system completes work, decide how you will best supply resources to this slower state. Do this at a pace that does not overwhelm the flow or the equipment.
3. Subordinate everything to bottlenecks: workflow and established policies need to be synchronized with the pace of the slowest process, so that impediments are avoided or minimized.
4. Raise bottlenecks: you will need to strengthen the state by investing in improvements such as resources, state limit or other alternatives that you consider.
5. Observe where bottlenecks occur: it is important to monitor the process. Bottlenecks are common, so you will have to repeat steps 2 to 5 to resolve them.

Waste elimination or Muda will help you analyze the current tasks in the value stream and identify those that do not add direct value to your product or project. If your team responds to ” It’s always been done this way” when you ask them about a step, it’s time to question the purpose and change it.

It is important that as a leader you identify waste and distinguish between necessary and unnecessary waste. Reducing activities that are not directly related to the value of the product will allow you to improve.

Customer confidence is gained when a service is reliable and predictable. (W. Edwards Deming)

6-Experimental evolution for collaborative improvement.

To be aligned with Kanban continuous improvement, we can use PDCA cycles.

Short PDA cycles are based on:

1. Plan: an activity to be improved is identified and communicated to the team. Ideally, all stakeholders should be included in the improvement process.
2. Do: at this point the plan from the previous step is executed. This has to be in line with the implementation of explicit policies and procedures. Take tangible actions that have come out of the previous step.
3. Check: evaluates the actions carried out in the previous step. Link them to the management and measurement of your team’s Kanban flow.
4. Act: we understand acting as evaluating whether the changes we have made in the previous stage have yielded positive or expected results. If they have not been, it means that they can be eliminated, adjusted or improved. In this case, we would start again from the first step.

How to start

If you want us to help you get started with Kanban, you can contact us, or you can follow this simple guide.

In the first phase, the survey phase, it is important that, as Agile Master, you meet as early as possible with the team and the Product Owner to understand the demand.

Demand Analysis

As an Agile Master, doing demand analysis as a first step will help you:

• Understand the context: when landing on a team it is important that you understand the environment in which the team operates, the expectations of its stakeholders and the needs of the business with respect to the team. This will help you to have a first picture and idea that will help you, later on, to plan and execute the improvement activities and the Kanban implementation.
• Identification of priorities: by analyzing the demand, you will be able to identify the team’s priorities. In turn, you will see if the team shares the same priorities, if they are established or if you need to emphasize them. With clear and shared priorities, you will be able to help the team effectively allocate resources and efforts to address the challenges they face.
• Scope for improvement: when you perform the demand analysis, both you as Agile Master and the team itself will identify opportunities for improvement in areas where changes can be implemented. It is very likely that the team is already clear about these areas of improvement. Let them talk, listen to them and write down their concerns, worries and ideas.
• Alignment with business objectives: once the demand has been analyzed, you will be able to see if the team is aligned with the business objectives and priorities. You will also see if they deliver real value, and if they don’t, you can help them change the flows so that they do.

Gather the entire team, preferably on-site at the offices. If you can’t gather it in person, do it online and use visual tools such as Miro.

The objective of analyzing equipment demand is to understand:

• Who asks the team
• What they ask
• How do these requests reach them (Teams chat, mail, Jira request, informal chat, etc.)?
• What percentage of total demand does each request represent
• How they prioritize each type of request, either by type of service or by requester

You can use the following questions to ask them:

• Who is your Business Owner? Do you centralize all the requests you receive for business?
• How does your Business Owner send you the requests?
• Does the Business Owner prioritize the different business requests you receive?
• In case you do not have a single Business Owner, which Business people make requests to you?
• To which departments or products do these Business Owners or Business applicants belong?
• Through which channel do you receive your requests?
• Do you have regular meetings with them or a place to make requests and follow up on initiatives?
• Do you receive requests from your Head of Product? What type of applications are they? Through which channel do they reach you? Are they usually urgent?
• Do other equipment enhance your applications?
• What kind of applications are they (cross, dependencies, etc.)?
• Through which channel do you receive requests from other teams?
• What percentage of each applicant represents the usual workload for the team?
• How do you prioritize this demand?
• How do you handle urgent requests from different applicants? Do you have a matrix or team agreements on demand prioritization?
• Do you synchronize with other teams with whom you have joint projects or initiatives?
• Are all applications in Jira? Who creates the tickets?
• Are the Jira tickets detailed with all the information? Who details this information? And when (planning, replenishment, dailies, etc.)?
• If the team is not clear about what is requested in a ticket, who do you manage it with (Product Owner, Business Owner, alone, etc.)?
• Do you have a template in the Jira tickets with the necessary information (what is needed, what for, steps to follow, etc.)?
• Do you have Definition of Done and Definition of Ready shared and visible in Jira for the team?

With the help of these questions, you will write down the demand analysis in different Posits. It is recommended that different colors of Posits be used by type of information (requester, percentage, urgency, category of request, etc.). This way it will be more visual.

Encourage them to move the Posits or arrows if necessary, make them participate in the process, they have to understand that the exercise is also important for them to share how they see the demand and how they understand it.

Map Product, Business, Equipment

Now that we have the demand drawn in a visual way and shared with the team, it is time to detail a little more how it relates to the technologies, predictability and the team.

With this exercise, you will be able to do:

• Strategic alignment: relating demand to products, business, technology and team will give you a clear view of whether the team is aligned with the organization’s overall strategy. In this way, we can help you avoid wasting time and resources that do not directly contribute to the organization’s objectives.
• Identify opportunities: you will be able to analyze the technologies currently used by the team and see if they can be improved. In this way, it will be possible to resolve incidents, improve efficiency, and provide a secure environment where equipment data is stored and worked from.
• Prediction and planning: by understanding how products relate to technologies, we can better predict delivery times. In this way, we can reduce uncertainty and help ensure fast and smooth delivery.

Part of the demand drawing to meet with the Product Owner and ask the following questions for each type of request:

• What type of deliverable does this request represent – is it a .csv, an Excel, a product, a SQL, etc.?
• How many team members work on this application?
• To whom does this request reach? Which channel? How do you convey this to the team?
• What technologies are involved in responding to this request (Tableau, Redshift, OnPrem, etc.)?
• What is the predictability of this type of application? Is it standard? Is it expeditious? Is there a deadline? Is it plannable? Does it stay in the backlog for when we have more capacity?
• With what urgency would you categorize this request? Is it easy for you to plan for the next sprint or the next two weeks? Do you categorize it as a Blocker and paralyze everything to get it delivered as soon as possible? Does it stay in the backlog?

It is important to identify trends and patterns in requests to better understand business needs.

Analysis Products or Services of the equipment

In this step, once we have done the demand analysis, and we have identified how this demand relates to the Business and the Team, we are going to analyze the Products that the team has together with the Product Owner.

Analyzing the products or services provided by the equipment will help you:

• Optimize the workflow: so that we identify possible areas of improvement in the workflow. By better understanding how we manage and deliver products we can identify bottlenecks, process inefficiencies and start working on solving those problems or improvements.
• Identify opportunities for improvement: the team will be aware of how they work and will be able to detect opportunities to improve efficiency, quality and business satisfaction. At this point, we can include the optimization of processes with automation, or redesigning the current flow, introducing or betting on new technologies such as Cloud, adopting new practices or establishing or reviewing the priorities of the team.
• Alignment with Business needs: by understanding and highlighting existing team deliverables and their priority and impact on the Business, we will better align the team’s work with these needs and objectives. In this way, we ensure that the team works in the areas of greatest impact and value for the organization.

To do this, you can use the following questions to help you:

• What are the products that go into the equipment?
• What is the product’s objective and vision?
• What technology does the product relate to in the creation and delivery of the product?
• Who is the Product’s main customer? Who will use it?
• What is the frequency of Product delivery?
• How predictable is the Product delivery process?
• What feedback do we receive from Product deliveries?
• How do we manage that feedback and how does it reach the team?
• Is the team aware of Product process improvement opportunities?
• How do you receive, as a PO, these opportunities for improvement from the team?
• How do you prioritize them?
• How does it reach the backlog?
• How are these improvements communicated to Business?

Shall we switch to Kanban?

If the team is working on Scrum and does not work because the demand is not plannable, the sprints run over them, the workflow is not clear, the roles are very specialized, and there is no visibility or transparency about the work being done by the team, adopting the Kanban methodology will help you:

• Improve flexibility in work management: with Kanban we obtain greater flexibility in the management of tasks and projects. While, in Scrum, iterations are fixed and do not allow flexibility for unplanned demand, with Kanban we can have a continuous flow of work, thus improving the management of changes in requirements or priorities.
• Focus on value stream: with Kanban we focus on optimizing the team’s workflow and eliminating or reducing bottlenecks. If Scrum is creating bottlenecks and an inefficient workflow, with Kanban you can improve the speed of delivery.
• Visibility: with Kanban you can give more visibility to the work being done among the team. In the same way, stakeholders such as Business or HPO can see from the Jira dashboard the status of initiatives, how they are being prioritized and how they are progressing. With visibility, we will be able to identify and attack problems that arise more quickly.
• Elimination of over-commitment: In Scrum, the team commits to deliver a fixed number of tasks in a given time. It does not mean that with Kanban the commitment goes away, but unlike Scrum, it does not generate frustration if the team does not arrive because the scope of tasks was more complex. In the same way, collaboration among team members is encouraged to deliver tasks together and with greater speed.
• Fewer ceremonies: Scrum has five ceremonies, many of which are inefficient for teams or seen as a “waste of time”. Kanban has seven ceremonies, but unlike Scrum, they are lighter and more adaptable. You can adopt those that really generate value and help you (for example, risk management is often the least used by teams). Remember, the methodology has to be at the service of the team, not the other way around.
• Waste reduction: with Kanban you will be able to identify and eliminate, whenever possible, those steps in the process that do not make sense and are a problem to deliver value. In this way, you will improve the efficiency and productivity of your team.
• Improved delivery time: when we focus on “stop starting, start finishing” we deliver continuously, minimize work in progress, and maintain focus on the tasks at hand, which leads to accelerated product deliveries.