Effort Tracking with Kanban

Software development using Kanban principles has not focused on Effort Tracking (though there hasn’t been a strong position against the same). At Digité, we were practitioners of Iterative Software Development. As part of this process, we emphasized on Daily Effort Tracking (time filing) for several reasons: A) Since we have geographically distributed teams, it helped us get a sense of what happened without chasing individual team members or asking people to send an email with their update. B) A lot of effort based metrics could be accurately computed and relied upon (especially if you have come from the ISO/CMMI world!). For example, we knew how much time was spent in product work (enhancements) vs unproductive work (rework) and see if the trend was in the right direction. We knew how much time was required for essential tasks that were not functionality accretive, like, performance tuning, stack upgrades, etc. The list can go on…

We adopted Kanban about 18 monthsback but continued with this practice. We tweaked it a bit to: A) Dedicate 2-3 minutes every day on filing time before signing off for the day (we strongly discourage Weekly Time filing) B) Use the previous day’s timesheet report as the basis to cover what was done the previous day across the team (no memory jogging required) in the Daily Status Call. It takes less than 3-5 minutes to discuss this for a team of 10. The rest of the daily call is focused on discussing what will be done today, team goals and specific issues.

One common criticism is the accuracy of such data that can be used for further analysis. However, once the team realizes that people are discussing and looking at this data daily, the accuracy and seriousness creeps in without any follow-up or persuasion.

Kanban focuses on cycle time and throughput (and associated metrics like wait time/ blocked time/ etc.). However, combining actual effort data with cycle time helps get the following additional benefits:

a) Compute the actual effort to complete work of different kinds – defects, user stories of different size (S, M, L, XL, XXL), etc. A sample of our data is below:

b) Publish variance between estimated effort and actual effort to help the participants of the estimation process ee-baseline their “gut-feel” benchmark. We estimate using Planning Poker and hence, the above input helps making future estimates more accurate. As you can see from the sample snapshot below, some of the estimates are quite “off” the actual.

c) Improve throughput – Combining the estimated effort with actual data on past effort for similar cards, you can get a better idea of how many parallel threads one should split the card into so that the cycle time can be reduced. For example, if a new user story is estimated as a XL size, and the team’s Planning Poker estimate is 30hrs, we know that this is against our past trend. Past trend tells us 55 hrs. So, either our estimation bucket is wrong or we are missing something in our “gut” estimate.If this suggests re-estimation and the revised estimate is 50hrs and our desired cycle time is less than a week, we know we must break it into 2 smaller scope (size) cards.

d) It also helps estimate how much time we need to reserve for “other” work buckets – leave/ paid time off, training, engineering tasks like performance, refactoring, etc. and budget for that. A sample data snapshot is enclosed for our team:

This means that at an aggregate level, for our team, close to 50% of the capacity can be earmarked for product enhancements (user stories). However, going by the trend of the last quarter, we can budget close to 70% for the same!

e) Understand if the amount of effort spent on “rework” (Internal Defects + Customer Defects) is improving or deteriorating (thereby pointing towards the need for training, resource upgrades, etc.).

In short, without any significant additional effort or being intrusive, one is able to collect additional data points for better planning and forecasting. These data points are very helpful in aggregate planning and forecasting (beyond what is on the board today or in the backlog).

Sudipta (Sudi) Lahiri
Sr. VP - Engineering and Professional Services

Using Swift-Kanban for customer portfolio management

My business focuses on lean-agile coaching, consulting and training, not on software development services, and I successfully use Kanban to manage my customer portfolio.

It is untrue that Kanban is only good for software change management work. Many people new to Kanban have this misconception mainly for two reasons. One is because Kanban started in a change management team at Microsoft. The other one is because David J Anderson declared that Kanban is a method for change management in the organization and that statement can be misinterpreted. What David meant with that is Kanban helps you bring positive change to your organization. Although the original Kanban description is around software it is actually context free. There is a very popular book entitled Personal Kanban by Jim Benson that I invite you to consult.


Getting back to the main subject of this blog. I have been using Kanban for years to manage customer-facing and business-facing activities. The customer facing activities Kanban board has one swim lane per customer for easy visualization of the activities with each customer and to avoid making mistakes on which customer a given activity is for.  Each customer has its own backlog, which we make visual as the first column on the board. The other columns are Ready, Execute (doing/done), Customer verification, and Completed columns. The WIPs for each customer are different and in agreement with the customer needs and my resources. The figure shows our Swift Kanban board for one of the countries where we conduct business. In addition to making remote communication easier, a huge advantage we have with Swift Kanban is that it allows us to resort the lanes up and down to indicate level of priority and activity (we used the smart lanes feature to accomplish this). That is, a lane (a customer) bubbles up if the our level of activity with that customer and its priority increases and bubbles down if the activity/priority decreases. That way if we will not be doing any work with a customer for a while its lane is "out of the way"; and it is still readily available to resurface at a moment's notice. We also count with a swim lane called "other" for general work that has to do with potential customers when the relationship hasn't matured yet to the point of earning a dedicated lane.

Our classes of service are

• Business task
• Business appointment
• Business partner / associate task
• Fixed delivery date
• Immediate

Intangible tasks are business-facing and are, therefore, on a separate board.
Cheers,
Masa K Maeda

Kanban and the Focus on Fundamentals

(Previously published in the DJ Anderson Associates sponsored eBook - Quotable Kanban)
Our Kanban journey began early in 2010 when we decided that we would build a product in the Kanban space that would address some of the basic issues we saw our prospects face in adoption of Agile methods such as Scrum and XP within their organizations that were historically used to doing waterfall or iterative or some hybrid Agile method that combined more than one type of processes.

While the presence of established competitors was a strong reason to look beyond the ‘popular’ Agile methods, we also felt a strong appeal for Kanban existed because of its focus on 3 key fundamentals:

• Evolutionary change
• Improvement of existing processes
• Engineering rather than Management processes

We have seen numerous organizations and teams take on large (revolutionary) process improvement initiatives – be it 6-Sigma or CMMi or even Agile.  We have seen them become consumed with “the task of process improvement” over and over again.  As a result, while there is improvement in the interim, in terms of consistency with which a process is followed in the team or the organization, the overall magnitude in terms of the time, effort and cost, of making the transition becomes huge and management begins to question the benefits!  Kanban, with its promise of evolutionary change, with one stroke, takes care of this fundamental issue.  It allows teams to take on only those aspects of change that they can comfortably handle.

Secondly, with an evolutionary approach, Kanban necessarily tackles current processes in an organization and helps improve them, rather than force a range of new processes on it.  This is fundamental to understanding how Kanban can be applied not just to traditional software processes – but also to popular Agile processes such as Scrum and indeed, to non-software processes – bet they within IT or in general business functions such as Sales or Marketing or Legal! So besides being attractive to software teams, their pull for non-software teams, presented us with a much bigger opportunity, which we are already starting to see materialize!

However, the one aspect of Kanban that excites more than others is that it forces teams to focus on the “engineering” or the “delivery” processes rather than the “management” processes.  This is where, I feel, Kanban truly distinguishes itself from its ‘competitors’, if one may terms them as that.  Through the use of statistical control charts, Kanban helps teams identify their normal performance and their deviations from the normal – the outliers.  Rather than advise teams to simply do better documentation or better management or better reviews, it encourages teams to do better root-cause analysis – and attack root causes for poor performance – be that better or more specific testing, better development or design practices or better collaboration and requirements elicitation from customers. And in doing so, I believe Kanban shows itself to be far more effective than any other framework to start making incremental, lasting improvements in the final quality of the product or service being delivered.

Far too often, after initial gains have been realized through ‘traditional’ Process Improvement initiatives, teams start to question the extra overhead of ‘following process’ and wonder ‘what is in it for them’.  With Kanban, these teams are much more likely to realize lasting gains through evolutionary, (incremental) improvements to basic existing delivery/ engineering processes and measuring their own performance in a much more meaningful manner.

Mahesh Singh

Co-founder, Sr. VP – Product

Scrum Bangalore - Scrum, Kanban and Pecha-Kucha!

I recently participated in a local Scrum event in Bangalore and shared my experience in trying to implement Scrum and later Scrumban within my current organization. I have shared the slides below.

The event was hosted by SAP in their campus and had a keynote speaker who shared the information about Lean/ Scrum implementation @ SAP and how they are trying to transform the entire organization to a newer or “lean” way of software development.

It’s great to see such enterprises adapting to this new wave of software development. It will encourage a lot of other companies to try out such methodologies and share their experiences/ learning. The event had more than 40 participants from various companies like Mindtree, Aricent, SAP, Cisco etc.

There was an interactive talk from David Putman, a UK based consultant, and Srikanth Tadipatri.  Both are currently helping the Tesco India team to move to agile development and they shared their experiences on various topics/ issues related to scrum implementation.

The other 4 presentations, including mine, were in a "Pecha-Kucha" format ( a Japanese style, where a concept is presented in 6 mins, 20 slides, auto-timed for 20 seconds) themed around 'Scrum: Success Stories'.

My talk was about our experience so far in implementing Scrumban – a combination of Scrum and Kanban and how it is helping us to work more effectively. It is hard to summarize the experience of over 2 years in 6 minutes (Pecha-kucha style is supposed to save people from 'Death by Powerpoint' ;)), but I hope I was able to put my points across. 

Here's a link to my presentation, do check it out and feel free to contact and we can discuss in detail.