PEARL XVI : SCRUMBAN – A tool for software production and Support

PEARL XVI : Scrumban is a combination between Scrum and Kanban methodologies for increased applicability and versatility tool for software production and support focused companies.

Scrum is an iterative and prescriptive process for building software using the Agile methodology. A development team plans and commits to completing a certain amount of work in a certain time period called a sprint. At the end of the sprint, the team reviews the work with a product owner. They then hold a retrospective to analyze their processes during the sprint, and determine what can be improved next time.

Scrum can be an effective tool for introducing teams to Agile. Its more rigid structure provides a framework of understanding that is far easier to grasp than the loose nature of Kanban might be for teams used to rigidly planned waterfall-style projects.

The daily standup, planning, review, and retrospective meetings are excellent touch points for periodic checking in with the work that is happening and reviewing with stakeholders. The retrospective itself is the crown jewel of the Scrum framework, and is what enables teams to focus on continuous improvement, or Kaizen.

One of the primary motivations for moving a team to Scrum is to get away from the often restrictive and inefficient processes of the waterfall model. In this model, there is frequently too much time spent on planning and designing before any work begins. After that, teams find themselves unable to respond to change later in the project as the developing and testing proceeds. All of this is why waterfall is a sub-optimal process for software development.

But look at the makeup of a typical Scrum sprint:

  1. Team plans the work that will be worked on over the next sprint.
  2. During planning, teams try to design as many features as possible, so that they can more accurately estimate what they can complete during the Sprint.
  3. During the Sprint, the team develops and then tests their user stories.
  4. At the end of the Sprint, the Product Owner reviews the work completed, and decides which of the stories are shippable and ready for production.

What does this mean? Scrum is a series of miniature waterfall projects wrapped up into iterations called “Sprints.” This is a push-based system, where another solution would be to use a pull-based one. Enter Scrumban.

Scrumban can give teams the power to adapt and change to stakeholder and production needs, without feeling overburdened by their project methodology. It is designed to remove metrics that encourage undesired outcomes. It can restore working time to the team, and avoids unnecessary meetings. And most importantly, it can limit the team’s work in progress so that they can finish what they start to a high standard. Scrumban can remove overhead stress for the development team, increase efficiency, and increase the overall satisfaction for the customer.

Scrumban combines the best features of both methods. It compounds the prescriptive nature of Scrum and the process improvement of Kanban, allowing teams to become Agile and to continually improve their process. Scrumban is becoming especially popular in services industries, where project development and maintenance goes together.

Scrumban is a process for evolving a Scrum instance to be more Lean oriented, supplemented with core Kanban practices such as: visualization, work-in-process limits, work flow management, and making policies explicit. The basic Scrumban implementation principles include:

  • Start with all the ceremonies, artifacts and roles you use now.
  • Agree to pursue improvement towards a more effective process.
  • Respect current roles, responsibilities and job titles.

Scrumban as a combination of a Kanban and Scrum method

Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected work items or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished work and defects are familiar from the Kanban model. Using these methods, the team’s workflow is directed in a way that allows for minimum completion time for each work item or programming error, and on the other hand ensures each team member is constantly employed.

To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. In the case of decentralized teams, stage-illustration software such as Assembla, ScrumWorks, TargetProcess, Rational Team Concert, Eylean board, OnTime, Kanban Tool or JIRA in combination with Jira Agile can be used to visualize each team’s product backlog items, defects and tasks divided into separate phases.

In their simplest, the tasks are categorized into the work stages:

  • Unstarted
  • Ongoing
  • Completed

If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”). These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work cannot be raised. A more specific task division also makes it possible for employees to specialize in a certain phase of work.

There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times. A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.

The major differences between Scrum and Kanban are derived from the fact that, in Scrum, work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables, which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible.

In Kanban, Workitems deemed  high priority and needed as soon as  possible have a way of being addressed  ahead of current work. Periodic reviews  of process, tools, team performance, and
WIP limits to find improvements and  eliminate inefficiencies or waste.

When to use Scrumban?

Are you considering implementing Scrumban in your team or business? You should take it into account if you are doing one of these:

  • Projects maintenance,
  • Event-driven work (support, hardening),
  • Problematic projects management (projects with unexpected user stories and bugs),
  • New product development (work preceding sprint development or following sprint development),
  • Continuous management improvement.

Scrumban board gives an easy view of process workflow. It informs about the number of items the team is currently working on as well as already finished ones. It influences the improvement of accountability, responsibility, communication and performance results.

 The example of a Scrumban board

Scrumban is a pull-based system, where the team no longer plans out the work that is committed to during the planning meeting, and instead continually grooms the backlog. The same Scrum meetings (planning, review, and retrospective) can and should still take place, but the cadence of them can be more context-driven. The real key to moving to Scrumban, though, is ensuring that work in progress (WIP) is still limited.

Work-in-progress limits, not Sprints. With Scrum, the amount of work that is ongoing is limited by the Sprint time commitment. But in Scrumban, with no specific time commitment, the team must limit itself through the use of WIP limits on columns within their task board. The goal is always to move tickets in a flow from left to right on the board. If too many issues are in progress, the team is at risk of not finishing anything to high quality standards. Instead, there should be a maximum number of tickets allowed per column. If the number of tickets in that column ever exceeds the maximum, the entire team should swarm onto that column and help move tickets on. This should happen no matter what functional role a team member fills.

Key Scrumban Terms
• Work Backlog – Equivalent to Scrum’s Product Backlog with minor differences for how  Workitems are tracked.
• Workitem– The individual descriptions of functionality needed by the business that either define enhancements or defects.
• Workline – The series of stages in the software development process that pull work from the  Work Backlog and produce shippable business value.
• Stages – The common and discrete steps required to deliver software within an organization.

The Weekly Timeblock (WTB)

The Weekly Timeblock is a reoccurring meeting used for multiple purposes. It should be set up in the  middle of the week (Wednesday are best) so as to avoid holidays and vacation days that typically  occur at the beginning and end of each workweek.
Two to four hours is recommended and set to occur in the afternoon so any preparation work can be  completed ahead of time. The team will use the time they need and leave the rest. Having a projector,  screen, and ample whiteboard space will be conducive for any technical discussions and problem  solving.
The first use of the Weekly Timeblock is for demonstrating any completed work. This is the time  where Developers can show the Product Owner what was completed and get Acceptance. Completed  work can be demonstrated outside of the meeting anytime but it is good for the team to have  every one witness the conclusion of work.
Once Workitems have been demonstrated, the team should reflect on how their development process  is going, any tools they use, and review the data on how Workitems are flowing through the  Workline. They should have frank discussions about any new innovation that should be reinforced or  impediments to be overcome. Clear action items and their owners should be identified along with a  target resolution date.
After the review of recent activity, the team should have a preview of upcoming Workitems the  Product Owner is preparing. The Developers should seek to understand the intent of each item,  asking questions and getting clarity so everyone is familiar with what’s needed. The Developers  should also provide feedback on Workitem scope, structure, and the optimal execution order so the  Product Owner can make any needed adjustments to content and priority.

Standup meetings. The Daily Standup meeting is a concept borrowed from Scrum and serves the same purpose; to coordinate activities and identify impediments. A daily reoccurring meeting should be set up for 30  minutes where the first half is focused on the team members updating everyone on what they did  since the last meeting, what they intend to do before the next meeting, and any impediments that are  blocking, or threaten to block progress on their work. The second half is for any impromptu  discussions necessary to address questions or plan activities. The meeting should be held near the Board so discussions focus around work in progress and updates can be made publically. Ideally the  meeting should occur early in the day, just after everyone has had a chance to get to work, reorient themselves, and think about what they’ll focus on.

In practice, this boils down to redundant statuses that recount information available on the team’s task board. For Scrumban, a more effective method is to refocus on the flow of tickets on the board. That same pattern of yesterday/today/blocked can be transferred to the tickets themselves—the group moves through each column and briefly discusses each ticket and what is necessary to move that ticket rightward on the board. This provides far more context to the team and informs everyone of any major architectural or design decisions.

Metrics. Metrics can certainly be useful, but they are often abused by managers and business stakeholders who want to unnaturally simplify a complex process into a one-dimensional number. Velocity, the amount of story points a Scrum team completes in a single Sprint, is such a metric that incentivizes lower quality at the end of a Sprint as a team scrambles to finish every last story they committed to. When the number fluctuates, as is common with a newer team, the stakeholders begin to question the outputs of the team, and even the effectiveness of Agile itself.

Instead of velocity, a useful Scrumban metric is cycle time. This is the length of time a ticket takes to complete, measured from when it is first began. Over time, a statistical analysis of all tickets in the project can yield a mean cycle time and standard deviation. This can be a useful planning tool at a macro level, as it is trivial to add up the number of stories and multiply by mean cycle time.

The Work Backlog under Scrumban is basically the same as with Scrum. It is a collection of User  Stories and Acceptance Criteria written and maintained by the Product Owner. These individual Workitems describe the business value desired.

To keep the collection organized, additional information is associated with each item:
• ID–A unique identifier (e.g. B#042) for easy searches and reference.
• Project –A label to group a set of work items together according to a theme or purpose.
• Title –A concise, action-oriented description of the business value desired.
• User Story –A formulaic description of who will benefit from the item, what exactly is  wanted, and why it is wanted. The User Story provides the context behind the request and  enables the Developers to understand the goal, and not just take orders.
• Acceptance Criteria –A list of the specific conditions required for the Workitem to be  considered complete.
• Status –An indicator of the readiness of the Workitem, when it is being worked on, and the  final disposition.

When the progress of a Work item through the Workline is blocked

As a team is working on items, it will be fairly common that progress from one stage to another is blocked. These blockages can be internalto the team where the work was more challenging than expected. Whatever the cause the team should “swarm” to help wherever possible to remove the blockage. All team members can assist to one degree or another, even crossing the traditional role boundaries of Coders & Testers to help test, code, prepare environments, research or write documentation.
When a blocking issue is external to the team, such as when a required server hasn’t yet been delivered or subject matter experts are needed for questions, the Scrum Master should attempt to resolve it. The rest of the team can be engaged as needed to help with external issues.
If a Workitem is blocked completely with no resolution in sight, it should be pulled from the Workline and its status changed from ‘In Progress’ to ‘New’ or ‘Draft’ depending on what is needed before the team can pull it back into the Workline again.

Workitem needs to be completed as soon as possible
There are two ways to address this need. First, the Product Owner should be continually maintaining  the order of the Work Backlog such that the items the business considers the most valuable are at or  near the top. It is these top items that the team reviews and makes ‘Ready’ through discussions and  feedback and are pulled into the Workline as capacity opens up.
If there a more urgent need for a work item to be completed than what the standard process  provides, the item’s priority can be changed to expedited and be fast-tracked through to completion.

Defects in Scrumban

Defects are a natural part of any software development effort and dealing with them is straightforward. When defects associated with current Workitems are found they should be addressed before the item is considered complete and ready for demonstration.
Assuming the defect was found during the Testing stage and it is relatively minor, then the item can stay within the Testing stage as the Coder works closely with the Testing to diagnose the issue and provide updated code.
If the diagnosing and fixing effort is much larger however, such as requiring more than a day to complete, then the Workitem should move back to the Coding stage even if the WIP limits are exceeded. The priority for the Coder should be to address the defect and get the Workline flowing again in the right direction.
Sometimes defects are found in areas of the code not currently part of a Workitem in progress. These should be brought to the attention of the Product Owner who can create a new Workitem representing the defect and prioritize it accordingly in the Work Backlog.

Estimation

The statistics kept on how long Workitems take to transit the Workline should be enough to estimate  how long any particular item will take to be completed. For example, if the average number of days is  four, then any new item pulled into the Workline is likely to take four days. By the same logic, if there was a set of Workitems that comprised a release, then the time to complete the entire set is four  times the number of items in the set

This estimation technique works well when the scopes of the Workitems are somewhat consistent.  When they are not, some rough estimates of size, combined with the transit time for those specific  sizes can produce a more accurate estimate although it will take longer to gather enough data to be  confident with the results.Be mindful that any additional time spent by the team should be worth the  effort and if not, abandoned for the simple statistics Kanban provides.

Advertisements

PEARL XII : Kanban : Application of Lean software development to Agile Methodologies

PEARL XII : Kanban : Application of Lean software development to Agile Methodologies.

Most agile m­ethods such as Scrum and XP are already well aligned with lean principles. In 2004, David Anderson pioneered a more direct implementation of Lean Thinking and Theory of Constraints to software development. Under the guidance of experts such as Don Reinertsen, this evolved into what David called a “Kanban system for software development”, and which most people now simply refer to as “Kanban”. ­So while Kanban as applied to software development is new, Kanban as used in Lean Production is over a half century old.

A software development lifecycle process or a project management process could be said to be “lean” if it was observed to be aligned with the values of the Lean Software Development movement and the principles of Lean Software Development.

Bob Charette was invited but unable to attend the 2001 meeting at Snowbird, Utah, where the Manifesto for Agile Software Development was authored. Despite missing this historic meeting, Lean Software Development was considered as one of several Agile approaches to software development. Jim Highsmith dedicated a chapter of his 2002 book to an interview with Bob about the topic. Later, Mary & Tom Poppendieck went on to author a series of 3 books. During the first few years of the 21st Century, Lean principles were used to explain why Agile methods were better. Lean explained that Agile methods contained little “waste” and hence produced a better economic outcome. Lean principles were used as a “permission giver” to adopt Agile methods.

Lean Software Development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement, and the practices of companies like Toyota. Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” the mechanisms that deliver that Value. The main principles of Lean include:

  1. Eliminating Waste
  2. Amplifying Learning
  3. Deciding as Late as Possible
  4. Delivering as Fast as Possible
  5. Empowering the Team
  6. Building Integrity In
  7. Seeing the Whole

Lean eliminates waste through such practices as selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers. Lean uses the idea of work product being “pulled” via customer request. It focuses decision-making authority and ability on individuals and small teams, since research shows this to be faster and more efficient than hierarchical flow of control. Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.

Perhaps the most important Lean activity is to build a value stream map. This means to break down a process into individual steps, and identify which steps add value and which steps do not, thus adding to the waste (muda). The goal, then, is to eliminate the waste and improve the value-added steps (kaizen). An important lean tool helping to manage the work flow is the concept of pull system, which is usually visualized using a Kanban board. In general, we can define the Kanban software process  as a WIP (Work In Process) limited pull system visualized by the Kanban board.

In recent years, Lean Software Development has really emerged as its own discipline related to, but not specifically a subset of the Agile movement. This evolution started with the synthesis of ideas from Lean Product Development and the work of Donald G. Reinertsen and ideas emerging from the non-Agile world of large scale system engineering and the writing of James Sutton and Peter Middleton.  David also synthesized the work of Eli Goldratt and W. Edwards Deming and developed a focus on flow rather than waste reduction . At the behest of Reinertsen around 2005, David introduced the use of kanban systems that limit work-in-progress and “pull” new work only when the system is ready to process it. Alan Shalloway added his thoughts on Lean software development in his 2009 book on the topic. Since 2007, the emergence of Lean as a new force in the progress of the software development profession has been focused on improving flow, managing risk, and improving (management) decision making. Kanban has become a major enabler for Lean initiatives in IT-related work. It appears that a focus on flow, rather than a focus on waste elimination, is proving a better catalyst for continuous improvement within knowledge work activities such as software development.

The Lean Systems Society published its credo at the 2012 Lean Software & Systems Conference. This was based on a set of values published a year earlier. Those values include:

  • Accept the human condition
  • Accept that complexity & uncertainty are natural to knowledge work
  • Work towards a better Economic Outcome
  • While enabling a better Sociological Outcome
  • Seek, embrace & question ideas from a wide range of disciplines
  • A values-based community enhances the speed & depth of positive change

Kanban is an agile methodology for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and team members pull work from a queue.

Kanban in the context of software development can mean a visual process management system that tells what to produce, when to produce it, and how much to produce inspired by the Toyota Production System and Lean manufacturing.

The name ‘Kanban’ originates from Japanese and translates roughly as “signboard” or “billboard”. The Kanban method in one of the Kanban methods available today. It was formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. One example of such a pull system is a kanban system, and it is after this popular form of a work-in-progress, limited pull system that the method is named.

In Lean Software Development, the kanban are virtual and often tracked by setting a maximum number for a given step in the workflow of a work item type. In some implementations, electronic systems keep track of the virtual kanban and provide a signal when new work can be started. The signal can be visual or in the form of an alert such as an email.

Virtual kanban systems are often combined with visual controls to provide a visual virtual kanban system representing the workflow of one or several work item types. Such systems are often referred to as “kanban boards” or “electronic kanban systems

Visual control systems are valuable in changing behavior because they display status in an easy-to-see format. This ensures that everyone has a shared understanding of work status and process constraints. Transparency is a key to achieving organizational change

The Kanban method is rooted in four basic principles:

Start with what you do now

The Kanban method does not prescribe a specific set of roles or process steps. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system. The Kanban method is a change management method.

Agree to pursue incremental, evolutionary change

The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but have a higher failure rate due to resistance and fear in the organization. The Kanban method encourages continuous small incremental and evolutionary changes to your current system.

Respect the current process, roles, responsibilities and titles

It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.

Leadership at all levels

Acts of leadership at all levels in the organization from individual contributors to senior management should be encouraged.

Kanban Vs Agile

Kanban systems are an approach to scheduling  work. Kanban shares with typical AMs the fact that  requirements are expressed in atomic features (also  known as user stories, work items, Minimum  Marketable Features, or MMF), to be implemented  incrementally. To this purpose, AMs use time-boxed  iterations. – at the beginning of the iteration, the team meets and chooses features from their backlog  that can be done by the end of the iteration. Over the  course of the iteration, they develop those stories,  and at the end of the iteration, they ship them .
Kanban systems are different because they focus on a continuous flow of work, and disregard fixed  iterations. When needed, the team chooses a subset  of features from the backlog and moves them to the  Kanban board. Then, it develops these features one
after the other. Work is delivered as soon as it’s  ready, and the team only works on one – or very few – feature at a time.

Six core practices of Kanban

Anderson identified five core properties that had been observed in each successful implementation of the Kanban method. They were later relabeled as practices and extended with the addition of a sixth.

  1. Visualize
    The workflow of knowledge work is inherently invisible. Visualising the flow of work and making it visible is core to understanding how work proceeds. Without understanding the workflow, making the right changes is harder.
    A common way to visualise the workflow is to use a card wall with cards and columns. The columns on the card wall representing the different states or steps in the workflow.
  2. Limit WIP
    Limiting work-in-process implies that a pull system is implemented on parts or all of the workflow. The pull system will act as one of the main stimuli for continuous, incremental and evolutionary changes to your system.
    The pull system can be implemented as a kanban system, a CONWIP system, a DBR system, or some other variant. The critical elements are that work-in-process at each state in the workflow is limited and that new work is “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.
    WIP limits encourage everyone to work as a team and prevent any one individual from getting too far ahead of anyone else.
  3. Manage flow
    The flow of work through each state in the workflow should be monitored, measured and reported. By actively managing the flow the continuous, incremental and evolutionary changes to the system can be evaluated to have positive or negative effects on the system. Kanban elevates awareness of constraints and forces the team to address them before they can bring additional work into the queue. New work is pulled into the system when there is capacity to handle it, rather than being pushed into the system based on demand. With Kanban, the focus of management and the team becomes the flow of work, not the utilization of the team.
    While Scrum has retrospectives at the end of each iteration to address these items, Kanban explicitly points out constraints in real time and encourages the team to address them as they arise.
  4. Make policies explicit
    Until the mechanism of a process is made explicit, it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.
  5. Implement feedback loops
    Collaboration to review flow of work and demand versus capability measures, metrics and indicators coupled with anecdotal narrative explaining notable events is vital to enabling evolutionary change. Organizations that have not implemented the second level of feedback – the operations review – have generally not seen process improvements beyond a localized team level. As a result, they have not realized the full benefits of Kanban observed elsewhere.
  6. Improve collaboratively, evolve experimentally (using models and the scientific method)
    The Kanban method encourages small continuous, incremental and evolutionary changes that stick. When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus.
    The Kanban method suggests that a scientific approach is used to implement continuous, incremental and evolutionary changes.

Common models used are:

  • Theory of constraints (the study of bottlenecks)
  • Deming System of Profound Knowledge (a study of variation and how it affects processes)
  • Lean economic model (based on the concept of elimination of “waste” (or muda, muri and mura)).

Open Kanban

An open source, Agile and Lean based method to deliver value for knowledge work like Information Technology, Software Development, Business, Product Development or Personal organization. On the Lean side it is inspired on the work of Taiichi Ohno (Toyota Production System), Eliyahu Goldratt (Theory of Constraints) and Edward Deming. On the Agile side it takes inspiration from the Agile manifesto signers, and in addition contributions from Alan Shalloway’s Kanban for Teams, Corey Ladas Scrumban and David Anderson’s early Kanban work.

It innovates by making the whole method fully open source and free to improve or modify. Open Kanban was written by Joseph Hurtado, and it has been translated by members of the community to French, Italian, Russian and Ukrainian.

Steps to Get Started

  • Agree on a set of goals for introducing Kanban.
  • Map the value stream.
  • Define some point where you want to control  input. Define what is upstream and who are the upstream stakeholders.
  • Define some exit point beyond which you do  not intend to control.
  • Define a set of work items types based on the work requests that come from the upstream stakeholders.
  • Analyze the demand for each work item type.
  • Meet with the upstream and downstream stakeholders.
  • Create a board/card wall to track the value stream you are controlling.
  • Optionally, create an electronic system to track and report the same.
  • Agree with the team to have a standup meeting in front of the board; invite upstream and downstream stakeholders .
  • Agree to have regular operations review meeting for retrospective analysis of the  process; invite upstream and downstream stakeholders .
  • Train the team on the new board, WIP limits and the pull system. Nothing else in  their world should have changed.

VersionOne Kanban Boards

VersionOne provides a single platform to manage all your projects, from Scrum to Kanban and everything in between, without sacrificing cross-project visibility. Visualize, manage and optimize your workflow using VersionOne’s custom Kanban boards.

With some teams practicing Scrum and others choosing Kanban, it can be challenging for managers to get a clear, integrated view of status across all projects. VersionOne’s Kanban boards make it easy to manage all projects in a single tool without sacrificing cross-project visibility and consolidated reporting. When teams are practicing lean methods within iterations, VersionOne provides the Kanban capabilities to help agile teams visualize and manage their workflow processes.

Agile teams can Create custom Kanban boards using named columns to illustrate each stage of  workflow process, and an expedited track for high priority items. Work items are visually represented using story cards and can be pulled from prioritized queue and moved through the workflow easily using drag-and-drop software functionality.

Managing the Kanban board in VersionOne provides real-time visibility for the entire team with full accessibility for remote members. Agile Teams see at a glance what work items are in progress and where they are in the development process. Visual cues within the Kanban board identify items that are blocked, held up in wait queue, or have exceeded their aging threshold, providing an early indicator of potential problems.

VersionOne software helps maximize  flow of work by setting explicit WIP limits across single or multiple contiguous columns to determine how many items can be worked on at each stage of  process. Visual cues within the Kanban board lets team know when WIP limits are exceeded to trigger conversations and refocus the agile team’s efforts on the right work to ensure a continuous flow.

VersionOne enables to Track and measure the average time to complete a work item using Cycle Cycle Time reporting capabilities. The ability to track cycle time metrics gives visibility into past performance to help  increase the predictability of  delivery and drive continuous process improvement.

The Cycle Time clock starts when work begins on a request and ends when the item is ready for delivery. Cycle time is a mechanical measure of process capability.

VersionOne can be used Identify and resolve bottlenecks using Cumulative Flow reports to see how well items are flowing through the process, Determine where work is stalled and where you should focus improvement efforts.

The Cumulative Flow diagram provides a graphic depiction of how work items are moving through various statuses on the way to being “Done”. It shows the total scope of a project, grouped by status, and thus lets us know how much of that scope is in a particular status at a given time.

As highlightedd, the use of a basic Kanban board (manual and/or virtual for distributed teams)  serves to bring everyone onto the same page, improve focus and prompt questions that lead to revision of policies and practices. When the team’s  experience grows, the Kanban board will change  to expand and refine the workflow representation, thereby reflecting a more sophisticated level