Kanban, which literally translates as Visual (Kan) Card (Ban) or billboard, is an operational method used to increase efficiency. It was originally developed by the industrial engineer Taiichi Ohno while working at Toyota. Ohno analyzed the way supermarket shelves are stocked and applied the lessons learnt to the factory floor, creating unprecedented efficiency. The visual card (Kanban) was used to signal the need for more items to upstream suppliers on the production line. The Kanban method can be applied to any field, including strategic planning, sales and marketing, and human skills management, but more recently Kanban has been applied to the process of developing software-centric solutions in an attempt to ensure that value is delivered to the customer as quickly as possible. The information technology industry has been plagued since its beginning with projects running over schedule and over budget, but more significantly failing to deliver value to customers in a time frame that enables them to compete and be successful. These endemic issues have become a critical element of business in an age dominated by digital disruption and unprecedented change.
Kanban is fundamentally very simple and relies on a small number of principles, the origins of which can be attributed to the engineers at Toyota:
- Make work visible
Traditional project management methods hide the work items from the people who carry out the work; Kanban exposes the work to everyone, allowing any team member to contribute to the way work items flow through the board and ultimately deliver value to the customer
- Limit work in progress
Project managers and team leads have traditionally been under pressure to get products finished or to include more features, and have responded to this pressure by burdening the team with more work items; this results in lots of focus switching and inevitably half-finished items and reduced efficiency
Paradoxically, Kanban encourages the number of items in progress to be limited, resulting in greater efficiency and more finished items; the reduced number of in-progress items allows team members to concentrate on one thing at a time without having to switch focus
- Manage the flow of work
Using traditional project management methods, bottlenecks or blockers are hard to identify and typically only surface at the time of a post project review, often only after the product is delivered late and missing features
Using Kanban, the visibility of work and the ability to identify stalled processes - whether because of bottlenecks or lack of work items - allows a flow problem to be identified and rectified quickly
The next diagram shows the way the Kanban facility in Enterprise Architect responds when the number of items in a lane exceeds the number specified in the max items (Work in Progress or WIP limit) value for that lane; the header is highlighted in a configurable color and the numbers (number of items/max items) also provide a visual queue that will prompt the team to respond by swarming (a number of team members focusing) on the lane to reduce the number of items
Enterprise Architect has a flexible and integrated Kanban facility built into the core product, allowing projects of any size and vertical market to benefit from the profound efficiencies that come with this simple, elegant and lean project management approach. Regardless of the type of process that is being used, Enterprise Architect’s Kanban features can be quickly and seamlessly integrated into any method, creating a compelling visual solution and team collaboration platform that will result in products, services and solutions being delivered to customers with efficiency and in record time - delighting both product owners and customers alike.
The Kanban features in Enterprise Architect are highly configurable and can be altered to suit any team and process, including Agile, iterative and incremental, and even waterfall projects. There is a very low barrier to adoption and teams can commence with Kanban immediately. The most basic Kanban board comprises a diagram divided into a small number of lanes; a range of work items can be added to the diagram, including Features, User Stories, Defects, Changes, Use Cases, Requirements and more. Work Items can be drawn with a compelling visual style representing a colored card, and can be dragged anywhere in the diagram to change order in a given lane, or from lane to lane progressing from left to right through the board, representing progress towards value for the customer. The lanes are typically bound to the values of a 'project management aware' property such as status or phase, and as the item is dragged from lane to lane the value of the bound property is automatically changed.
Any number of resources, performing specified roles, can be allocated to work items as they flow through the Kanban board, and the progress can be visualized as one or more progress bars displayed at the bottom of the card. The allocation is driven by Enterprise Architect's practical and simple resource allocation facility, which can be used to define the relationship between resources (team members) and work items (cards). Any number of team members can assign themselves to a work item, indicating the role they will perform, and the start date, finish date, and the expected time can be used to record estimates of how long the task will take.
Progress can be updated as a percentage of completion, which can be displayed visually on the card. The Kanban board (like any diagram) can also be displayed as a Gantt chart or a list view, supporting alternative project management representations.
The Kanban cards can be configured to display an extensive set of properties, with compelling icons, colors and progress bars to communicate the important aspects of the work item, resource allocation and work item progress. The properties include the item name, type, status, version, priority, stereotype, phase, author and more.
The names, colors and number of lanes can be configured, in addition to a range of other properties such as the overfill limits, defaults and the definition of sub-lanes. The appearance of the board and the work items can all be configured, using different colors, fonts and styles including a hand-drawn mode that might appeal to teams more accustomed to using a physical board with colored notes. It is also possible to set the chart appearance to highlight elements that come from the same hierarchies.
Enterprise Architect has built-in Kanban diagrams, and a number of workflow Patterns that are pre-built and that can be used 'As-Is' or configured to suit any project or initiative. The workflow Patterns define one, two or three stage workflows; for example, the two stage workflow defines a Kanban board solely for managing the prioritization of the backlog, and items from the backlog are then moved from the backlog Kanban to the first lane of the iteration Kanban. If necessary, the Product Owner can use Enterprise Architect's security facility to lock the backlog Kanban, ensuring that the order of items in the backlog is not inadvertently changed.
There are a number of commercial tools that allow Kanban to be used to manage projects visually, but Enterprise Architect’s Kanban facility is incredibly powerful because the tool is also a sophisticated modeling platform for strategic and business analysis, architecture, design, implementation, testing and deployment. This means that work items on a Kanban Board can be linked to strategic decisions, business rules, policies, requirements, architecture and design elements, wireframes and UX models, programming code, database tables, procedures, tests, virtual or physical deployment nodes, and more. For the first time everyone in the team can collaborate in the same environment using a toolbox of facilities purpose built for their discipline, while at the same time being able to visualize and manage the value being delivered to the customer in a powerful and visually compelling set of Kanban boards.
A high priority User Story that is at the top of the backlog could be pulled into the 'In Progress' lane and a developer could immediately commence work on it. The work might entail the coding of business rules, the review of detailed requirements, changes to a database schema or the addition of an element or attribute to an information schema, and the creation of a new or updated deployment environment.
All of these artifacts can be found inside the same repository without the need to launch other tools or schedule meetings to locate the needed information. The strategic drivers can be seen in the context of their business owners, architectural design and principles can be viewed, Business Rules can be visualized in relation to the policies they qualify, a live connection can be made to the databases and their schemas analyzed and altered, XML schemas can be inspected and messages constructed, programming code can be written and deployment targets detailed, and all of this achieved in a single collaborative platform.
Charts and Dashboards
Enterprise Architect has a sophisticated charting facility that can be used to create powerful and expressive charts and dashboards that will provide insights into the Kanban process and enable Product Owners and other team members to monitor performance and determine ways of fine tuning how the team is working. There are a range of built-in charts including bar and pie charts, heat maps and more but a team is free to create any number of user-defined charts and these can be incorporated into team processes and reviews.
The Kanban project management methodology helps you to develop a dynamic, easy-to-view progress summary of the stages of development of a project, where the stages are represented as lanes and sub lanes of a diagram - a Kanban Board. In Enterprise Architect, you can apply a form of this methodology to your project administration diagrams to monitor and manage the flow of work in a particular area.
The stages of development can be defined by the value of a project management property of an element, such as Phase, Version or Status, or a user-defined Tagged Value. The elements that represent each task or object of a task are initially placed in the lanes for the earlier stages of the project, and work on the task is reflected by moving the corresponding element to a different lane on the diagram. If a diagram is linked to a project management property, dragging an element from one lane to another automatically changes the value of the property to the value that the lane represents.
In this illustration, the lanes identify what work is being performed in each stage of development.
New tasks will usually begin in the left-most lane, and completed tasks will usually pass through all lanes before coming to rest in the right-most lane and then being moved off the diagram. A typical workflow is to choose the next task that you are going to work on by starting in the right-most lane and seeing if it has any tasks that you are able to progress; if not, move to the next lane and repeat, and so on.