Moving to yuvalyeret.com

Hey, I decided to take the plunge and move from wordpress.com to another wordpress host, where I can customize my blog some more and while at it have my own domain.
Since my name is quite unique, I was able to find a simple enough domain to occupy…

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.

Leave a Comment

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

Scrumban when will this be done

Dennis Stevens wrote a wonderful blog post called Kanban and when will this be done where he talks about how to forecast done dates in a kanban environment and how kanban looks at estimates, unperdictability, and how to make commitments.

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

Leave a Comment

Conference Videos from Agile Israel 2010

This year we videoed some of the sessions from Agile Israel 2010
The videos are on Vimeo.com. specifically my session was videoed, and for the first time I can see myself talking… strange experience…

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

Agile Project Management from AgileSparks Videos on Vimeo.

Leave a Comment

Older Posts »
Follow

Get every new post delivered to your Inbox.