David Anderson’s Kanban Book

For those interested in Kanban and still reading those actual things you hold in your hands and spend several hours on, David Anderson’s new Kanban book is out there…

As David provided Agilesparks with the draft manuscript to help us prepare for a Kanban Coaching Workshop we had with him back in February,  I was able to read it early and provide the first review :

David provides a comprehensive guide to implementing Kanban in a software development/maintenance environment.
Covering the mechanics, dynamics, principles and rationale behind why Kanban is a so promising framework for managing the work of a variety of teams and groups and being an evolutionary-based change management driver.

Kanban is the practical approach to implement Lean Software Development, and this book is the practical guide for how to start using Kanban, and how to adapt the system for advanced needs.

The book is clear and flowing, even though it covers some quite technical material. I would recommend it to Development managers, Project/Program managers, Agile Coaches/Consultants. It addresses concerns/needs of Novice as well as those already familiar with Kanban and looking for advanced answers.

Even if you don’t intend to implement a kanban system, there are a lot of techniques and ideas that are easily applicable to any product development/maintenance environment, agile or not.

Bottom line, highly recommended.
Beyond that, I believe the champion of any Kanban initiative in the software world (and probably in services as well) should read this book, an am taking the steps to make that happen at least in Kanban initiatives I’m involved in 😉
David asked me some time ago whether it makes sense to think of translating the book to Hebrew and I told him that those in the Israeli IT world that find the time/energy to read, are quite proficient doing it in English, and that probably the market is not large enough to warrant it.

It might be worth though to translate a basic explanation of Kanban to hebrew… maybe something from kanban101.com

Anyhow – recommended book, go ahead and order a copy, you won’t regret it.


Leave a Comment

Using Kanban to drive Continuous Improvement and Management Teams

It seems like new uses for Kanban are cropping up every day. And the interesting thing is that in some cases, several different organizations/people come up with similar ideas spontaneously.

One of those ideas is to use Kanban in order to drive Continuous Improvement efforts.
I’ve recently described such an approach in my presentation for Lean Conference 2010 in Atlanta (#LSSC10), it also came up in other talks and others seem to be having great success using this (E.g. . In Israel I saw it come up in Kanban workshops we hold for clients, as well as some ideas that clients have after they start using Kanban for other things. It w

Think of mgmt teams at the organization level, or for any group (e.g. VP R&D and his staff members, CEO and the other CXOs/VPs, Group leader with his team leads).

We want this team to lead Continuous Improvement initiatives in their organization. Both at the aggregate level collating and coordinating efforts the various teams they’re in charge of, as well as initiatives that originate and are focused at their level.

Who hasn’t seen the lessons learned exercise which was great, but when you come some time later, the action items are at best documented, lets not even talk about tracked and executed.

Same goes for Agile Retrospectives, even though the frequency of the retrospectives improves the situation a bit and nags the team some more…

Enter Kanban. Now, really, you don’t need anything fancy. We mainly are talking about creating a backlog of action items. Prioritizing it. And choosing a FEW action items for execution each time. Until you are finished with those, don’t divert or context switch to any other initiative. This is where the Kanban WIP Limit comes into play…

This of course can be used for ANY kind of action item for the management team.

Again, you don’t have to do it with Kanban. A shared action item list you check items off as you go can work just as well. I used Sharepoint, a whiteboard, and other ways to achieve that. With Kanban you get the added benefit of the WIP limits. From my experience, management teams and other sorts of committees, are quite horrible at focusing and managing their WIP, so Kanban can really help.

In addition, if your organization is currently undergoing a Lean/Agile transition, adopting a Kanban board can help you lead by example and show that you are adopting Lean/Agile methods. It will also help you understand what is happening at the production floor, and adopt the language being used by the organization.

That is why, with our customers over at Agilesparks we are starting to use Kanban boards to drive Agile Transitions, and recommend to the team managing the transition to adopt his board and style for their own use.

Other elements of Lean that can help here are A3 and PDM.

A3 (see http://www.crisp.se/lean/a3-template) is problem-solving tool originating in Toyota. Its beauty is that it drives you to be concise and focused. Each A3 describes a problem and what you are trying to do about it, in essence bodying the PDCA Plan Do Check Act cycle.

PDM – The Hoshin Kanri Policy Deployment Matrix (see http://en.wikipedia.org/wiki/Hoshin_Kanri) is another way to practically use the PDCA cycle. I’ll try to describe it in more depth some other time…

I don’t promise to post here often. With my over-WIP I barely find time to tweet (over at http://twitter.com/yuvalyeret) …

In the meantime – what are YOU thinking of doing with Kanban? let me know…

Leave a Comment

Change J-Curve Discussion on the iScrum forum

In the last few weeks we (Agilesparks) have been trying to liven up the israeli scrum forum – iScrum.
This is a forum dedicated to practitioners of Agile/Scrum in Israel. There are some interesting discussions and ideas and its also a place to monitor for events in the israeli Agile/Scrum community (e.g. user groups, ask the expert sessions, etc.)

One of the questions raised was the issue of agile adoption curve. There are several interesting opinions, and I’ve been thinking a bit about this subject, see two of my comments:

ince indeed it is a journey, a critical question is what is the break even point on this project or in other words how long to roi.

The costs are investment in Learning, training, coaching as well as organizational time, attention and productivity loss due to learning curve and transition difficulties ( see the j-curve mentioned in the material Inbar quoted )

depending on the specific variables of the transition the time will vary but it will be more in the months time frame to years timeframe I think.

Note that at that point it’s important to continue to drive to more and more agility to get even higher benefits


Another reference to the change curve is in the Virgina Satir Change model also see .

An important point to take from this model regarding change and agile transitions specifically, is that the level of resistance/chaos that causes the productivity dip and risks to the transition, is a function of readiness and preparation.
An organization can minimize the time/impact of the dip by improving preparation. Improving preparation is possible if you assess your readiness for this change and focus on improving readiness before going into the change. While this sounds a bit un-agile, it seems like there is empirical research around this that shows that at least some of this preparation brings better results.

I’ve also been thinking about the implications of exactly how you do your agile transition (or any similar change for that matter) on the change curve. Some of my questions:
* Is it better to dive in across the board, or do it in vertical slices of the organization? In other words, is it better to stagger the productivity dip, or to have one big dip and get it over with? My instinct is to stagger the dip, with the added value that after one slice (department) has gone thru the dip, the organization has better strength/stamina to go thru another dip because it knows what waits on the other side, and its also more prepared at the organizational level to support the change. In addition the risk of a big organization going into such a dip, with the various departments feeding off each other’s dip, and the supporting functions trying to support everything and remove impediments everywhere at once, is a scary notion (speaking from experience…)
* Is it better to implement a change via a big bang methodology (e.g. Scrum) or a pattern/practice at a time? Here, while I think the dip will indeed be shallower for each practice, in most cases you’ll want to move fast to utilize the “driving force” of an enterprise-level change. It is important to note that after you DO the big change, it might be best to continue with one practice/pattern at a time, in a Kaizen/Continuous Improvement spirit. Note that the Lean/Toyota style talks about doing even the initial change in a flow mode rather than a large batch mode. Sounds agile to me 😉

Together with a few colleagues we were looking at the effects of this curve on a big enterprise transition we are involved in, and trying to learn from it. I’m sure some more thoughts will come up…

Join us in the discussion!

Leave a Comment

Kanban/Scrumban at the Israeli Scrum user group 2009

Yesterday was the Israeli Scrum User Group for 2009. While we have monthly gatherings, usually for an afternoon or so, we try to have at least one full day gathering a year. The gatherings are organized by Agilesparks – we are trying to push the Agile/Scrum community forward as much as possible – both because we believe in the collaboration and value add that this community/tribe provides, as well as because the stronger we are as a community, the further Agile will go in Israel, which is good for everyone working in the Agile space.

We had very interesting speakers from all over the israeli community, including some of our partners and friends, topped by a humbling appearance by the one and only Dr. Alistair Cockburn who gave a keynote and a couple of sessions. I still need to gather my thoughts and notes as there were several ideas I took home with me, both from sessions as well as lobby discussions and questions from my session.

One concept that struck home was Feature Thinning which Alistair presented as a way to have the minimum (thinnest) implementation possible, relevant especially in the tale end of projects, when under schedule pressure. This is especially useful when under Fixed Contracts, where you need to have that “checkmark” that a feature exists, and having some minimal implementation is better than paying a penalty for having nothing.

As the other coaches in Agilesparks know, I have somewhat of a Kanban fever these days. I implemented a Kanban flavored Scrum over in Sanrad when I was VP R&D there, and I think it was a neat solution for our situation. My presentation, inspired by ideas from David Anderson, Corey Ladas and Karl Scotland, was an introduction to the subject, and covered the Why we might want to look at Kanban, What is it, how it can Complement Scrum, and what can we do with it.

One of the key places I see Kanban providing some much needed answers is what happens upstream to an Enterprise-scale Scrum development cycle. In one of our clients, we see a lot of mess around the backlog, requirements elaboration, having just enough design/architecture ready, and all in all being READY-READY for the sprints. We are working on a workflow that will include Kanban that will try to address this issue. I’m very much a workflow kind of guy, and had a lot of fun playing with workflows in Issue Trackers (mainly JIRA) in the past. I see great promise in the visibility and WIP control that Kanban will provide in this area.

I also think teams can get a lot of value from visualizing the workflow and thinking in WIP terms inside their Scrum framework. This will lead to a process of addressing problems in the short term and identifying and removing systemic constraints in the long term, assuming retrospectives are held effectively.

One of the key questions, which was also raised by one of the other speakers – Guy Nirpaz, is whether it is wise to use Kanban as a starting point on the way to agility. Kanban is clearly a less prescriptive methodology, and can be abused quite easily to become a phased/waterfall process, if the strive towards small MMFs, fast cycle times and SLA is not there.

OTOH the Kanban approach seems to have some advantages compared to Scrum – transition can be smoother, and agility/leanness can grow from the needs of the workflow and metrics, not from thin air. This can make it easier and clearer to some folk, and since an Agile Transition is a tough change, anything that makes the process itself smoother is quite important. I’m looking for the opportunity to try this approach and see.

For now, I think it is safe to say that if you are considering a Kanban-based transition, you should seek some professional help to help ensure you are going to the right direction, and your guide/coach is keeping you honest. Same is still true for a Scrum-based transition IMHO…

In the meantime, take a look at my presentation and tell me what you think…

FYI it has been featured on the slideshare homepage – the editorial staff liked it for some reason or the other 😉

Leave a Comment

Lately I’ve been trying to understand how best to represent Known Unknowns (KU) stories/tasks in the BDC. I’m talking about things like Support cases from customers – things not related to stories from the backlog essentially, that you know you will need to address.

Its the kind of stuff that “is not supposed to happen” as part of the sprint, but we’re in the real world, and in the real world, it happens.

I’m familiar with two major ways to account for those:

  • One is to remove them from the capacity. This removes it from visibility, OTOH it makes for a pure burndown/capacity/velocity calculation/tracking
  • The other is to create stories for those “buckets”. This way you can track them, have better visibility.

Assuming an organization is interested in tracking and measuring this part of the work, the team needs to integrate this into their burndown chart, velocity, etc.

The issue is that those tasks are sort of a “buffer for rainy day”, so the remaining effort on them as the sprint goes by is not necessarily related to actual invested effort compared to the whole bucket, but rather to time left where the events might happen.

Think support cases from customers – assuming you have a 30 day sprint. you planned on 20 days for the sprint based on yesterday’s weather. after 15 days, assuming you spent 5 days on this already, what should be the remaining effort for the BDC?
Naively, 20-5=15 days. But realistically, the statistics are that after half of the sprint, if your yesterday’s weather is to be counted on, 20/2=10.

Is anyone aware of any tools that manage these kinds of KU effectively without requiring the team/SM to manually update the remaining effort?

Together with some other coaches, we raised the option of drawing the planned work as an internal burndown line BELOW the total burndown. Another alternative was to show a burnup of this kind of work separately, so the team has visibility.

The idea is to make sure the team knows whether they got lucky and had more capacity left for their planned work, so should be more aggressive than their original plans, or the other way around. Without this kind of visibility, a critical aspect of the burndown chart is lost – teams don’t trust it, there is too much fog to see clearly where they SHOULD be so they don’t hold themselves accountable to where they ACTUALLY are.

Bonus question – do you have teams that count this work into velocity? using SP? How?

Note that the rationale for counting this into velocity is the “metric” side of velocity, not the planning aspect.

Its clear that this cannot be used to plan the release. It can, if you find the right way to account for it, reflect productivity of the team around this kind of work.

Leave a Comment

Invest in your Product Owner

Getting the user stories on the right size, in the right format, in essence getting to the sprint in a READY-READY form (READY actually means READY, not make-believe READY…) requires a lot of cooperation from the Product Owner/Manager. He should understand the value he gets if he INVESTs in stories/features, because it DOES create work that he’s not used to. In some cases you will have a hard time getting to this level of detail from your Product Management, so you’ll need to create a Product Owner that proxies and fills in the blanks – usually a Business Analyst, Designer, Architect can help in that aspect.


The biggest challenge is if a Product Owner/Manager doesn’t think he can get any business value from small granular stories, and that “he needs everything – all features, and all requirements in all stories”. In that case, your biggest impediment is that the PO doesn’t believe in Agility – and you should think what to do about that. I would suggest a discussion about Agile potential ROI for the business, driven by faster time to market, better adjustment to customer real requirements, and much better predictability and trust that the versions will get out on schedule.


On a side note, I see the lack of understanding/belief in the value of agility on the business side as a very common and very dangerous problem. Without the business side on board, the development teams will lose a lot of the reasoning behind some of the Agile practices/principles, which might lead to regression to lesser ways.


E.g. ROI for faster sprints without delivery to the customer or PO coming for a demo – I believe they still have value in having a fast feedback cycle, even if internal, and even if used mainly for the team improving its performance. But its clear that the ROI will be a lot smaller than if the sprint result is actually taken by the customer or other groups in the company, both to earn money, as well as give much better feedback.






Leave a Comment

Big is bad, small is good!

While a lot of what affects an agile team is within the team’s scope of responsibility, the key antipattern I’m talking about today sort of isn’t…

A big factor on whether a team can be effective is the size of stories/features on its backlog. A lot of good things happen when stories are Small (See the S in INVEST). A lot of bad things happen if they’re too big.

Lets look at how it looks when the stories/features are too big (team takes more than a week or so to start-to-finish them)

Teams cannot achieve real flow – testers are idle waiting for a long story to be developed, then are stressed to test it, since the end of the iteration/sprint is near.

Since there is a tendency of individuals to want some ownership of at least a story (if not a module), assuming big stories, an iteration/sprint will look like a mini-waterfall, with the developers each taking a story, all major stories getting into testing about 2/3 of the way into the sprint, and we lose the ability to control the sprint scope, and left with either making it across the finish line after managing to catch all defects and fixing them for all of the stories, or we are left with a sprint which is unsuccessful. The burndown chart of such a team will look like the one below.





For some really big stories, its not even clear how to finish them in one sprint, so teams start to have sprints for “Design”, “Coding”, “Testing” leading to really a waterfall across sprints.


With both in-sprint and across-sprints mini-waterfalls the mains problems are visibility and ability to change priorities or adapt to new requirements.

From the moment you start working on a story/feature, it becomes WIP – work in progress. Your aim should be to minimize this. WIP is Waste, that becomes apparent in the cases your Product Owner comes and says that this feature is now not the top priority anymore and he needs something else instead, or that after seeing a demo first time at the end of the sprint, he has a lot of changes in mind that you would have liked to have known about before finishing all the work.

The visibility problem is due to the fact that the real measure of progress is Working Software. Knowing that the design task is done and we are in coding is nice, but after many years developing software we don’t trust it that much. We prefer seeing working software frequently DURING the sprints.


The one potential problem of really small stories, is that they become a unit of business value that doesn’t mean much for the Customer/Product Owner. The drive for “Minimum Marketable Features” adopted by Kanban is to have slightly bigger stories, something you would mention in a product blog for example. There’s a fine balance that needs to be managed here.

Leave a Comment

« Newer Posts · Older Posts »