Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

kanbandev · Using the Kanban Method

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 2440
  • Category: Other
  • Founded: Aug 20, 2007
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 9064 - 9093 of 17647   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#9064 From: "emil_vikstrom" <ejmull@...>
Date: Thu Sep 30, 2010 9:58 pm
Subject: Circular Kanban: Exploring the Kanban Multiverse
emil_vikstrom
Send Email Send Email
 
Hi Karl

When I saw the picture of the circular Kanban board on your blog I immediately
remembered this very classical picture of iterative development with risk
management:
http://www.cs.colorado.edu/~kena/classes/5828/s07/lectures/04/spiral.png

It's going inside out but otherwise there are a few similarities =)

Emil

#9065 From: Eb <amaeze@...>
Date: Fri Oct 1, 2010 12:16 am
Subject: Re: [XP] Re: Is Kanban Agile?
amaeze77
Send Email Send Email
 
Then a start a thread that focuses on those questions.  Whether they can be used together is completely different from whether "Kanban is Agile".

On 09/30/2010 10:06 AM, Alan Baljeu wrote:
I don't remember where the thread began, but I'm looking at the title.  We've already established here that club membership is not worth pursuing.  So if the subject question has any point, it's found in delving into the details and answering my two questions below.
 
Alan Baljeu



From: Eb <amaeze@...>
To: kanbandev@yahoogroups.com
Cc: Alan Baljeu <alanbaljeu@...>
Sent: Thu, September 30, 2010 8:19:45 AM
Subject: Re: [kanbandev] [XP] Re: Is Kanban Agile?

On 09/30/2010 08:02 AM, Alan Baljeu wrote:


Kanban is not an axe, but a set of ideas and practices. The question is not whether I should use an axe or not. One question is whether I can use two tools together? A second question is, does my previous skill and understanding still apply, and how?   

Alan Baljeu


Legit questions but I'm not sure how they relate to the original thread.  Maybe a new discussion.
-- blog: http://eikonne.wordpress.com
twitter: http://twitter.com/eikonne



-- blog: http://eikonne.wordpress.com
twitter: http://twitter.com/eikonne

#9066 From: "PAUL" <beckfordp@...>
Date: Fri Oct 1, 2010 7:06 am
Subject: What is Kanban?
beckfordp...
Send Email Send Email
 
Hi Eb,

The questions Alan is asking are valid. I don't agree with Emil that labels
aren't important and we shouldn't codify methods. If you buy into the Dreyfus
model of learning then you'll accept that for novices and early beginners they
do need "best practice" and codified methods at least to begin with.

It is only later with practice and experience can we begin to throw away the
rules and the labels. Until then labels and rules are important.

Kanban is non prescriptive, which has an upside, you can experiment and apply it
in different ways and in different contexts. Fine for the expert, but daunting
for the novice. The novice is looking for guidance.

As a novice I believe the following questions are all valid:

1. What is Kanban?
2. Where does it fit in the methodology space (assuming that it is a
methodology)?
3. What Values does it build on and what principles if any?
4. Where should I use it and where not?
5. Are there different flavours, and where does each flavour apply?

I gave up looking for answers to these questions on this forum. I do intend to
use Kanban in the right context, based on my own answers to these questions, but
it would be nice if I had some definitive answers from the community as
guidance.

Instead, what I've seen here is a politicisation of a software approach with
respect to other approaches (like Scrum) and a focus on personalities (like Ken
Schwaber) rather then substance. In the meanwhile important questions go
unanswered.

The nearest I have had to answers is "we don't know yet", and "stop asking".

I don't believe Scrum is bad, or Agile is bad or Kanban is bad or Lean is bad.
They are just different things (I think?). It would be great to know how to
combine them, when, where, why etc.

After years of asking, in the end as a novice, I have come up with my own
answers. Will I mis-apply Kanban? Well from my reading of Davids book, no. But
to be honest as a novice I couldn't tell you.

Regards,

Paul.


--- In kanbandev@yahoogroups.com, Eb <amaeze@...> wrote:
>
> Then a start a thread that focuses on those questions.  Whether they can
> be used together is completely different from whether "Kanban is Agile".
>
> On 09/30/2010 10:06 AM, Alan Baljeu wrote:
> > I don't remember where the thread began, but I'm looking at the
> > title.  We've already established here that club membership is not
> > worth pursuing.  So if the subject question has any point, it's found
> > in delving into the details and answering my two questions below.
> > Alan Baljeu
> >
> >
> > ------------------------------------------------------------------------
> > *From:* Eb <amaeze@...>
> > *To:* kanbandev@yahoogroups.com
> > *Cc:* Alan Baljeu <alanbaljeu@...>
> > *Sent:* Thu, September 30, 2010 8:19:45 AM
> > *Subject:* Re: [kanbandev] [XP] Re: Is Kanban Agile?
> >
> > On 09/30/2010 08:02 AM, Alan Baljeu wrote:
> >>
> >>
> >> Kanban is not an axe, but a set of ideas and practices. The question
> >> is not whether I should use an axe or not. One question is whether I
> >> can use two tools together? A second question is, does my previous
> >> skill and understanding still apply, and how?
> >>
> >> Alan Baljeu
> >>
> >
> > Legit questions but I'm not sure how they relate to the original
> > thread.  Maybe a new discussion.
> > --
> > blog:http://eikonne.wordpress.com
> > twitter:http://twitter.com/eikonne
> >
>
>
> --
> blog: http://eikonne.wordpress.com
> twitter: http://twitter.com/eikonne
>

#9067 From: Eb <amaeze@...>
Date: Fri Oct 1, 2010 10:09 am
Subject: Re: What is Kanban?
amaeze77
Send Email Send Email
 
On 10/01/2010 03:06 AM, PAUL wrote:
>
>
>
>
>
> Hi Eb,
>
> The questions Alan is asking are valid. I don't agree with Emil that labels
aren't important and we shouldn't codify methods. If you buy into the Dreyfus
model of learning then you'll accept that for novices and early beginners they
do need "best practice" and codified methods at least to begin with.
>
> It is only later with practice and experience can we begin to throw away the
rules and the labels. Until then labels and rules are important.
>
> Kanban is non prescriptive, which has an upside, you can experiment and apply
it in different ways and in different contexts. Fine for the expert, but
daunting for the novice. The novice is looking for guidance.
>
> As a novice I believe the following questions are all valid:
>
> 1. What is Kanban?
> 2. Where does it fit in the methodology space (assuming that it is a
methodology)?
> 3. What Values does it build on and what principles if any?
> 4. Where should I use it and where not?
> 5. Are there different flavours, and where does each flavour apply?
>
> I gave up looking for answers to these questions on this forum. I do intend to
use Kanban in the right context, based on my own answers to these questions, but
it would be nice if I had some definitive answers from the community as
guidance.
>
> Instead, what I've seen here is a politicisation of a software approach with
respect to other approaches (like Scrum) and a focus on personalities (like Ken
Schwaber) rather then substance. In the meanwhile important questions go
unanswered.
>
> The nearest I have had to answers is "we don't know yet", and "stop asking".
>
> I don't believe Scrum is bad, or Agile is bad or Kanban is bad or Lean is bad.
They are just different things (I think?). It would be great to know how to
combine them, when, where, why etc.
>
> After years of asking, in the end as a novice, I have come up with my own
answers. Will I mis-apply Kanban? Well from my reading of Davids book, no. But
to be honest as a novice I couldn't tell you.
>
> Regards,
>
> Paul.
>

Hello Paul -

I never said the questions were invalid.  I just said that they were
IMO, a  different set of questions and a new thread should be started
that looks at the questions he posed.

I'll get back to this thread a little later.

Eb

--
blog: http://eikonne.wordpress.com
twitter: http://twitter.com/eikonne

#9068 From: Karl Scotland <kjscotland@...>
Date: Fri Oct 1, 2010 11:09 am
Subject: Re: What is Kanban?
kjscotland
Send Email Send Email
 
Hi Paul

On 1 October 2010 08:06, PAUL <beckfordp@...> wrote:

After years of asking, in the end as a novice, I have come up with my own answers. Will I mis-apply Kanban? Well from my reading of Davids book, no. But to be honest as a novice I couldn't tell you.

I'm curious. Do you think you would have understood better if you had been given the answers?

Karl

--
Karl Scotland
Lean & Agile Coach
http://www.availagility.co.uk/

#9069 From: "PAUL" <beckfordp@...>
Date: Fri Oct 1, 2010 11:19 am
Subject: Re: What is Kanban?
beckfordp...
Send Email Send Email
 
Hi Karl,

I don't want it to look like I'm picking on Kanban. Scrum IMHO suffers from a
similar problem. How does a novice apply it in practice?  What are the
pre-requisites? Do you need to marry it with other practices?  When should you
use it? Why? etc.

For me the only Agile methodology that provides sufficient guidance for the
novice is XP. XP goes further then just mere guidance, it actually suggests that
you find yourself a good Coach.

So for me yes, context specific guidance would be useful.

Thanks,

Paul.

--- In kanbandev@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:
>
> Hi Paul
>
> On 1 October 2010 08:06, PAUL <beckfordp@...> wrote:
>
> >
> > After years of asking, in the end as a novice, I have come up with my own
> > answers. Will I mis-apply Kanban? Well from my reading of Davids book, no.
> > But to be honest as a novice I couldn't tell you.
> >
>
> I'm curious. Do you think you would have understood better if you had been
> given the answers?
>
> Karl
>
> --
> Karl Scotland
> Lean & Agile Coach
> http://www.availagility.co.uk/
>

#9070 From: Sameh Zeid <sameh.zeid@...>
Date: Fri Oct 1, 2010 12:04 pm
Subject: Re: Re: What is Kanban?
samehsz
Send Email Send Email
 
When used as process management foundation, Flow Management using Kanban can help in recognizing improvement areas where best practices can be implemented.

IMHO

Sameh

On Fri, Oct 1, 2010 at 7:19 AM, PAUL <beckfordp@...> wrote:
 



Hi Karl,

I don't want it to look like I'm picking on Kanban. Scrum IMHO suffers from a similar problem. How does a novice apply it in practice? What are the pre-requisites? Do you need to marry it with other practices? When should you use it? Why? etc.

For me the only Agile methodology that provides sufficient guidance for the novice is XP. XP goes further then just mere guidance, it actually suggests that you find yourself a good Coach.

So for me yes, context specific guidance would be useful.

Thanks,

Paul.



--- In kanbandev@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:
>
> Hi Paul
>
> On 1 October 2010 08:06, PAUL <beckfordp@...> wrote:
>
> >
> > After years of asking, in the end as a novice, I have come up with my own
> > answers. Will I mis-apply Kanban? Well from my reading of Davids book, no.
> > But to be honest as a novice I couldn't tell you.
> >
>
> I'm curious. Do you think you would have understood better if you had been
> given the answers?
>
> Karl
>
> --
> Karl Scotland
> Lean & Agile Coach
> http://www.availagility.co.uk/
>




--
Sameh Zeid
Email: sameh.zeid@..., Phone: (226)444-1794
Twitter: @sameh_zeid
http://www.linkedin.com/in/samehzeid

#9071 From: Ged Byrne <ged.byrne@...>
Date: Fri Oct 1, 2010 12:59 pm
Subject: Re: What is Kanban?
gedb01
Send Email Send Email
 
Paul,

As another newcomer to Kanban I see it as something that like minded individuals can rally around.

I'm new to Kanban, but I've been applying the principles of Lean, Theory of Constraints and Flow to my software development for years.

When I read the Kanban book, it tied in with my own eperiences, goals and frustrations.

When I look at Claudio's Rise of the Lean Machine slides, I see a slide (39) that exactly matches my own bookshelf: http://www.slideshare.net/cperrone/the-rise-of-the-lean-machine
 
For years I've been doing this in isolation, and I'm hoping that Kanban allows me to find others who are looking for the same things in the same places.  It's great, after so many blank stares, to communicate with people who get it.

That's just my personal view, I'm new around here.

Hopefully, Kanban will become more.

Regards, 


Ged

As a novice I believe the following questions are all valid:

1. What is Kanban?
2. Where does it fit in the methodology space (assuming that it is a methodology)?
3. What Values does it build on and what principles if any?
4. Where should I use it and where not?
5. Are there different flavours, and where does each flavour apply?

I gave up looking for answers to these questions on this forum. I do intend to use Kanban in the right context, based on my own answers to these questions, but it would be nice if I had some definitive answers from the community as guidance.

Instead, what I've seen here is a politicisation of a software approach with respect to other approaches (like Scrum) and a focus on personalities (like Ken Schwaber) rather then substance. In the meanwhile important questions go unanswered.

The nearest I have had to answers is "we don't know yet", and "stop asking".


#9072 From: Joseph Hurtado <joseph@...>
Date: Fri Oct 1, 2010 12:36 pm
Subject: Re: What is Kanban?
trumpetflickr
Send Email Send Email
 
Short answer:
It's the mixed martial arts of Agile. 

A bit longer answer:
Kanban is the lightest Agile method available. Unlike other methods it can start with next to nothing in regards of process and tools, but through continous improvements it can lead to amazing results.
It only asks three things out of you: limit WIP, map flow, improve. 

Longer answer, wait till I get my coffee! LOL!

Joseph Hurtado
Sr. Project Manager
Toronto, Canada

PS. First post to the forum folks, glad I am finally participating. TGIF.   

Sent from my iPhone

On Oct 1, 2010, at 3:06 AM, "PAUL" <beckfordp@...> wrote:

 



Hi Eb,

The questions Alan is asking are valid. I don't agree with Emil that labels aren't important and we shouldn't codify methods. If you buy into the Dreyfus model of learning then you'll accept that for novices and early beginners they do need "best practice" and codified methods at least to begin with.

It is only later with practice and experience can we begin to throw away the rules and the labels. Until then labels and rules are important.

Kanban is non prescriptive, which has an upside, you can experiment and apply it in different ways and in different contexts. Fine for the expert, but daunting for the novice. The novice is looking for guidance.

As a novice I believe the following questions are all valid:

1. What is Kanban?
2. Where does it fit in the methodology space (assuming that it is a methodology)?
3. What Values does it build on and what principles if any?
4. Where should I use it and where not?
5. Are there different flavours, and where does each flavour apply?

I gave up looking for answers to these questions on this forum. I do intend to use Kanban in the right context, based on my own answers to these questions, but it would be nice if I had some definitive answers from the community as guidance.

Instead, what I've seen here is a politicisation of a software approach with respect to other approaches (like Scrum) and a focus on personalities (like Ken Schwaber) rather then substance. In the meanwhile important questions go unanswered.

The nearest I have had to answers is "we don't know yet", and "stop asking".

I don't believe Scrum is bad, or Agile is bad or Kanban is bad or Lean is bad. They are just different things (I think?). It would be great to know how to combine them, when, where, why etc.

After years of asking, in the end as a novice, I have come up with my own answers. Will I mis-apply Kanban? Well from my reading of Davids book, no. But to be honest as a novice I couldn't tell you.

Regards,

Paul.

--- In kanbandev@yahoogroups.com, Eb <amaeze@...> wrote:
>
> Then a start a thread that focuses on those questions. Whether they can
> be used together is completely different from whether "Kanban is Agile".
>
> On 09/30/2010 10:06 AM, Alan Baljeu wrote:
> > I don't remember where the thread began, but I'm looking at the
> > title. We've already established here that club membership is not
> > worth pursuing. So if the subject question has any point, it's found
> > in delving into the details and answering my two questions below.
> > Alan Baljeu
> >
> >
> > ----------------------------------------------------------
> > *From:* Eb <amaeze@...>
> > *To:* kanbandev@yahoogroups.com
> > *Cc:* Alan Baljeu <alanbaljeu@...>
> > *Sent:* Thu, September 30, 2010 8:19:45 AM
> > *Subject:* Re: [kanbandev] [XP] Re: Is Kanban Agile?
> >
> > On 09/30/2010 08:02 AM, Alan Baljeu wrote:
> >>
> >>
> >> Kanban is not an axe, but a set of ideas and practices. The question
> >> is not whether I should use an axe or not. One question is whether I
> >> can use two tools together? A second question is, does my previous
> >> skill and understanding still apply, and how?
> >>
> >> Alan Baljeu
> >>
> >
> > Legit questions but I'm not sure how they relate to the original
> > thread. Maybe a new discussion.
> > --
> > blog:http://eikonne.wordpress.com
> > twitter:http://twitter.com/eikonne
> >
>
>
> --
> blog: http://eikonne.wordpress.com
> twitter: http://twitter.com/eikonne
>


#9073 From: Karl Scotland <kjscotland@...>
Date: Fri Oct 1, 2010 1:17 pm
Subject: Re: Re: What is Kanban?
kjscotland
Send Email Send Email
 


On 1 October 2010 12:19, PAUL <beckfordp@...> wrote:

So for me yes, context specific guidance would be useful.

And therein lies the challenge. Every context is different.
What is the right level of abstraction to desctive the contexts?
What is the right level of abstraction to descrive the guidance? 

Karl

--
Karl Scotland
Lean & Agile Coach
http://www.availagility.co.uk/

#9074 From: John Goodsen <jgoodsen@...>
Date: Fri Oct 1, 2010 1:29 pm
Subject: Re: What is Kanban?
jgoodsen
Send Email Send Email
 


On Fri, Oct 1, 2010 at 8:36 AM, Joseph Hurtado <joseph@...> wrote:

Short answer:
It's the mixed martial arts of Agile. 

I look at it the other way around.  Agile is kinda the mixed martial arts of software development at the moment - and the fighters (us) come into the octagon with different backgrounds, training and techniques.  Kanban is but one of many several techniques we'll I need to apply when we're at work.  Using that analogy, Kanban seems to be my jui jitsu at the moment.  You need a solid ground game to succeed.

Buce Lee summed it up with his school of Jeet Kun Do, as "Absorb what is useful. Discard what is not."  It's a mindset that applies to all aspects of life, including software development.  

--
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@...            Lean/Kanban/XP/Scrum Coaching and Training
http://www.radsoft.com          Enterprise Ruby, Java and Scala Solutions

#9075 From: "PAUL" <beckfordp@...>
Date: Fri Oct 1, 2010 1:34 pm
Subject: Re: What is Kanban?
beckfordp...
Send Email Send Email
 
Hi Karl,

Have we seen no patterns? Can we say nothing other then experiment for yourself?
For example XP makes clear that it works best for small teams (7 plus or minus
2). It is also clear that it calls for organisational change with a reduction in
the number of roles and hand-offs. If you've got a large team and there is
resistance to radically changing the organisation, then clearly XP may not be
right for you.

Can't we say similar things about Kanban? I have answers of my own, but I'm
interested in yours.

Regards,

Paul.

--- In kanbandev@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:
>
> On 1 October 2010 12:19, PAUL <beckfordp@...> wrote:
>
> >
> > So for me yes, context specific guidance would be useful.
> >
>
> And therein lies the challenge. Every context is different.
> What is the right level of abstraction to desctive the contexts?
> What is the right level of abstraction to descrive the guidance?
>
> Karl
>
> --
> Karl Scotland
> Lean & Agile Coach
> http://www.availagility.co.uk/
>

#9076 From: "PAUL" <beckfordp@...>
Date: Fri Oct 1, 2010 1:38 pm
Subject: Re: What is Kanban?
beckfordp...
Send Email Send Email
 
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.

#9077 From: Ged Byrne <ged.byrne@...>
Date: Fri Oct 1, 2010 1:47 pm
Subject: Why we need Kanban
gedb01
Send Email Send Email
 
To assist with the ongoing conversations, here's a scenario that I believe demonstrates the need for Kanban.

The original XP Project was the Chrysler Comprehensive Compensation.  The project was eventually cancelled and Kent Beck summarises the reasons on the C2 wiki:


Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over. Or not, we'll see... if the people who tell you what to do don't agree with the people who evaluate what you are doing, you're stuffed, XP or no XP.

The example shows that XP, or any other method, is just not enough.  You can be stuffed XP or no XP.

The reason?  Because you're dependant upon you're value stream.  You're like a farmer who depends upon a river to water his crops.  If the water is damned up stream then no amount of skill will save the harvest.

With Kanban the Value Stream is mapped and visualised on the board.  If there are problems in the Value Stream, like the one above, it does not get masked.  Instead it is brought to every bodies attention because it feeds through to the board.

For example, consider the recent question about a work item that was ready for development, but then had to be pulled back to analysis.  That's a problem in the Value Stream, and it because a problem on the board.  http://finance.groups.yahoo.com/group/kanbandev/message/8990

This isn't intended to be a knock at XP, I'm just trying to ground the discussion with some specific examples.  I just trying to give an example where XP wasn't enough, something extra was needed, and that Kanban provides that extra something.

A method just isn't enough, regardless of what that method it is.  Things change and there has to be a process that allows people to see those changes and adapt to them.

Regards,


Ged

#9078 From: Karl Scotland <kjscotland@...>
Date: Fri Oct 1, 2010 2:01 pm
Subject: Re: Re: What is Kanban?
kjscotland
Send Email Send Email
 


On 1 October 2010 14:34, PAUL <beckfordp@...> wrote:

Can't we say similar things about Kanban? I have answers of my own, but I'm interested in yours.

I don't have answers - I've found they often lead to closed rather than open thinking - or worse, no thinking at all!

I do have a model I use to help people think.
1. System Thinking is core
2. Flow, Value and Capability are foundational concepts
3. Workflow, Visualisation, WIP, Cadence and Learning are aspects to be viewed from

I'm still learning myself how to use this model, and all models are wrong etc., but I do find it useful. 

Karl

--
Karl Scotland
Lean & Agile Coach
http://www.availagility.co.uk/

#9079 From: Eric Willeke <eric.willeke@...>
Date: Fri Oct 1, 2010 2:09 pm
Subject: Re: Re: What is Kanban?
erwilleke
Send Email Send Email
 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.


#9080 From: Robert Swanbum <rswany79@...>
Date: Fri Oct 1, 2010 2:25 pm
Subject: Re: Re: What is Kanban?
rswany79...
Send Email Send Email
 
As a novice, it's not that hard to pick up.  You really just have to participate in learning as you go.  Be open, be honest with what you are seeing and be strong enough to fight off the naysayers (there will be some).  I think if you keep your eye on the brass ring, understand the work flow and the effects of all the variables, then you will end up with a fine working Kanban system which produces positive results.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:09 AM

 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.


#9081 From: Eric Willeke <eric.willeke@...>
Date: Fri Oct 1, 2010 2:34 pm
Subject: Re: Re: What is Kanban?
erwilleke
Send Email Send Email
 
Are you a "software novice" or just "new to kanban"?
I'm assuming you're speaking from experience and not theory.

On Fri, Oct 1, 2010 at 7:25 AM, Robert Swanbum <rswany79@...> wrote:


As a novice, it's not that hard to pick up.  You really just have to participate in learning as you go.  Be open, be honest with what you are seeing and be strong enough to fight off the naysayers (there will be some).  I think if you keep your eye on the brass ring, understand the work flow and the effects of all the variables, then you will end up with a fine working Kanban system which produces positive results.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:09 AM


 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.





#9082 From: Robert Swanbum <rswany79@...>
Date: Fri Oct 1, 2010 2:44 pm
Subject: Re: Re: What is Kanban?
rswany79...
Send Email Send Email
 
Sort of both.  Our situation is a bit different than a true software dev group.  We are more of an app support group.  When I first got here 5 months ago they had just implemented a new service manager app and immediately had a backlog of 150+ requests from enhancements to bugs to data modifications in the app.  We decided to implement Kanban to handle the problem and it has been highly successful (up to this point anyways).  We did not have any exposure to Kanban prior to this except that the company I left had just implemented Kanban so I got a 10 min introduction to it before I left.  We researched the methodology (which actually led me to this forum) and dove right in.  I stated the other day that I've learned a lot just reading posts here and applying your experiences to ours.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:34 AM

 
Are you a "software novice" or just "new to kanban"?
I'm assuming you're speaking from experience and not theory.

On Fri, Oct 1, 2010 at 7:25 AM, Robert Swanbum <rswany79@...> wrote:


As a novice, it's not that hard to pick up.  You really just have to participate in learning as you go.  Be open, be honest with what you are seeing and be strong enough to fight off the naysayers (there will be some).  I think if you keep your eye on the brass ring, understand the work flow and the effects of all the variables, then you will end up with a fine working Kanban system which produces positive results.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:09 AM


 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.





#9083 From: Robert Swanbum <rswany79@...>
Date: Fri Oct 1, 2010 2:47 pm
Subject: Re: Re: What is Kanban?
rswany79...
Send Email Send Email
 
Forgot to mention, I do have quite a bit of experience in Six Sigma, Balanced Scorecarding and stuff like that so from a managerial process perspective pehaps I grabbed onto Kanban a bit easier than someone who may not have that experience.

--- On Fri, 10/1/10, Robert Swanbum <rswany79@...> wrote:

From: Robert Swanbum <rswany79@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:44 AM

 
Sort of both.  Our situation is a bit different than a true software dev group.  We are more of an app support group.  When I first got here 5 months ago they had just implemented a new service manager app and immediately had a backlog of 150+ requests from enhancements to bugs to data modifications in the app.  We decided to implement Kanban to handle the problem and it has been highly successful (up to this point anyways).  We did not have any exposure to Kanban prior to this except that the company I left had just implemented Kanban so I got a 10 min introduction to it before I left.  We researched the methodology (which actually led me to this forum) and dove right in.  I stated the other day that I've learned a lot just reading posts here and applying your experiences to ours.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:34 AM

 
Are you a "software novice" or just "new to kanban"?
I'm assuming you're speaking from experience and not theory.

On Fri, Oct 1, 2010 at 7:25 AM, Robert Swanbum <rswany79@...> wrote:


As a novice, it's not that hard to pick up.  You really just have to participate in learning as you go.  Be open, be honest with what you are seeing and be strong enough to fight off the naysayers (there will be some).  I think if you keep your eye on the brass ring, understand the work flow and the effects of all the variables, then you will end up with a fine working Kanban system which produces positive results.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:09 AM


 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.





#9084 From: Joseph Hurtado <joseph@...>
Date: Fri Oct 1, 2010 2:47 pm
Subject: Re: What is Kanban?
trumpetflickr
Send Email Send Email
 
Good point John, I almost said it was Jiu Jitsu, but then realized not really. 

I do think it's MMA because it welcomes best practices from any other Method. IMHO Scrum does not, XP does not. But knowing Kanban and XP or Scrum will make you a better Kanban Sensei. 

You will pick and choose what's best for Kaizen, flow and overall value for the people and the organization. 

Cheers,

Joseph Hurtaado
Sr. Project Manager
Toronto, Canada

PS. I had my coffee. 

Sent from my iPhone

On Oct 1, 2010, at 9:29 AM, John Goodsen <jgoodsen@...> wrote:

 



On Fri, Oct 1, 2010 at 8:36 AM, Joseph Hurtado <joseph@...> wrote:

Short answer:
It's the mixed martial arts of Agile. 

I look at it the other way around.  Agile is kinda the mixed martial arts of software development at the moment - and the fighters (us) come into the octagon with different backgrounds, training and techniques.  Kanban is but one of many several techniques we'll I need to apply when we're at work.  Using that analogy, Kanban seems to be my jui jitsu at the moment.  You need a solid ground game to succeed.

Buce Lee summed it up with his school of Jeet Kun Do, as "Absorb what is useful. Discard what is not."  It's a mindset that applies to all aspects of life, including software development.  

--
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@...            Lean/Kanban/XP/Scrum Coaching and Training
http://www.radsoft.com          Enterprise Ruby, Java and Scala Solutions


#9085 From: Eric Willeke <eric.willeke@...>
Date: Fri Oct 1, 2010 2:47 pm
Subject: Re: Re: What is Kanban?
erwilleke
Send Email Send Email
 
Robert, this is very nice!
Would you be willing to write up your experience, findings, and such as a 1-2 page and submit it to myself and Karl to put on LWS?


On Fri, Oct 1, 2010 at 7:44 AM, Robert Swanbum <rswany79@...> wrote:


Sort of both.  Our situation is a bit different than a true software dev group.  We are more of an app support group.  When I first got here 5 months ago they had just implemented a new service manager app and immediately had a backlog of 150+ requests from enhancements to bugs to data modifications in the app.  We decided to implement Kanban to handle the problem and it has been highly successful (up to this point anyways).  We did not have any exposure to Kanban prior to this except that the company I left had just implemented Kanban so I got a 10 min introduction to it before I left.  We researched the methodology (which actually led me to this forum) and dove right in.  I stated the other day that I've learned a lot just reading posts here and applying your experiences to ours.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:34 AM


 
Are you a "software novice" or just "new to kanban"?
I'm assuming you're speaking from experience and not theory.

On Fri, Oct 1, 2010 at 7:25 AM, Robert Swanbum <rswany79@...> wrote:


As a novice, it's not that hard to pick up.  You really just have to participate in learning as you go.  Be open, be honest with what you are seeing and be strong enough to fight off the naysayers (there will be some).  I think if you keep your eye on the brass ring, understand the work flow and the effects of all the variables, then you will end up with a fine working Kanban system which produces positive results.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:09 AM


 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.








#9086 From: Robert Swanbum <rswany79@...>
Date: Fri Oct 1, 2010 2:50 pm
Subject: Re: Re: What is Kanban?
rswany79...
Send Email Send Email
 
Yes, I planned on documenting the whole experience once I felt we were truely at a mature stage. 
 
What is LWS?

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:47 AM

 
Robert, this is very nice!
Would you be willing to write up your experience, findings, and such as a 1-2 page and submit it to myself and Karl to put on LWS?


On Fri, Oct 1, 2010 at 7:44 AM, Robert Swanbum <rswany79@...> wrote:


Sort of both.  Our situation is a bit different than a true software dev group.  We are more of an app support group.  When I first got here 5 months ago they had just implemented a new service manager app and immediately had a backlog of 150+ requests from enhancements to bugs to data modifications in the app.  We decided to implement Kanban to handle the problem and it has been highly successful (up to this point anyways).  We did not have any exposure to Kanban prior to this except that the company I left had just implemented Kanban so I got a 10 min introduction to it before I left.  We researched the methodology (which actually led me to this forum) and dove right in.  I stated the other day that I've learned a lot just reading posts here and applying your experiences to ours.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:34 AM


 
Are you a "software novice" or just "new to kanban"?
I'm assuming you're speaking from experience and not theory.

On Fri, Oct 1, 2010 at 7:25 AM, Robert Swanbum <rswany79@...> wrote:


As a novice, it's not that hard to pick up.  You really just have to participate in learning as you go.  Be open, be honest with what you are seeing and be strong enough to fight off the naysayers (there will be some).  I think if you keep your eye on the brass ring, understand the work flow and the effects of all the variables, then you will end up with a fine working Kanban system which produces positive results.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:09 AM


 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.








#9087 From: Eric Willeke <eric.willeke@...>
Date: Fri Oct 1, 2010 3:41 pm
Subject: Re: Re: What is Kanban?
erwilleke
Send Email Send Email
 
http://www.limitedwipsociety.org/

De facto home of case studies, local meet ups, etc.

As I looked, I find our tag cloud amusing - is focus one of our principles? :)


On Fri, Oct 1, 2010 at 7:50 AM, Robert Swanbum <rswany79@...> wrote:


Yes, I planned on documenting the whole experience once I felt we were truely at a mature stage. 
 
What is LWS?


--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:47 AM


 
Robert, this is very nice!
Would you be willing to write up your experience, findings, and such as a 1-2 page and submit it to myself and Karl to put on LWS?


On Fri, Oct 1, 2010 at 7:44 AM, Robert Swanbum <rswany79@...> wrote:


Sort of both.  Our situation is a bit different than a true software dev group.  We are more of an app support group.  When I first got here 5 months ago they had just implemented a new service manager app and immediately had a backlog of 150+ requests from enhancements to bugs to data modifications in the app.  We decided to implement Kanban to handle the problem and it has been highly successful (up to this point anyways).  We did not have any exposure to Kanban prior to this except that the company I left had just implemented Kanban so I got a 10 min introduction to it before I left.  We researched the methodology (which actually led me to this forum) and dove right in.  I stated the other day that I've learned a lot just reading posts here and applying your experiences to ours.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:34 AM


 
Are you a "software novice" or just "new to kanban"?
I'm assuming you're speaking from experience and not theory.

On Fri, Oct 1, 2010 at 7:25 AM, Robert Swanbum <rswany79@...> wrote:


As a novice, it's not that hard to pick up.  You really just have to participate in learning as you go.  Be open, be honest with what you are seeing and be strong enough to fight off the naysayers (there will be some).  I think if you keep your eye on the brass ring, understand the work flow and the effects of all the variables, then you will end up with a fine working Kanban system which produces positive results.

--- On Fri, 10/1/10, Eric Willeke <eric.willeke@...> wrote:

From: Eric Willeke <eric.willeke@...>
Subject: Re: [kanbandev] Re: What is Kanban?
To: kanbandev@yahoogroups.com
Date: Friday, October 1, 2010, 9:09 AM


 
Let me ask a different question:
"Do we believe novices should be trying kanban in isolation?"

I used to think "of course", but lately I've started changing my mind. I have no concerns about the ability of experienced software leaders and practitioners from most any background trying to do so.  "Focus on Quality", "Reduce Work in Progress", "Deliver Often", "Balance Demand against Throughput", "Prioritize", "Attack .. Variability" (Anderson, 2010). Those steps taking as a single large batch are daunting to understand and incredibly hard to implement. Individually and in the right order they're quite easy to understand, and reasonably straight-forward to implement. 

Do I see a team of guys right out of college being successful with this? Not without a LOT of research and practice to understand what we mean by quality, trusting what goes wrong when you multi-task a team too much, fail to deliver, etc. There's a _HUGE_ difference between "novice at software" and "new to Kanban". 

So, going back to Paul's question, I don't believe we should offer prescriptive guidance to novices. We have plenty of examples out there for people to draw on as they follow the recipe.  The one thing we ought to be more clear on is that we're not _excluding_ anything... all of agile's practices are fair game if you need them (and most you should adopt), as are all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and explore as you strive to achieve the goal. 

Paul, what do you think?


On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
Hi John,

> "Absorb what is
> useful. Discard what is not."

Agreed. This is a big ask for a novice though :)

Paul.











#9088 From: "PAUL" <beckfordp@...>
Date: Fri Oct 1, 2010 5:15 pm
Subject: Re: What is Kanban?
beckfordp...
Send Email Send Email
 
Hi Eric,

I think you're on the money!


> Let me ask a different question:
> "Do we believe novices should be trying kanban in isolation?"

> There's a _HUGE_ difference between "novice at software"
> and "new to Kanban".

I'm definitely not a novice at software. I also have a lot of experience of
processes and process improvement. From this I have had a good stab at deciding
where Kanban fits into my toolbox. Intuitively I think I'm not far off.

I am a novice at Kanban, but my expertise in other things should see me through
(I hope) :)
>
> So, going back to Paul's question, I don't believe we should offer
> prescriptive guidance to novices. We have plenty of examples out there for
> people to draw on as they follow the recipe.  The one thing we ought to be
> more clear on is that we're not _excluding_ anything... all of agile's
> practices are fair game if you need them (and most you should adopt), as are
> all of PMI's, CMMI's, Lean, etc, etc, etc... use what makes sense and
> explore as you strive to achieve the goal.
>
> Paul, what do you think?
>

Not excluding is different from knowing the right recipe. My concern from the
beginning is for people whose only ingredient is Kanban and/or Lean Software
Development. If you bake a cake with too much flower and not enough eggs it's
not going to come out right, and it takes a lot of experience to work out the
right mixture just by taste.

This is where the guidance is needed I think. Kanban is just one ingredient,
novices need to know the full recipe for at least one type of cake. Perhaps two
or three archetypal cake recipes would be nice as a starting place. They can
then move forward with confidence knowing that if they stick to the recipe they
won't go far wrong.

(BTW there are recipes out there. Jim Shores XP derived one piece flow comes to
mind, Davids case studies on bug fixing and maintenance, numerous support
examples, Scrumban etc - These are all different IMHO and we should be
cataloging them as patterns).

Paul.
>
> On Fri, Oct 1, 2010 at 6:38 AM, PAUL <beckfordp@...> wrote:
>
> > Hi John,
> >
> > > "Absorb what is
> > > useful. Discard what is not."
> >
> > Agreed. This is a big ask for a novice though :)
> >
> > Paul.
> >
> >
>

#9089 From: John Goodsen <jgoodsen@...>
Date: Fri Oct 1, 2010 5:32 pm
Subject: Re: Re: What is Kanban?
jgoodsen
Send Email Send Email
 
On Fri, Oct 1, 2010 at 9:38 AM, PAUL <beckfordp@...> wrote:
> Hi John,
>
>> "Absorb what is
>> useful. Discard what is not."
>
> Agreed. This is a big ask for a novice though :)
>

That's where the Shu Ha Ri model comes into play.  When you are Shu,
you cannot discard. You need to get somewhere around Ha and Ri before
you get to discard.  That's how a Jeet Kun Do school works too.  You
are there to learn and practice, not to discard.

--
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@...            Lean/Kanban/XP/Scrum Coaching and Training
http://www.radsoft.com          Enterprise Ruby, Java and Scala Solutions

#9090 From: Eric Willeke <eric.willeke@...>
Date: Fri Oct 1, 2010 5:45 pm
Subject: Re: Re: What is Kanban?
erwilleke
Send Email Send Email
 
A different question:

Is kanban a good idea for a young team making its first move from chaos -> [Agile/lean/defined process/whatever] in the absence of a coach or team member with lots of previous process experience?

#9091 From: Alan Baljeu <alanbaljeu@...>
Date: Sat Sep 25, 2010 12:13 pm
Subject: Re: MMF-driven Kanban Sprints
alanbaljeu
Send Email Send Email
 
If sprint interval equals the mean MMF size, then half the sprints will fail to meet objectives. If sprint interval equals the 80th percentile MMF, 20% will fail. But 75% will have downtime. A large percentage will finish very early.   How do you handle missed deadlines?  How do you handle slack?

If on the other hand a sprint is unconstrained, are there problems?
 

Alan Baljeu

On 2010-09-25, at 1:57 AM, Yuval Yeret <yuval@...> wrote:

 

Thanks Troy
My scrum and kanban roots are indeed struggling around this question... :-)
I would maybe refine it to say that the sprint due date should be based on historical cycle time for MMF. In case of external customer delivery which requires a more careful but aggressive due date, ca. Use estimation on the stories as well. 

The more I think about it, the fact that there is a sprint cfd tracking to a certain date is going to help a lot even if that date is not a commitment but just the predicted performance of the team. 

Now to add more complication - what would happen if we use TOC style sprint buffer? Half taken off for savings. Half as buffer at end of sprint? ( eg simply by taking the average cycle time not the safer one STD dev up) would it encourage the right behavior or the wrong one? 
The balance between slack in the system and energized pace is a hard one isn't it. 


--
Yuval


On Sep 24, 2010, at 22:56, Troy Tuttle <TroyLTuttle@...> wrote:

 

I subscribe to the idea of replacing sprint boundries with the more customer-centric boundries of an MMF.  I like where you're headed with this approach, and just wanted to offer a comment on one of your questions in your post:
"What is the length of this MMF-based sprint? Is it pre-determined using Estimation/Commitment? Does it emerge as the stories are completed and progress is made?"

I think the length should depend on the size of the current MMF.  You could define a specific length, but I think you lose the advantages of a vessel that is shaped by a customer expression of value.  Depending on the context, the MMF's may or may not be relatively close in size, and I'm usually ok with that.  I choose to error on the side of keeping customer requirements distortion free (from artificial process constraints).  

I definitely prefer to establish MMF SLA's based on metrics rather than estimation/commitment.  

Troy Tuttle 

My profiles: LinkedIn Twitter Blogger



On Fri, Sep 24, 2010 at 9:00 AM, yuvalyeret <yuval@...> wrote:
 

Hi everyone,
With a lot of the community in Antwerp enjoying what seems to be a great conference (at least based on twits...), I had to stay home, which was a bummer, but OTOH gave me some time to think and write a bit.

Elad Amit (a colleague in Agilesparks) and I have been thinking recently about introducing some more structure into the Kanban implementations we are doing with clients. While we started with Scrumban for some situations, fixed length sprints quickly wear out a true Kanban approach. OTOH more and more signs in the field and in the community pointed to using something like the MMF as a boundary object between the team and its stakeholders, and hold Cadence, tracking, and commitment discussions around it.

I started to write up our discussion about it at http://yuvalyeret.com/2010/09/24/mmf-driven-sprints-in-a-kanban-world/

We would love to hear what other practitioners have to say about it. In the meanwhile we are trying it in the field, and will continue to write up some more details we already discussed, and those that will emerge (in a true agile fashion...)

One key aspect is strengthening the metrics/status that is provided on a feature level around Kanban boards - which was discussed a couple of weeks ago on the list (http://finance.groups.yahoo.com/group/kanbandev/message/8796). I suspect this will be one of the first posts I get to...


Recent Activity:
Yahoo! Groups
Switch to: Text-Only, Daily Digest • Unsubscribe •


#9092 From: Yuval Yeret <yuval@...>
Date: Sat Oct 2, 2010 6:01 am
Subject: Re: MMF-driven Kanban Sprints
yuvalyeret
Send Email Send Email
 
Alan,
Those are key questions around this subject, and we haven't thought them through yet, although we have some thoughts. 

I would say that unless your MMFs have very low variance in size, you need to estimate the MMF size to set the sprint length accordingly. In many environments this will make sense, since someone is waiting for this MMF anyhow. Even if not, estimating at the MMF level allows you to have a good scope to fit discussion with the Product Owner/Manager to align expectations of cost versus scope (I'm not talking about Arlo's Naked Planning here...)

STILL this estimation is only a ballpark. I don't expect team to break everything into smaller stories, tasks and estimate them in detail, unless there's a strong commitment required for this MMF. 
So you will still see some failure. some downtime. 

For the downtime - If its minor, its a good slack to work on improving the system and getting rid of accumulated debt. If its major, you can cut the sprint length. 
For missed deadlines - its the classic conflict between having some clear goal that drives you to converge, and avoiding the strict goal that drives you to use the magic "reduce quality" button. One idea I was entertaining was to revise the sprint finish line once you are at the 70-80% mark. If by that time you think you will be late - you go into the room, do a retrospective, find out what you can fix, whether you will do feature thinning, find ways to swarm and meet the time, or extend the timeline. 
If by that time you see you are ahead - congratulations, you can either cut the sprint short, use the time for technical debt / 20% time, or start the next MMF. 

Again, if it wasn't clear, we are talking about variable length sprints, and in some cases multiple such sprints running in parallel if the team cannot swarm effectively to one MMF. 

There are challenges with this way of working, both from the technical perspective, as well as from the cadence mindset perspective, but it seems like a worthy experiment :-)




On Sat, Sep 25, 2010 at 2:13 PM, Alan Baljeu <alanbaljeu@...> wrote:
 

If sprint interval equals the mean MMF size, then half the sprints will fail to meet objectives. If sprint interval equals the 80th percentile MMF, 20% will fail. But 75% will have downtime. A large percentage will finish very early.   How do you handle missed deadlines?  How do you handle slack?

If on the other hand a sprint is unconstrained, are there problems?
 

Alan Baljeu

On 2010-09-25, at 1:57 AM, Yuval Yeret <yuval@...> wrote:

 

Thanks Troy
My scrum and kanban roots are indeed struggling around this question... :-)
I would maybe refine it to say that the sprint due date should be based on historical cycle time for MMF. In case of external customer delivery which requires a more careful but aggressive due date, ca. Use estimation on the stories as well. 

The more I think about it, the fact that there is a sprint cfd tracking to a certain date is going to help a lot even if that date is not a commitment but just the predicted performance of the team. 

Now to add more complication - what would happen if we use TOC style sprint buffer? Half taken off for savings. Half as buffer at end of sprint? ( eg simply by taking the average cycle time not the safer one STD dev up) would it encourage the right behavior or the wrong one? 
The balance between slack in the system and energized pace is a hard one isn't it. 


--
Yuval


On Sep 24, 2010, at 22:56, Troy Tuttle <TroyLTuttle@...> wrote:

 

I subscribe to the idea of replacing sprint boundries with the more customer-centric boundries of an MMF.  I like where you're headed with this approach, and just wanted to offer a comment on one of your questions in your post:
"What is the length of this MMF-based sprint? Is it pre-determined using Estimation/Commitment? Does it emerge as the stories are completed and progress is made?"

I think the length should depend on the size of the current MMF.  You could define a specific length, but I think you lose the advantages of a vessel that is shaped by a customer expression of value.  Depending on the context, the MMF's may or may not be relatively close in size, and I'm usually ok with that.  I choose to error on the side of keeping customer requirements distortion free (from artificial process constraints).  

I definitely prefer to establish MMF SLA's based on metrics rather than estimation/commitment.  

Troy Tuttle 

My profiles: LinkedIn Twitter Blogger



On Fri, Sep 24, 2010 at 9:00 AM, yuvalyeret <yuval@...> wrote:
 

Hi everyone,
With a lot of the community in Antwerp enjoying what seems to be a great conference (at least based on twits...), I had to stay home, which was a bummer, but OTOH gave me some time to think and write a bit.

Elad Amit (a colleague in Agilesparks) and I have been thinking recently about introducing some more structure into the Kanban implementations we are doing with clients. While we started with Scrumban for some situations, fixed length sprints quickly wear out a true Kanban approach. OTOH more and more signs in the field and in the community pointed to using something like the MMF as a boundary object between the team and its stakeholders, and hold Cadence, tracking, and commitment discussions around it.

I started to write up our discussion about it at http://yuvalyeret.com/2010/09/24/mmf-driven-sprints-in-a-kanban-world/

We would love to hear what other practitioners have to say about it. In the meanwhile we are trying it in the field, and will continue to write up some more details we already discussed, and those that will emerge (in a true agile fashion...)

One key aspect is strengthening the metrics/status that is provided on a feature level around Kanban boards - which was discussed a couple of weeks ago on the list (http://finance.groups.yahoo.com/group/kanbandev/message/8796). I suspect this will be one of the first posts I get to...


Recent Activity:
Yahoo! Groups
Switch to: Text-Only, Daily DigestUnsubscribe



#9093 From: "PAUL" <beckfordp@...>
Date: Sat Oct 2, 2010 6:29 am
Subject: Re: Why we need Kanban
beckfordp...
Send Email Send Email
 
Hi Ged,

This response explains precisely why we need a structured taxonomy. Value stream
mapping can be used with Scrum, XP or any Agile method. Kanban at the
organisational level can be used, without impacting the process of the
development team.

So using this concrete example. The organisation could have applied value stream
mapping and Kanban outside the development team, and the development team could
have carried on using XP.

Do we now call the whole process Kanban, or do we now have an XP team working in
a value stream that is managed using kanban?

In fact is Kanban the most significant feature of the way they are working?
Marry Poppendiek presents Lean Software development as a toolbox of practices
inspired from Lean Manufacturing and design. At this level you can mix and match
practices and introduce them into any methodology you like.

Kanban is packaged somewhat differently, as a System. Giving the impression that
it is a group of practices that should be used together collectively. If this is
so then it is natural to ask what is this group?


My answer is to say that there is no group, and to un-bundle the practices. So
Value stream mapping is valuable in its own right, so is kanban, so are WIP
limits, so is ToC.

So for me Kanban is not a methodology or a system it is simply a tool (or set of
tools). I'm sure others here will disagree, hence the confusion.

Paul.

--- In kanbandev@yahoogroups.com, Ged Byrne <ged.byrne@...> wrote:
>
> To assist with the ongoing conversations, here's a scenario that I believe
> demonstrates the need for Kanban.
>
> The original XP Project was the Chrysler Comprehensive Compensation.  The
> project was eventually cancelled and Kent Beck summarises the reasons on the
> C2 wiki:
>
>
> Near as I can tell the fundamental problem was that the
> GoldOwner<http://www.c2.com/cgi/wiki?GoldOwner>
>  and GoalDonor <http://www.c2.com/cgi/wiki?GoalDonor> weren't the same. The
> customer feeding stories to the team didn't care about the same things as
> the managers evaluating the team's performance. This is bad, and we know
> it's bad, but it was masked early because we happened to have a customer who
> was precisely aligned with the IT managers. The new customers who came on
> wanted tweaks to the existing system more than they wanted to turn off the
> next mainframe payroll system. IT management wanted to turn off the next
> mainframe payroll system. Game over. Or not, we'll see... if the people who
> tell you what to do don't agree with the people who evaluate what you are
> doing, you're stuffed, XP or no XP.
> http://www.c2.com/cgi/wiki?CthreeProjectTerminated
>
> The example shows that XP, or any other method, is just not enough.  You can
> be stuffed XP or no XP.
>
> The reason?  Because you're dependant upon you're value stream.  You're like
> a farmer who depends upon a river to water his crops.  If the water is
> damned up stream then no amount of skill will save the harvest.
>
> With Kanban the Value Stream is mapped and visualised on the board.  If
> there are problems in the Value Stream, like the one above, it does not get
> masked.  Instead it is brought to every bodies attention because it feeds
> through to the board.
>
> For example, consider the recent question about a work item that was ready
> for development, but then had to be pulled back to analysis.  That's a
> problem in the Value Stream, and it because a problem on the board.
> http://finance.groups.yahoo.com/group/kanbandev/message/8990
>
> This isn't intended to be a knock at XP, I'm just trying to ground the
> discussion with some specific examples.  I just trying to give an example
> where XP wasn't enough, something extra was needed, and that Kanban provides
> that extra something.
>
> A method just isn't enough, regardless of what that method it is.  Things
> change and there has to be a process that allows people to see those changes
> and adapt to them.
>
> Regards,
>
>
> Ged
>

Messages 9064 - 9093 of 17647   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help