At a customers site, teams have been using Scrum for year or more (even the sales people run it 🙂 Developers are talented and motivated. In one team, increased visibility was needed, so I helped them convert to Kanban.
A second team took noticed on what went on, copied the Kanban board and started using it on their own.
So before, their sprint burndowns looked like this:
(atleast for the last three sprints)
Now this is a picture of the same team after two weeks of Kanban
Isn’t it a bit cool? 🙂
I don’t get it. Why was the burn down different when the team converted to Kanban?
I (believe) it is because they got better WiP transparency.
Hawthorne effect?
Not excluded of course 🙂 After all, this was just one sampling, so not scientifically reliable data yet.
Hi Mattias, I share with you a doubt I have about Kanban.
I know and I’ve seen in practice that scrum-but teams do not work well. What make a Kanban team different from a Scrum-But team ?
Same here?
What else did you do? Just because you changed the name of the process it does not make it better?
I’m intressted in how you used the burndown chart for Kanban? i love the BC but I haven’t found a good way to use it properly in my Kanban teams.
I guess a blog post follow up to explain the changes made. They weren’t many, just better flow and WiP visibility to the team.
What I found striking was that team ended up in this new situation without any active coaching. They just watched another team, copied the board and got going.
Observing them now, for the second week in a row, their new burndown has repeated.
> I don’t get it. Why was the burn down different when the team converted to Kanban?
Small WIP effect I think.
Which changes has the second team made to their process to consider this a conversion from SCRUM to Kanban? If they still have sprints and burn-down charts, why is it Kanban?
Thanks!
The team does estimation and daily standup pretty much Scrum like. So it is kind of a Hybrid right now.
What is changed is:
– limit work in progress continuously instead of sprint commitment
– burndown is towards release not sprint
– weekly Kaizen (continuous improvement) with root cause analysis and solving instead of sprint retro
Mattias, without knowing more about that specific team, I would argue that with a burndown like that for three consecutive sprints they where far from doing Scrum in the first place.
You could of course argue that they were not performing well as a Scrum team. Or as a team. Or that the interaction client/team was failing. It depends what view you take.
Mattias, without knowing more about the team I would argue that a team whose burndown looks that that for three consecutive sprints are not doing Scrum in the first place?
I think they aren’t solving their problems 🙂
Unfortunately, Scrum doesn’t help you with that. And this can be hard. You need a place to start. That is where Kanban provided use, it helped the team, Product Owner and Manager to agree on what issue to attack.