So from now, find me at http://yuvalyeret.com. I migrated the content from here, and will continue posting there from now on.

So long wordpress.com, its not you, its me.

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!

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.

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

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

I think its a great post, go read it!!!

After you’re done, try to think how it applies in a Scrumban environment, or more specifically, where the delivery is not continuous but scheduled in a sprint-like fashion.

As Cycle time is supposed to reflect start to finish, and finish usually means delivered, Cycle time in a sprint environment will include time waiting for the release/delivery event (E.g. every 2 weeks). So for example a story with 2 days cycle time to “ready to deliver” might have either a 3 days cycle time end to end, or 10 days cycle time end to end, depending on how long it waited to be delivered.

This means that the cycle time histogram used to create the T-Shirt sizes will not be very useful..

What should you do?

It probably makes sense to measure cycle time up to the release activity, and add the frequency of the release activity to the “when will this be released” forecast.

so for example our 2 day cycle time story, added to a 2w frequency of delivery will end up being a 16 day cycle time from first place in queue.

When looking at longer-term commitments this effect is diminished somewhat, especially if lead times are much longer than the cycle times and the delivery frequency.

Tools like LeanKit Kanban provide a way to define different levels of cycle times, which might come in handy for such situations.

There might be also some way to provide dynamic disneyland queues that take into account the fact that “next delivery cycle” might be 1 day ahead, or 10 days ahead. But I think this goes back into the land of planning what is going to fit before the next delivery cycle. And that is “Scrum Sprint Planning/Commitment” world, which is what we’re trying not to do here (but works in some environments…)

Anyhow check it out – hope you will find it interesting.

Agile Project Management from AgileSparks Videos on Vimeo.

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.

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…

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

and

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!