The question often put before Lean-Agile coaches or consultants is – what does Lean-Agile say about Estimation? Good, bad… or ugly? In general, the Lean-Agile community is negative about Estimation.
I have spoken about this topic in several conferences in India in the last year. After my talk, I would get several requests to share a “template” of the Upstream
Digité products have been the core execution platform for many IT service companies in India. We have a leadership position in the market, given that 4 of the Top 5 India based IT service companies use our products.
I have seen people focus a lot on what the WIP limit should be for a Value Stream stage of a Kanban system. However, once the WIP limit is known, I haven’t seen much thought going into where to put those WIP limits. Hence, this blog!
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.”
Many teams adopting Kanban come from Agile background. Agile thinking has discouraged the use of Due Dates. Due Dates breed undesirable behavior. Focus on Due Dates results in teams working under significant pressure. Quite often, that translates into short cuts in Design/ Testing activities. The net effect is that work quality is compromised and technical debt piles up. That said, Agile methodologies, specifically Scrum, inherently have a Due Date. Most often, this is the Sprint end date.
Try SwiftKanban Enterprise Plan FREE for 30 days.