Archive for kanban

Pictures from Kanban workshop for Managers

Today I delivered the first public Kanban workshop for managers in Israel

The feedback was great overall, and there is a lot of interest in creating a community to keep taking this forward.
We’ll see how to do that

In the meantime see some pictures from the event over at agilesparks, thanks to Gil from Agilesparks for the photography!


Comments (1)

So what is the right ratio between developers and testers?

One of the questions I’m asked quite frequently is what is the right ratio between developers and testers.

A variant on that question is what I typically see in other organizations as the ratio.

Well lets answer the second variant and then try to deal with the first.

Typically what we see in agilesparks customers is 2:1 or 3:1. There are some exceptions of 3:2 or 5:1 but they are quite rare.

What is right? Well as u might expect it depends:
– what are the skills/strength of developers and testers. Not all engineers are made equal…
– how are the responsibilities spread between roles? Eg test automation etc.
– what is the development life cycle style used by the group
– what is the quality of the code when delivered to testers
– technology and character of the system. Usually the lower the product is in the stack the more testing it needs per code developed. This is due to the amount of impacted areas, the complexity to test, and the breadth of the configuration/platform matrix.
– how much test automation exists

One of the typical dynamics of a phased waterfall-like development lifecycle is that QA phase starts late and pressured and compromises in quality are part of life

This means very tough weeks/months for the poor testers which get a big blob of code to work on, they are outnumbered, usually outskilled and the following happens:
– the perception is that test is the bottleneck. ( well I would say that in waterfall each phase is a bottleneck. Those that tend to be the last ones just get the short end of the straw 😉
– either test phase is prolonged or developers are asked to help do testing. Or both.

But what also happens is that organizations get used to this. It’s a fact of life. For some reason the need to strengthen the test organization is usually outweighed by ability to develop more features each version.

Another thing is that developers do end up helping testers they usually do it in crisis mode when their only option is to help do the work, not help testers have an easier job the next time

Lets see what happens when such an organization moves to agile/kanban

In kanban or any kind of lifecycle that is feature driven developers and testers are expected to have more
Or less the same pace / feature velocity. So our typical outskilled outnumbered testers usually quickly appear as a bottleneck early in the transition to agile.

Limiting the WIP in test and Dev causes Dev to stall, leading to one of the classic discussions in kanban workshops and even some kanban games I wouldn’t mention to avoid spoiling the fun ( Carlos – we know you’re out there!)

In an upcoming post I will try to cover what can be done when this typical scenario happens, using practices from Agile Testing, the TOC five focusing steps, and agile engineering practices I general.

And we will try to think what is the right ratio for an agile environment.

Leave a Comment

Speaking at Lean Kanban 2010 Europe

Lean & Kanban 2010 Europe Speaker

I will be speaking in Lean Kanban 2010 in Belgium.

I’m excited about the agenda and connecting to the Lean/Kanban community in Europe.

It will also give me a chance to give a visit to my recent Kanban team in Utrecht and see how they are doing 🙂

Leave a Comment

Agile/Kanban interview on Reversim

I’ve been listening to podcasts for some years now.

reversim (רברס עם פלטפורמה) is a podcast by Ran and Ori, two kibutzniks talking about all things Software Engineering, in Hebrew.

I had the pleasure of having a chat with Ran and Ori a few weeks ago about Agile, Kanban, Agilesparks, Lean Startups, and some other things.

A very interesting discussion, if I may say so myself.

Go listen at Reversim 066 Agile and Kanban with Yuval Yeret from Agilesparks

The direct audio file is at reversim66_agile_kanban

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 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 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 …

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

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