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

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

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
>

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

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/
>

 

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
>

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/
>

Hi John,

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

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

Paul.

 

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

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.
> >
> >
>

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

 

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:

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...

Reply to sender | Reply to group | Reply via web post | Start a New Topic

Messages in this topic (6)

Recent Activity:

• New Members 8

Visit Your Group

MARKETPLACE

Hobbies & Activities Zone: Find others who share your passions! Explore new interests.

---

Stay on top of your group activity without leaving the page you're on - Get the Yahoo! Toolbar now.

---

Get great advice about dogs and cats. Visit the Dog & Cat Answers Center.

Switch to: Text-Only, Daily Digest • Unsubscribe •

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
>