Archive for July, 2009

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