Archive for Uncategorized

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.

Advertisements

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

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

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!

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

Older Posts »