I have spoken before about why I like Lean and why I like ScrumBan, a combination of Scrum and Kanban.
Some people prefer 'Kanban', as it is being called in the software development community.
Of course, what 'Kanban' is actually in the wild varies a lot.
So, here are my concerns about doing 'Kanban' alone, without Scrum. And I make some assumptions
about what Kanban is, and these assumptions may not be correct in many cases.
1. No upfront planning.
It is fine and correct to say that waterfall does too much upfront thinking. But this does not mean we should do zero upfront thinking.
In general people who do Scrum also advocate (as I do) some upfront planning before starting the first sprint. I call this Agile Release Planning, and have talked about specific techniques extensively. These are patterns that I use. Not always, but almost all the time.
In the wild, many Kanban people do not even do any Sprint Planning. Much less 'agile release planning'. Which I think is almost always sad. Yes, I can imagine a few odd cases where agile release planning is not necessary at all.
If the Team is doing purely maintenance work (bugs and small enhancements) and has ZERO work in backlog at the beginning of the Sprint, well then I guess there is no point in Sprint Planning. But I have never seen this situation. I have seen where a lot of the work for the Sprint will be defined later, as the high priority problems come in. So...minimal Sprint Planning might make sense.
People (the customers and the implementers, etc.) need to see the big picture. It affects creativity about designing the better solution, it affects motivation, and makes better able to address dependencies. But, we also must never again suffer the illusion that we have all the information upfront. That too is patently incorrectly.
2. No Team
Kanban in the wild does not require a Team concept. Certainly some people are involved, but how they are involved and whether they are a real, stable team is left totally open.
The Team concept, which involves many things (self-organization, etc, etc), is so important. And it needs to be a whole, real, stable team. By whole, we mean it must include the business side, as we usually call it. At least good people representing the 'customers' well. Inside the Team.
3. No Sprint.
Kanban is often played without any concept of a sprint. Although frequently people will say "we got 20 cards done in a week", which implies a 1 week sprint concept.
There are many many advantages to having a sprint. One is so that the Team and the people around the team can see productivity per Sprint (a measurement or feedback loop).
4. 'Scrum does not allow any changes to the Sprint Backlog'
This is a reason people give for using Kanban that is not correct.
First, it is true that Team productivity is getting killed by interruptions and whipsawing. So, we want to minimize disruptions. And the first, overly simplistic rule to get the 'kids' straightened out is: No changes to the Sprint Backlog.
But Scrum is not opposed to common sense. So, for example, inserting 2 SPs of 'bug' work (higher priority) to replace a 2SP story (lower priority) that has not been started -- this can be done. It should be explained to the Team why we are doing this. And the Team is not being asked to do a higher velocity than what they 'committed' to. And they get to re-commit to the new work too (eg, sometimes there are technical reasons why the 2 SP of bug work is not 'equal', this sprint at least, to the 2SP story).
So, this need to address to-be-identified-high-priority work is a false reason to switch to Kanban.
5. Dis-engagement from the Business
Kanban as played in the wild is often used to enable dis-engagement between Technology and the Business. Of course that does not have to be so, but it often is.
Often the Business side does not want to engage. The solution to this is not to give up, but to attack the issue, and 'force' them to engage. So, I am very discouraged when I see Kanban used this way. People seldom admit overtly this is the purpose, but it often is. IMO.
Scrum forces engagement, by making a business person (well, usually a business person) Product Owner of a real Team (and the PO is part of the Team). And then, if the PO is not engaged enough, that should become apparent quickly as an impediment, and hopefully fixed (if high enough in priority).
6. No Daily Scrum
Kanban in the wild often has nothing like a Daily Scrum.
All Lean teams do a short daily meeting (AFAIK). Why do 'Kanban' teams not do this? Well, they often say they don't want to stop 'continuous flow'. But then, still, everyone goes home at night and flow stops. Lean has a short daily meeting, because it helps the Team stay in sync, etc. And the stoppage 'cost' is repaid the same day by higher productivity.
So, I think the Daily Scrum adds a lot in enabling the Team to sync up, self-organize and self-manage. As a Team.
(Kanban does not require any Team concept. But sometimes it is played with a Team. So, a Daily Scrum would enable them to do a better job in collaborating, etc as a Team.)
One Team (and I think I believe they are a real Team) that uses Kanban does a kind of Daily Scrum every day at lunch. Still, I am thinking this is less effective than a regular Daily Scrum. If done professionally. Although, to be fair, many so-called Daily Scrums are...not really what they should be -- they are not done professionally.
7. No Sprint Review
Kanban in the wild is often played with no Sprint Review or Demo. AFAIK, Kanban does not require any demo.
Related to that, Scrum requires a Demo every Sprint. That includes the business stakeholders.
Now, in Kanban one could have demos. Ad-hoc. For example, of each 'card' when it completes.
But this is not nearly as good, usually, because the best people to give the best feedback are the business stakeholders. They are often fairly senior or at least very busy. So, it is better for them if, fairly far in advance, they can schedule that every two weeks (or every Sprint), they will come to the Demo (Sprint Review). This leads to better attendance and better feedback, based upon all the stories, seen together. 'The whole is greater than the sum of the parts.'
In Scrum one could still add additional feedback during the Sprint. For individual stories, as one example. There is no restriction on additional feedback.
8. No Retrospective
Kanban does not require any Retrospective.
Of course, something like a Retrospective could happen 'naturally'.
But from lots of experience, we think the odds of a regular and good retrospective go down considerably if there is no 'required' meeting to make it happen.
Again, to be fair, lots of 'scrum' Retrospectives are done in name only. And are not good or not very good. I want them not to call that kind of unprofessional work 'scrum'. But of course I cannot enforce that.
***
It is fine to add more Kanban ideas to Scrum. And specifically the Scrum board (which out-of-the-box is a basic Kanban board). And to focus on flow, pull, single-piece flow, minimizing WIP, etc. Excellent ideas.
And sometimes you can't get a Team to do all of Scrum. At first. So you start with Kanban. I totally understand. Getting people to change is hard. But as soon as you have that change made, start working on them to make some more change. And adding each part of Scrum, piece by piece.
Comments?
Some people prefer 'Kanban', as it is being called in the software development community.
Of course, what 'Kanban' is actually in the wild varies a lot.
So, here are my concerns about doing 'Kanban' alone, without Scrum. And I make some assumptions
about what Kanban is, and these assumptions may not be correct in many cases.
1. No upfront planning.
It is fine and correct to say that waterfall does too much upfront thinking. But this does not mean we should do zero upfront thinking.
In general people who do Scrum also advocate (as I do) some upfront planning before starting the first sprint. I call this Agile Release Planning, and have talked about specific techniques extensively. These are patterns that I use. Not always, but almost all the time.
In the wild, many Kanban people do not even do any Sprint Planning. Much less 'agile release planning'. Which I think is almost always sad. Yes, I can imagine a few odd cases where agile release planning is not necessary at all.
If the Team is doing purely maintenance work (bugs and small enhancements) and has ZERO work in backlog at the beginning of the Sprint, well then I guess there is no point in Sprint Planning. But I have never seen this situation. I have seen where a lot of the work for the Sprint will be defined later, as the high priority problems come in. So...minimal Sprint Planning might make sense.
People (the customers and the implementers, etc.) need to see the big picture. It affects creativity about designing the better solution, it affects motivation, and makes better able to address dependencies. But, we also must never again suffer the illusion that we have all the information upfront. That too is patently incorrectly.
2. No Team
Kanban in the wild does not require a Team concept. Certainly some people are involved, but how they are involved and whether they are a real, stable team is left totally open.
The Team concept, which involves many things (self-organization, etc, etc), is so important. And it needs to be a whole, real, stable team. By whole, we mean it must include the business side, as we usually call it. At least good people representing the 'customers' well. Inside the Team.
3. No Sprint.
Kanban is often played without any concept of a sprint. Although frequently people will say "we got 20 cards done in a week", which implies a 1 week sprint concept.
There are many many advantages to having a sprint. One is so that the Team and the people around the team can see productivity per Sprint (a measurement or feedback loop).
4. 'Scrum does not allow any changes to the Sprint Backlog'
This is a reason people give for using Kanban that is not correct.
First, it is true that Team productivity is getting killed by interruptions and whipsawing. So, we want to minimize disruptions. And the first, overly simplistic rule to get the 'kids' straightened out is: No changes to the Sprint Backlog.
But Scrum is not opposed to common sense. So, for example, inserting 2 SPs of 'bug' work (higher priority) to replace a 2SP story (lower priority) that has not been started -- this can be done. It should be explained to the Team why we are doing this. And the Team is not being asked to do a higher velocity than what they 'committed' to. And they get to re-commit to the new work too (eg, sometimes there are technical reasons why the 2 SP of bug work is not 'equal', this sprint at least, to the 2SP story).
So, this need to address to-be-identified-high-priority work is a false reason to switch to Kanban.
5. Dis-engagement from the Business
Kanban as played in the wild is often used to enable dis-engagement between Technology and the Business. Of course that does not have to be so, but it often is.
Often the Business side does not want to engage. The solution to this is not to give up, but to attack the issue, and 'force' them to engage. So, I am very discouraged when I see Kanban used this way. People seldom admit overtly this is the purpose, but it often is. IMO.
Scrum forces engagement, by making a business person (well, usually a business person) Product Owner of a real Team (and the PO is part of the Team). And then, if the PO is not engaged enough, that should become apparent quickly as an impediment, and hopefully fixed (if high enough in priority).
6. No Daily Scrum
Kanban in the wild often has nothing like a Daily Scrum.
All Lean teams do a short daily meeting (AFAIK). Why do 'Kanban' teams not do this? Well, they often say they don't want to stop 'continuous flow'. But then, still, everyone goes home at night and flow stops. Lean has a short daily meeting, because it helps the Team stay in sync, etc. And the stoppage 'cost' is repaid the same day by higher productivity.
So, I think the Daily Scrum adds a lot in enabling the Team to sync up, self-organize and self-manage. As a Team.
(Kanban does not require any Team concept. But sometimes it is played with a Team. So, a Daily Scrum would enable them to do a better job in collaborating, etc as a Team.)
One Team (and I think I believe they are a real Team) that uses Kanban does a kind of Daily Scrum every day at lunch. Still, I am thinking this is less effective than a regular Daily Scrum. If done professionally. Although, to be fair, many so-called Daily Scrums are...not really what they should be -- they are not done professionally.
7. No Sprint Review
Kanban in the wild is often played with no Sprint Review or Demo. AFAIK, Kanban does not require any demo.
Related to that, Scrum requires a Demo every Sprint. That includes the business stakeholders.
Now, in Kanban one could have demos. Ad-hoc. For example, of each 'card' when it completes.
But this is not nearly as good, usually, because the best people to give the best feedback are the business stakeholders. They are often fairly senior or at least very busy. So, it is better for them if, fairly far in advance, they can schedule that every two weeks (or every Sprint), they will come to the Demo (Sprint Review). This leads to better attendance and better feedback, based upon all the stories, seen together. 'The whole is greater than the sum of the parts.'
In Scrum one could still add additional feedback during the Sprint. For individual stories, as one example. There is no restriction on additional feedback.
8. No Retrospective
Kanban does not require any Retrospective.
Of course, something like a Retrospective could happen 'naturally'.
But from lots of experience, we think the odds of a regular and good retrospective go down considerably if there is no 'required' meeting to make it happen.
Again, to be fair, lots of 'scrum' Retrospectives are done in name only. And are not good or not very good. I want them not to call that kind of unprofessional work 'scrum'. But of course I cannot enforce that.
***
It is fine to add more Kanban ideas to Scrum. And specifically the Scrum board (which out-of-the-box is a basic Kanban board). And to focus on flow, pull, single-piece flow, minimizing WIP, etc. Excellent ideas.
And sometimes you can't get a Team to do all of Scrum. At first. So you start with Kanban. I totally understand. Getting people to change is hard. But as soon as you have that change made, start working on them to make some more change. And adding each part of Scrum, piece by piece.
Comments?
No comments:
Post a Comment