Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Kanban Methodology

•Download as PPTX, PDF•
•
Sudhanva Ramesh
Sudhanva Ramesh

Kanban is a lean methodology for managing workflow. It uses visual signals like cards to limit work-in-progress and optimize flow. Software teams can implement Kanban virtually with boards and cards to visualize work, standardize workflows, and identify blockers. Key benefits include planning flexibility, shortened cycle times from overlapping skills, fewer bottlenecks from limiting work-in-progress, and support for continuous delivery of value. Teams use metrics like control charts and cumulative flow diagrams to continually improve efficiency.

1 of 12
Kanban Methodology 05/17/2017, SUDHANVA RAMESH
看板 – Kanban Kanban literally means “visual card,” “signboard,” or “billboard.” Kanban cards act as a form of “currency” representing how WIP is allowed in a system
Challenges of Iterative Approach  Short time-boxes give more frequent opportunity to measure progress and inspect software but force development items to be smaller.  Smaller development items are often too small to be valuable and difficult to identify  Quality of requirements suffers as analysts rush to prepare for upcoming cycles  Quality of current development suffers when busy analysts are unable to inspect software or answer questions during development  Quality often suffers as testers race to complete work late in the development time-box Development work often continues throughout a cycle while testing starts late and never seems to get enough time.
Kanban for Software Teams  Agile software development teams today are able to leverage the concept of agile by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.  While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice.  In part, this is because software teams can begin practicing with little to no overhead once they understand the basic principles. Unlike implementing Kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things a software teams need are a board and cards, and even those can be virtual.
Kanban boards  The work of all Kanban teams revolves around a Kanban board, a tool used to visualize work and optimize the flow of the work among the team. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.  Regardless of whether a team's board is physical or digital, their function is to ensure the team's work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved. A basic Kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.  The Kanban methodology relies upon full transparency of work and real-time communication of capacity, therefore the Kanban board should be seen as the single source of truth for the team's work.
Kanban benefits Planning flexibility A Kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum. Tip: Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. Shortened cycle times Cycle time is a key metric for Kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work. Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a backup of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in, too. In a Kanban framework, it's the entire team's responsibility to ensure work is moving smoothly through the process. Fewer bottlenecks Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenant of Kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets. Continuous delivery We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And Kanban teams focus on exactly that: optimizing the flow of work out to customers.
Kanban Metrics One of the core values is a strong focus on continually improving team efficiency and effectiveness with every iteration of work. Charts provide a visual mechanism for teams to ensure they're continuing to improve. When the team can see data, it's easier to spot bottlenecks in the process (and remove them). Two common reports Kanban teams use are control charts and cumulative flow diagrams. Tip: The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. A control chart shows the cycle time for each issue as well as a rolling average for the team. A cumulative flow diagram shows the number of issues in each state. The team can easily spot blockages by seeing the number of issues increase in any given state. Issues in intermediate states such as "In Progress" or "In Review" are not yet shipped to customers, and a blockage in these states can increase the likelihood of massive integration conflicts when the work does get merged upstream.
Scrum Vs. Kanban Some teams blend the ideals of Kanban and scrum into "scrumban." They take fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from Kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while.
Kanban Board – Configuration Options Options Description General General info. of the project such as name, administrators. Columns Define constraints on the number of issues (Kanban is usually 9 issues) Swim lanes Horizontal Splits based on Stories, Assignees or Epics Quick Filters Filter Options (Need to have understanding of JQL) Card Colors Define Flag Colors based on Assignees, DOR etc. Card layout Extra Fields (Maximum of 3) to be shown on the Stories Working days Time Zone, Working Days Definition for the team Issue Detail view Fields to be shown on Issue Detail Screen
Kanban Board – Configuration Options Board View Releases – Defined in the Project Administration and set to each story. Report View Issues – Issue Types (Stories/Epics) as defined in the Project Administration Components – Defined in the Project Administration and set to each story Feedback Project Administration – Visible to Administrators Add Ons Expand the window
Appendix
Elaborate Kanban Board 1. Define a work process flow. 2. Lay out a visual Kanban board. 3. Decide on limits for items in queue and work in progress. 4. Place prioritized goals on the left column of the board. 5. Start the board by placing stories or features in queue. 6. Move features through the process flow as work is complete. 7. Use the dates on the cards to calculate cycle time. Place an expedite track above the main left to right queue This board uses painters tape to indicate available “slots” for work in progress Product Owners manage the waiting queue. Place “done and waiting” queues between each work queue. Cycle time = finish date – start date The average cycle time from the date the item enters the board is the wait time from this point in the queue

More Related Content

Kanban Methodology

  • 2. 看板 – Kanban Kanban literally means “visual card,” “signboard,” or “billboard.” Kanban cards act as a form of “currency” representing how WIP is allowed in a system
  • 3. Challenges of Iterative Approach  Short time-boxes give more frequent opportunity to measure progress and inspect software but force development items to be smaller.  Smaller development items are often too small to be valuable and difficult to identify  Quality of requirements suffers as analysts rush to prepare for upcoming cycles  Quality of current development suffers when busy analysts are unable to inspect software or answer questions during development  Quality often suffers as testers race to complete work late in the development time-box Development work often continues throughout a cycle while testing starts late and never seems to get enough time.
  • 4. Kanban for Software Teams  Agile software development teams today are able to leverage the concept of agile by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.  While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice.  In part, this is because software teams can begin practicing with little to no overhead once they understand the basic principles. Unlike implementing Kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things a software teams need are a board and cards, and even those can be virtual.
  • 5. Kanban boards  The work of all Kanban teams revolves around a Kanban board, a tool used to visualize work and optimize the flow of the work among the team. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.  Regardless of whether a team's board is physical or digital, their function is to ensure the team's work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved. A basic Kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.  The Kanban methodology relies upon full transparency of work and real-time communication of capacity, therefore the Kanban board should be seen as the single source of truth for the team's work.
  • 6. Kanban benefits Planning flexibility A Kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum. Tip: Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. Shortened cycle times Cycle time is a key metric for Kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work. Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a backup of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in, too. In a Kanban framework, it's the entire team's responsibility to ensure work is moving smoothly through the process. Fewer bottlenecks Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenant of Kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets. Continuous delivery We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And Kanban teams focus on exactly that: optimizing the flow of work out to customers.
  • 7. Kanban Metrics One of the core values is a strong focus on continually improving team efficiency and effectiveness with every iteration of work. Charts provide a visual mechanism for teams to ensure they're continuing to improve. When the team can see data, it's easier to spot bottlenecks in the process (and remove them). Two common reports Kanban teams use are control charts and cumulative flow diagrams. Tip: The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. A control chart shows the cycle time for each issue as well as a rolling average for the team. A cumulative flow diagram shows the number of issues in each state. The team can easily spot blockages by seeing the number of issues increase in any given state. Issues in intermediate states such as "In Progress" or "In Review" are not yet shipped to customers, and a blockage in these states can increase the likelihood of massive integration conflicts when the work does get merged upstream.
  • 8. Scrum Vs. Kanban Some teams blend the ideals of Kanban and scrum into "scrumban." They take fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from Kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while.
  • 9. Kanban Board – Configuration Options Options Description General General info. of the project such as name, administrators. Columns Define constraints on the number of issues (Kanban is usually 9 issues) Swim lanes Horizontal Splits based on Stories, Assignees or Epics Quick Filters Filter Options (Need to have understanding of JQL) Card Colors Define Flag Colors based on Assignees, DOR etc. Card layout Extra Fields (Maximum of 3) to be shown on the Stories Working days Time Zone, Working Days Definition for the team Issue Detail view Fields to be shown on Issue Detail Screen
  • 10. Kanban Board – Configuration Options Board View Releases – Defined in the Project Administration and set to each story. Report View Issues – Issue Types (Stories/Epics) as defined in the Project Administration Components – Defined in the Project Administration and set to each story Feedback Project Administration – Visible to Administrators Add Ons Expand the window
  • 12. Elaborate Kanban Board 1. Define a work process flow. 2. Lay out a visual Kanban board. 3. Decide on limits for items in queue and work in progress. 4. Place prioritized goals on the left column of the board. 5. Start the board by placing stories or features in queue. 6. Move features through the process flow as work is complete. 7. Use the dates on the cards to calculate cycle time. Place an expedite track above the main left to right queue This board uses painters tape to indicate available “slots” for work in progress Product Owners manage the waiting queue. Place “done and waiting” queues between each work queue. Cycle time = finish date – start date The average cycle time from the date the item enters the board is the wait time from this point in the queue