Having problems with message search?
Hi Ron, on Sat, Jun 20, 2009 at 9:28 PM you wrote:
I figured so :)
Yes ... I agree.
Once again I must have mis-communicated. I get the feeling that I leave an impression
that kanban is a process. It's not. It's a tool I use with my XP process.
It's a tool that helps me explicitly limit work in progress. That simple tool forces a significant and deep mindshift in an organization, though, and that's what gets me excited.
It's not my only tool. You know that I've been doing XP since 1999. I haven't abandoned XP. Kanban is just my latest tool in the bag. We still print xprogramming.com and your signature on our T-Shirts still! (thank you and your welcome :-)
I know there's a lot of rhetoric and theory floating around about kanban, but it's really nothing more than a tool to limit work in progress. period. nothing more. But when used at an individual task level with Scrum/XP teams, I'm finding it quite effective and keeping the flow by limiting individual's work in progress on stories.
The tool also helps move a team away from iterations and releases of arbitrarily set fixed lengths to delivering value when value is ready - an MMF. The primary purpose of iterations for me over the years has been to effectively track velocity and project release schedules. That has worked great for me and I still use iterations for the Kaizen aspects of the process. But I have abandoned iteration planning. Iterations are aribtrary. Tracking lead times on work and releasing work when it is ready is more effective in my experience (why wait until the end of an iteration or a release to deliver value?) Some organizations can't handle this *yet*. Others can. Since I've been in the Ruby on Rails world mostly, we're used to releasing multiple features in a day sometimes. Implement the feature, run the story tests. Looks good? "cap deploy" and it's out on the cloud. In that enviroment, Kanban has been a great tool.
Keep in mind that through all of this, I have not abandoned XP technical practices. TDD, pair programming, continuous integration, ...., releasing value when value is ready does not imply we've dropped practices. The XP practices that you, Ward, Kent, et. al. invented and popularized are just as important in a kanban scheduling system as in an iterative scheduling system.
so after those many paragraphs, are we all clear that to me, kanban is a tool, not a process and I don't compare it as either/or with Agile ? :)
Here's the difference that I see. Teams that are really new to XP/Scrum rarely estimate effectively. It takes time. But they struggle with trying to build that backlog and estimate like all the good books and consultants tell them to do. In the early iterations, it is very wasteful because they are not that good at it. It's a distraction for me as a coach to try to help them get good at estimating work for iterations and fit "just the right amount of work" to make a commitment to aribitrary timeboxes, especially in the early stages when they don't even have a velocity based on history. Kanban has allowed me to promote the technical practices that I learned from you in XP and remove the fear of working without estimates. If a team can't master these practices, I don't think they'll ever get good at estimating anyways.
And I'm finding a value stream map very valuable to help transform an organization. Before I used the value stream map as a tool, it was hard to visually show management where bottlenecks existed in their organization and how to eliminate bottlenecks by reducing WIP or increasing capacity. Because our scrum/xp board was just the development board (didn't show early analysis or back-end QA folks). It was always a gut-feel thing: "well, let's add another tester, let's slow down the rate of feature requests, etc.." that visual value stream is very powerful when you have that conversation with barely-technical executives.
Agreed. Kanban is just the Big Visible Chart of that petri net with WIP limits to guide you.
I'm not making any argument that Kanban is substantially different. That's the strawman that you keep throwing out there. It's apples to oranges, baby. How many times do I have to repeat that Kanban is not a process and I'm not comparing it to Agile. I'm kinda getting tired of repeating this message, frankly. Kanban is just a tool in my Agile/XP bag.
Keep in mind that this entire thread came about in my response to the original poster talking about doubling estimates and adding 10%. With all due respect, I feel like you keep strawmanning this argument back to a comparison between kanban and agile, which by now I hope you see that I think that is not. You could have just as easily replied to that poster with something like "don't pad estimates, use yesterday's weather" and we'd be saying just about the same thing.
Yes, it requires management to play by the rules. So does timeboxed iterations.
Yesterdays weather is akin to lead-time on classes of service (story types/estimates).
I've been pulling stories with XP teams for a while now. I've had similar experiences as you.
Those who didn't like it, in my observation were teams of low skill and motivation
(due to their culture) an their management didn't play by the rules. Those that liked it
seemed to be more advanced teams with a less dsyfunctional culture around them.
Why do you need iterations if you pull work and deliver value when value is ready?
From the outside observer, I'd say that I probably deliver similar results.
From the subtle, inside observer, a team member, there is something very relieving about eliminating the commitment to deliver value withing some aribitrary timeframe and the resulting stress and pressure to "meet that commitment when they underestimate". The end product results are similar, but kanban allows a team to remove that stress from their lives. I don't have any emperical data, but the less stressed a team is, the more productive they will be. Would you agree?
I'm betting and winning with it. So are other people. Step up your game and place a bet. :)
-- It has to be you. We all know that the written word communicates
> Sorry about recent miscommunication. Either I'm not doing a good job of
> communicating, or you are taking devil's advocate to the point that I'm
> calling it miscommuncation.
perfectly unless the reader screws up.
I figured so :)
Yes ...
> Lead times *ARE* your estimates. We still estimate using a kanban
> approach. Our estimates place work into Classes of Service - very similar
> in concept to the point system that I've grown to love over the years with
> XP. The effort is very similar, perhaps a bit less than XP points. It's
> all estimates at the end of the day.
Yes. I recommend using real velocity for estimates even in
> Lead time in a pure pull system is the equivalent of velocity in XP.
iteration-oriented situations.
It seems to me that iteration velocity, N stories per K weeks, is
just exactly the sum of the kanban velocity over the same K weeks.
Yes ... I agree.
I would also expect that a kanban team will do best if it already
understands and can execute practices like continuous integration
and automated testing. If not, then of course, the need will show up
as a bottleneck at those stations ... if the work is broken down so
as to make those stations, at least.
And, of course, an iteration team of similar sophistication to the
kanban team will also notice the same bottleneck. Especially since
practically every team I visit these days is using a kanban-style
task or story board.
Once again I must have mis-communicated. I get the feeling that I leave an impression
that kanban is a process. It's not. It's a tool I use with my XP process.
It's a tool that helps me explicitly limit work in progress. That simple tool forces a significant and deep mindshift in an organization, though, and that's what gets me excited.
It's not my only tool. You know that I've been doing XP since 1999. I haven't abandoned XP. Kanban is just my latest tool in the bag. We still print xprogramming.com and your signature on our T-Shirts still! (thank you and your welcome :-)
I know there's a lot of rhetoric and theory floating around about kanban, but it's really nothing more than a tool to limit work in progress. period. nothing more. But when used at an individual task level with Scrum/XP teams, I'm finding it quite effective and keeping the flow by limiting individual's work in progress on stories.
The tool also helps move a team away from iterations and releases of arbitrarily set fixed lengths to delivering value when value is ready - an MMF. The primary purpose of iterations for me over the years has been to effectively track velocity and project release schedules. That has worked great for me and I still use iterations for the Kaizen aspects of the process. But I have abandoned iteration planning. Iterations are aribtrary. Tracking lead times on work and releasing work when it is ready is more effective in my experience (why wait until the end of an iteration or a release to deliver value?) Some organizations can't handle this *yet*. Others can. Since I've been in the Ruby on Rails world mostly, we're used to releasing multiple features in a day sometimes. Implement the feature, run the story tests. Looks good? "cap deploy" and it's out on the cloud. In that enviroment, Kanban has been a great tool.
Keep in mind that through all of this, I have not abandoned XP technical practices. TDD, pair programming, continuous integration, ...., releasing value when value is ready does not imply we've dropped practices. The XP practices that you, Ward, Kent, et. al. invented and popularized are just as important in a kanban scheduling system as in an iterative scheduling system.
so after those many paragraphs, are we all clear that to me, kanban is a tool, not a process and I don't compare it as either/or with Agile ? :)
One thing that I don't see is why it'd make a big difference. All
> Kanban and XP point estimating are nearly similar except for the explicit
> limiting work in progress that kanban prescribes. When practicing XP/Scrum,
> we limited work in progress to a team decision ("are we ready to pull in
> another story?").
the decently-functioning teams I see already work on one story at a
time (per pair or whatever a good breakout is). None of them work on
more stories than they can swarm effectively. They work on the
stories in the iteration plan in priority order, pulling them into
"in process" only when ready. If they run out of stories they ask
for more. If they don't get done with some, they are the lowest
priority ones.
Here's the difference that I see. Teams that are really new to XP/Scrum rarely estimate effectively. It takes time. But they struggle with trying to build that backlog and estimate like all the good books and consultants tell them to do. In the early iterations, it is very wasteful because they are not that good at it. It's a distraction for me as a coach to try to help them get good at estimating work for iterations and fit "just the right amount of work" to make a commitment to aribitrary timeboxes, especially in the early stages when they don't even have a velocity based on history. Kanban has allowed me to promote the technical practices that I learned from you in XP and remove the fear of working without estimates. If a team can't master these practices, I don't think they'll ever get good at estimating anyways.
So, just based on what I've seen, observed, and reasoned about, I'd
expect the WIP limits to perhaps highlight bottlenecks more readily
but it isn't as if everyone doesn't already know they are blocked on
GUI or Test or whatever it is.
One thing that kanban clearly does focus on, as does Lean, is
extending the line up and down stream, so that more and more of the
value stream is visible.
And I'm finding a value stream map very valuable to help transform an organization. Before I used the value stream map as a tool, it was hard to visually show management where bottlenecks existed in their organization and how to eliminate bottlenecks by reducing WIP or increasing capacity. Because our scrum/xp board was just the development board (didn't show early analysis or back-end QA folks). It was always a gut-feel thing: "well, let's add another tester, let's slow down the rate of feature requests, etc.." that visual value stream is very powerful when you have that conversation with barely-technical executives.
But in the end, it seems to me, it's exactly the same Petri Net
either way.
Agreed. Kanban is just the Big Visible Chart of that petri net with WIP limits to guide you.
Doesn't mean I wouldn't do it or recommend it: I would. But the
arguments that it is somehow substantially different from Agile done
well are not convincing as yet. The comparisons to date sound to me
as if they are comparing kanban done well with agile done poorly.
Apples to apples, I'm not seeing that the math is really that
different.
I'm not making any argument that Kanban is substantially different. That's the strawman that you keep throwing out there. It's apples to oranges, baby. How many times do I have to repeat that Kanban is not a process and I'm not comparing it to Agile. I'm kinda getting tired of repeating this message, frankly. Kanban is just a tool in my Agile/XP bag.
Keep in mind that this entire thread came about in my response to the original poster talking about doubling estimates and adding 10%. With all due respect, I feel like you keep strawmanning this argument back to a comparison between kanban and agile, which by now I hope you see that I think that is not. You could have just as easily replied to that poster with something like "don't pad estimates, use yesterday's weather" and we'd be saying just about the same thing.
Mind you, I do see that it may be easier to detect bottlenecks, and
I'm open to the possibility (but not convinced) that it is harder
for management to apply undue pressure. The reason I'm not convinced
is that it apparently requires management to agree to play by the
kanban rules. If they will agree to that, then iteration proponents
should be allowed to assume that they'll agree to yesterday's
weather.
Yes, it requires management to play by the rules. So does timeboxed iterations.
Yesterdays weather is akin to lead-time on classes of service (story types/estimates).
Mind you, I have not as yet worked with a team doing pure kanban,
especially by the changing definition of today. I've worked with two
teams who pulled stories whenever they needed one, and one of them
liked it and one did not.
I've been pulling stories with XP teams for a while now. I've had similar experiences as you.
Those who didn't like it, in my observation were teams of low skill and motivation
(due to their culture) an their management didn't play by the rules. Those that liked it
seemed to be more advanced teams with a less dsyfunctional culture around them.
From a theoretical angle and I would like to think a rather
thoughtful one, I'd expect iterative with a prioritized iteration
plan to work like a digitization of kanban as seen from the outside
... and to work very similarly as seen from inside.
Why do you need iterations if you pull work and deliver value when value is ready?
As yet, I've been unable to read through the rhetoric and
proselytizing to get a theoretical sense. As for the practical side,
one success or a few tells us nothing. I am totally sure that a team
I coached, who did as I coached and as they figured out with that
coaching, would perform well whether kanbanning or iterating. I
believe that performance is about the team and their working
together far more than it is about the details of their process.
From the outside observer, I'd say that I probably deliver similar results.
From the subtle, inside observer, a team member, there is something very relieving about eliminating the commitment to deliver value withing some aribitrary timeframe and the resulting stress and pressure to "meet that commitment when they underestimate". The end product results are similar, but kanban allows a team to remove that stress from their lives. I don't have any emperical data, but the less stressed a team is, the more productive they will be. Would you agree?
I could, of course, be wrong. It's just not the way to bet. :)
I'm betting and winning with it. So are other people. Step up your game and place a bet. :)
John Goodsen RADSoft / Better Software Faster
jgoodsen@... Lean/Agile/XP/Scrum Coaching and Training
http://www.radsoft.com Ruby on Rails and Java Solutions
Offline 
Send Email