One of the important aspects of The Kanban Method is Class of Service (CoS). CoS is a risk categorization mechanism for any work item. We identify 4 Classes of Service – Standard, Fixed Date, Expedite, and Intangibles – depending on customer expectation, value and loss of business value identified as cost of delay. For this blog, cards that are classified as Intangible CoS will be referred to as “Intangibles”.
As Agile gets larger acceptance across the (Indian software) industry, the (manual) testing community has been concerned about how it will impact them. They hear about developers doing testing, test automation and hence wonder – what role am I going to be play? Is this going to kill my job? The concern is natural given a general perception that in Agile, developers should be doing testing. This concern has been part of the resistance that some of the organizations are facing in adopting Agile thinking.
The Pune Chapter Meet of the Limited WIP Society was held on Mar 8, 2014. This session objective was to address challenges faced by Lean-Kanban practitioners in their projects. Participants from 4 different organizations attended this session. A couple of problems were posed by the participants ahead of time. We decided to work on the first one for this session. Some projects are fixed scope, fixed budget and have relatively small duration – 3-4 months.
The role of metrics in TPS is crisply explained in Jeffrey Liker’s book “The Toyota Way”. He explains that Toyota prefers simple metrics and does not use many of them at the plant or the company level. Some of my peers may be surprised to hear this! The author highlights his point with a simple example. During one of his visits to one of the Toyota plants, he was told that apart from a few basic metrics (like cost of plant operations, parts per million defects, some safety related and productivity), the metric Toyota finds most useful as a manager is the number of “Andon” pulls made by each Team Member to stop the production line.
Projects are often executed by dynamic teams. They start with a small core team and as the project gains momentum, add resources over time. This is commonly seen in IT service organizations that do fixed price projects. Fixed price projects have a defined scope that needs to be delivered within a contracted budget and within a negotiated timeline. For the purpose of this experience report, “Dynamic teams” or “Fixed Price projects” will be used interchangeably. Unfortunately, as Ron Jeffries put it, “Agile is founded on management of scope, not predicting when you’ll be done, even if you had fixed team size and “fixed” scope.”
Try SwiftKanban Enterprise Plan FREE for 30 days.