Hi Ted, Henrik,

Did you ask why Toyota and apparently other Japanese companies tend to choose 
Waterfall over other available software development life cycles (such as spiral,
evolutionary, rapid prototyping, etc)?

I have my own ideas over why this may be the case, but it would be interesting
to hear their reasons.

Regards,

Paul.
--- In kanbandev@yahoogroups.com, Ted Young <tedyoung@...> wrote:
>
> Henrik's experience matches mine, at least in software development. We've
> had customers from Japan visit our offices in California and are fascinated
> by our "wall": we use post-it cards to track stories and tasks in a very
> Kanban-like way. The stories I hear from the visitors describes a very
> traditional waterfall model in the way they do development. In fact, it's
> been somewhat of a challenge to introduce Scrum into the projects that we've
> done for Japanese companies.
>
> ;ted
>
> On Tue, Nov 24, 2009 at 9:40 PM, Henrik Kniberg <henrik.kniberg@...>wrote:
>
> >
> >
> > I met a Toyota software dev manager & a chief engineer in Nagoya last
> > spring. Didn't see or hear any sign of Kanban being used in product
> > development.
> >
> > Interestingly enough they are currently using a very traditional waterfall
> > method in software development, and trying hard to figure out how to apply
> > lean principles there. They are doing it slowly & patiently (Toyota style),
> > the current  first step is visualization. So it wouldn't surprise me if some
> > of the stuff we talk about on this list gets applied at Toyota at some point
> > :o)
> >
> > I didn't get to see the actual workplace though. So who knows, maybe their
> > walls are already full of kanban boards & they thought it is so obvious that
> > it wasn't worth mentioning :o)
> >
> > /Henrik
> >
> >
> > On Tue, Nov 24, 2009 at 3:59 AM, Pankaj Chawla <pankaj013@...>wrote:
> >
> >>
> >>
> >> Hi
> >>
> >> Dont know if its already answered or is my question stupid but I
> >> was wondering if Toyota also uses Kanban while actually designing
> >> the car. I know they use it on their production floor where the work flow
> >> is pretty much designed around the assembly line and incremental
> >> build and assemble. Software development to me is more analogous
> >> to product design (as in car design) than production ( as in assembly
> >> line). Thats why I want to understand if Kanban is a way of life in Toyota
> >> in pretty much everything or product design and production line use
> >> different approaches.
> >>
> >> Cheers
> >> Pankaj
> >>
> >>
> >
> >
> > --
> > Henrik Kniberg
> > http://www.crisp.se/henrik.kniberg
> > +46 (0)70 492 5284
> >
> >
> >
> >
>

I'm going and I expect to see some (good) Kanban discussions, if not I
will suggest one.

//Ola


Chris wrote:
>
>
> Is anyone ( apart from karl who I know is presenting ) going to xpday?
>
> If so do they want to suggest any Kanban open space discussions. ( think
> parasitic kanban conf within conf. )
>
> Regards
>
> Chris
> (Sent from my iphone.)
>
> On 24 Nov 2009, at 00:27, John Goodsen <jgoodsen@...
> <mailto:jgoodsen@...>> wrote:
>
>>
>>
>> Today, I like "expedite".  I've seen it in other lean literature
>> (can't find anything at the moment).  It's the term I currently use
>> and it seems to get the point across - although, I like the idea of
>> searching out a name which raises the red flag better - "expedite"
>> almost makes it sound like we are creating extra value - and maybe we
>> are - maybe an expedite workflow is something you can charge premium
>> dollar for to the point that it covers the cost of the waste it
>> generates ?
>>
>> --
>> John Goodsen                 RADSoft / Better Software Faster
>> jgoodsen@... <mailto:jgoodsen@...>
>>  Lean/Agile/XP/Scrum Coaching and Training
>> <http://www.radsoft.com>http://www.radsoft.com          Ruby on Rails
>> and Java Solutions
>>
>>
>> On Wed, Nov 18, 2009 at 6:27 PM, Bill Wake <william.wake@
>> <mailto:william.wake@...>acm.org <http://acm.org>> wrote:
>>
>>     I like your priority/panic designation pretty well. (Better than diva,
>>     etc., sorry:) I like "expedite" (since there's already lean literature
>>     railing against it:) but I could see sort of see applying it to either
>>     category so that's maybe not as clear.
>>
>>     But I'll suggest other things I've seen/heard/used/thought-of:
>>
>>     One star:
>>     Rush, Priority, Top Priority, Urgent
>>
>>     Two stars:
>>     Drop Everything, Hot [or Hot Potato], Critical, Emergency
>>
>>     (Nice chart, BTW!)
>>
>>     (I like your two proposals, and Urgent/Emergency)
>>
>>     --Bill Wake
>>
>>     On Wed, Nov 18, 2009 at 5:38 PM, Henrik Kniberg <henrik.kniberg@
>>     <mailto:henrik.kniberg@...>crisp.se <http://crisp.se>> wrote:
>>     >
>>     > Just to clarify the original question...
>>     > There are two classes of service on this kick-start template, one
>>     > labelled with one star and one labelled with two stars.
>>     >
>>    
<http://www.crisp.se/kanban/kanban-example.pdf>http://www.crisp.se/kanban/kanban\
-example.pdf
>>     >
>>     > One star just means "pull this feature first". So default is
>>     FIFO, but
>>     > if there is a starred feature then pull that one first. Doesn't
>>     > interrupt ongoing work, doesn't break WIP limits. So one start
>>     doesn't
>>     > significantly disrupt flow, and use of this is not a failure mode.
>>     >
>>     > Two stars means the team swarms this feature immediately,
>>     interrupting
>>     > existing work and breaking WIP limits as necessary. This
>>     disrupts flow
>>     > and should be considered a failure mode, an exception. If it happens
>>     > seldom it is OK, if it happens regularly then there is systemic
>>     > problem that should be addressed.
>>     >
>>     > The questions is: what are the most suitable default names for these
>>     > classes of service? The name should be as self-explanatory as
>>     > possible, even to people that don't know about Kanban. Never
>>     mind the
>>     > markers used (stars in this case) it's the terminology I'm after.
>>     >
>>     > I currently use the names priority (1 star) & panic (2 stars).
>>     > Considering priority / expedite instead. Any other suggestions are
>>     > welcome.
>>     >
>>     > It seems these two classes of service exist naturally in most
>>     > contexts, so it would be nice use the same terminology by default.
>>     > People are of course free to use whatever terms they like
>>     locally, but
>>     > I want to provide useful defaults. Any opinions are welcome.
>>     Might set
>>     > up a poll.
>>     >
>>     > /Henrik
>>     >
>>
>>     --
>>       Bill Wake   Industrial Logic, Inc.
>>
>>
>>     ------------------------------------
>>
>>     Yahoo! Groups Links
>>
>>     <http://yahoo.com/>group/kanbandev/
>>
>>     <http://yahoo.com/>group/kanbandev/join
>>        (Yahoo! ID required)
>>
>>        kanbandev-fullfeatured@yahoogroups.com
>>     <mailto:kanbandev-fullfeatured@yahoogroups.com>
>>
>>
>>
>>
>>
>
>
>


--
---------------------------------------------------------
Ola Ellnestam
Agical AB
VÀsterlÄnggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754000
E-mail: ola.ellnestam@...
Blog: http://ellnestam.wordpress.com
Twitter: ellnestam

Good article! We need to get this added to the limitedwipsociety.org site. I'm
traveling and it is middle of the night here. Hopefully someone else can pick
this up and add it to the site. Thanks for sharing Keith.

--- In kanbandev@yahoogroups.com, "Keith" <hooya_groups@...> wrote:
>
> This blog post has high level overview of my impression of Kanban method as a
result of last week's QCon session.
>
> http://kswenson.wordpress.com/2009/11/22/kanban-for-software-development/
>
> Here is a collection of posts on Agile methodology, including the 26
recommendations which people here might be interested in:
>
> http://kswenson.wordpress.com/tag/agile/
>
> -Keith
>

This blog post has high level overview of my impression of Kanban method as a
result of last week's QCon session.

http://kswenson.wordpress.com/2009/11/22/kanban-for-software-development/

Here is a collection of posts on Agile methodology, including the 26
recommendations which people here might be interested in:

http://kswenson.wordpress.com/tag/agile/

-Keith

 

Today, I like "expedite".  I've seen it in other lean literature (can't find anything at the moment).  It's the term I currently use and it seems to get the point across - although, I like the idea of searching out a name which raises the red flag better - "expedite" almost makes it sound like we are creating extra value - and maybe we are - maybe an expedite workflow is something you can charge premium dollar for to the point that it covers the cost of the waste it generates ?

--
John Goodsen                 RADSoft / Better Software Faster
jgoodsen@radsoft.com            Lean/Agile/XP/Scrum Coaching and Training
http://www.radsoft.com          Ruby on Rails and Java Solutions

On Wed, Nov 18, 2009 at 6:27 PM, Bill Wake <william.wake@acm.org> wrote:

I like your priority/panic designation pretty well. (Better than diva,
etc., sorry:) I like "expedite" (since there's already lean literature
railing against it:) but I could see sort of see applying it to either
category so that's maybe not as clear.

But I'll suggest other things I've seen/heard/used/thought-of:

One star:
Rush, Priority, Top Priority, Urgent

Two stars:
Drop Everything, Hot [or Hot Potato], Critical, Emergency

(Nice chart, BTW!)

(I like your two proposals, and Urgent/Emergency)

--Bill Wake

On Wed, Nov 18, 2009 at 5:38 PM, Henrik Kniberg <henrik.kniberg@crisp.se> wrote:
>
> Just to clarify the original question...
> There are two classes of service on this kick-start template, one
> labelled with one star and one labelled with two stars.
> http://www.crisp.se/kanban/kanban-example.pdf
>
> One star just means "pull this feature first". So default is FIFO, but
> if there is a starred feature then pull that one first. Doesn't
> interrupt ongoing work, doesn't break WIP limits. So one start doesn't
> significantly disrupt flow, and use of this is not a failure mode.
>
> Two stars means the team swarms this feature immediately, interrupting
> existing work and breaking WIP limits as necessary. This disrupts flow
> and should be considered a failure mode, an exception. If it happens
> seldom it is OK, if it happens regularly then there is systemic
> problem that should be addressed.
>
> The questions is: what are the most suitable default names for these
> classes of service? The name should be as self-explanatory as
> possible, even to people that don't know about Kanban. Never mind the
> markers used (stars in this case) it's the terminology I'm after.
>
> I currently use the names priority (1 star) & panic (2 stars).
> Considering priority / expedite instead. Any other suggestions are
> welcome.
>
> It seems these two classes of service exist naturally in most
> contexts, so it would be nice use the same terminology by default.
> People are of course free to use whatever terms they like locally, but
> I want to provide useful defaults. Any opinions are welcome. Might set
> up a poll.
>
> /Henrik
>

--
  Bill Wake   Industrial Logic, Inc.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/kanbandev/

<*> Your email settings:
   Individual Email | Traditional

<*> To change settings online go to:
   http://groups.yahoo.com/group/kanbandev/join
   (Yahoo! ID required)

<*> To change settings via email:
   kanbandev-digest@yahoogroups.com
   kanbandev-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
   kanbandev-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
   http://docs.yahoo.com/info/terms/

Hi Pankaj,

Good question. It is very difficult to get a balanced and unbiased view of what
Toyota actually does for Design. I cam across this article that tries to
describe it:

http://www.shmula.com/344/the-toyota-product-development-system

The author uses the book by Morgan and Liker as his main reference. One of my
concerns is that many books about Toyota are written by Western people who
started life outside Toyota and its strongly Japanese culture. In my opinion
such books have a tendency to place a particular lense on the Japanese approach.
They also tend to be uncritical, since their main audience  is western
management who are perceived as failing with regards to their Japanese counter
parts.

In contrast Taiichi Ohno's writings on the TPS seem to me to be much more
balanced and provide a unique insight into the Japanese mindset and how Toyota
evolved as a company. Unfortunately IMO we don't have a similarly authoritative
text for Toyota Design.

Even so the TPDS seems to have a very different focus to the TPS. The goal of
efficiency seems to be replaced with the goal of knowledge creation, which is
most evident in the idea of concurrent design, where a high degree of redundancy
is encouraged.

The article talks about pull scheduling and makes the analogy to kanban in
manufacturing.  For me the devil is in the detail. Agile methods such as XP and
Scrum also use pull scheduling, but their focus is different to Kanban/Lean
Software development, were the idea of flow is more closely related to the
manufacturing concept.

It is clear to me that Design is a very different activity to Production. I
would also say that Car design is a very different activity to Software Design.
So we should be very careful when we choose to make analogies between these
things not to lump them all together.

My experience has shown me not to rely on analogy or theory, but instead build
on ideas that have been proven in practice in my context of software
development. So whilst the TPS or the TPDS can provide us with some insights and
perhaps some inspiration. The proof of the pudding, as always is in the eating.

For me we still have a lot of work to do, to discover which ideas if any from
Toyota work well for Software Design. There is some natural overlap, but I'm
still unsure whether we have uncovered anything new, or whether the study of
Toyota as merely provided us with a new perspective on what we already knew.

Paul.

--- In kanbandev@yahoogroups.com, Pankaj Chawla <pankaj013@...> wrote:
>
> Hi
>
> Dont know if its already answered or is my question stupid but I
> was wondering if Toyota also uses Kanban while actually designing
> the car. I know they use it on their production floor where the work flow
> is pretty much designed around the assembly line and incremental
> build and assemble. Software development to me is more analogous
> to product design (as in car design) than production ( as in assembly
> line). Thats why I want to understand if Kanban is a way of life in Toyota
> in pretty much everything or product design and production line use
> different approaches.
>
> Cheers
> Pankaj
>

Keith

In this case the reason for the refactor was that the abstractions in
the old code were so leaky that creating a clean interface behind which
to operate would have been very difficult - not impossible it would just
have taken some time and certain amount of work on the old code base
before work on the new implementation could have started.

My estimate of 4.5 months is really just that, an estimate I couldn't
say for sure what sort of overhead there would be in practice. The
principle contributor to the extension in time would come from
maintaining the intermediate steps such that the functional behaviour
did not change. I would say that such tasks are hard to estimate with
confidence, though I feel certain that the extra complexity would carry
appreciable overhead.

In general I am in agreement with you that almost every feature can be
broken down so that valuable functionality can be released to the
customer in small and regular stages. However in this specific case I
could see no way out of batching up a large change.

It's also worth noting that the release was much more stressful than our
standard release cycle and really hammered home to the team why it's so
important to break features down (where possible), even if it feels
awkward to do so.

Neil


Keith wrote:
>
>
> Good example. Although this is supporting the contrary case. Large
> schema changes can be intimidating. And, having to keep a customer going
> through it all the time can not be ignored.
>
> How do you know that it would have added a month and a half to the
> schedule? Could you include some more details to support this.
>
> I have accomplished very large and complex schema migrations in the
> past. Let's say that a schema is discovered to be non-normalized, and
> there is a table that really needs to be broken into two tables. There
> are some effects on how you would read and write those tables that would
> ripple through the code. What I have done is
>
> (1) define an internal API around the desired schema: eg an API to get
> the information from one (future) table, and another API to get the
> information from the other. Immediate implementation actually fetches
> from a the single existing table. This can be checked in and made
> "customer ready".
> (2) Then begins the job of switching code to use the new schema through
> this API ... you need to eliminate code that assumes that it is a single
> table. This work has to be regardless of the approach, but because the
> old api (single table) and the new api (multiple tables) are available
> at the same time in the code, you can do this work incrementally and
> there is no increase in effort. At any point in time you can check in
> and ship customer ready code because both the new and the old API are
> functional.
> (3) finally, after all the code is done, you eliminate access to the
> single table, and actually split the table into two, migrates the data.
>
> Sometimes the new API can be implements as a view in the DB. If this is
> the case, you write the code to use the view, and once all the code is
> switched, once all the code that manipulated the old schema is
> eliminated, then you can actually change the underlying tables and
> migrate the data. I prefer the code level API in most cases.
>
> Technically speaking, part of part (1) of this is extra work that would
> not be needed if you did the job as a single batch, but only part of it.
> Having an API that represents the tables is a good idea in general,
> giving you compile time enforcement. That part should be done even if
> you implement in a single batch. I have found that the effort to map the
> new API to the old tables is not a huge task (but your mileage may vary).
>
> The compensating advantage is that you retain a single development
> version, and avoid a huge number of merge conflicts. Working one a
> branch for a long time incurs a cost as well. It is difficult to say
> clearly which cost is greater.
>
> Maybe this example is oversimplified. Your case might be different. What
> makes you sure it would take longer to do an incremental approach?
>
> -Keith
>
> --- In kanbandev@yahoogroups.com <mailto:kanbandev%40yahoogroups.com>,
> Neil Johnson <neil@...> wrote:
>  >
>  > I had this problem earlier in the year.
>  >
> ...
>
>

--
Neil Johnson <neil.johnson@...>
Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

Good example.  Although this is supporting the contrary case.  Large schema
changes can be intimidating.  And, having to keep a customer going through it
all the time can not be ignored.

How do you know that it would have added a month and a half to the schedule? 
Could you include some more details to support this.

I have accomplished very large and complex schema migrations in the past.  Let's
say that a schema is discovered to be non-normalized, and there is a table that
really needs to be broken into two tables.  There are some effects on how you
would read and write those tables that would ripple through the code.  What I
have done is

(1) define an internal API around the desired schema: eg an API to get the
information from one (future) table, and another API to get the information from
the other.  Immediate implementation actually fetches from a the single existing
table.  This can be checked in and made "customer ready".
(2) Then begins the job of switching code to use the new schema through this API
... you need to eliminate code that assumes that it is a single table.   This
work has to be regardless of the approach, but because the old api (single
table) and the new api (multiple tables) are available at the same time in the
code, you can do this work incrementally and there is no increase in effort.  At
any point in time you can check in and ship customer ready code because both the
new and the old API are functional.
(3) finally, after all the code is done, you eliminate access to the single
table, and actually split the table into two, migrates the data.

Sometimes the new API can be implements as a view in the DB.  If this is the
case, you write the code to use the view, and once all the code is switched,
once all the code that manipulated the old schema is eliminated, then you can
actually change the underlying tables and migrate the data.  I prefer the code
level API in most cases.

Technically speaking, part of part (1) of this is extra work that would not be
needed if you did the job as a single batch, but only part of it.  Having an API
that represents the tables is a good idea in general, giving you compile time
enforcement.  That part should be done even if you implement in a single batch. 
I have found that the effort to map the new API to the old tables is not a huge
task (but your mileage may vary).

The compensating advantage is that you retain a single development version, and
avoid a huge number of merge conflicts.  Working one a branch for a long time
incurs a cost as well.  It is difficult to say clearly which cost is greater.


Maybe this example is oversimplified.  Your case might be different.  What makes
you sure it would take longer to do an incremental approach?

-Keith

--- In kanbandev@yahoogroups.com, Neil Johnson <neil@...> wrote:
>
> I had this problem earlier in the year.
>
...

I had this problem earlier in the year.

We needed to refactor the core server functionality of an existing service.

For us, 'done' generally means deployed live but in this case the
refactor was so intrusive that it was not obvious how to incrementally
redeploy the changes.

Our options were to:-

Develop the new branch in parallel and then one day flip the switch, so
long as the functional tests passed in both new and old versions we
could be (more) confident that we hadn't broken anything. In this way
features were broken down, we just weren't putting them live and the
completed features added little value in isolation.

Option two would have been to have found a away to migrate from the old
to the new code base gradually (despite the pain). Doing would have
taken a great deal longer, I'd suspect it would have moved the project
from taking 3 month to taking 4.5 months since we needed a working
'something' at all stages.

As it turned out since we worked so hard on the functional test suite
flipping the switch was largely painless, but I'd really rather not have
branched for that length of time.

Is the answer just to get better at incremental migration of the code base?

Neil



Keith wrote:
>
>
> I am sure you have all heard this before: "this feature is going to take
> 3 months and there is no way to break it into smaller chunks. It is a
> holistic feature, and everything depends on all the other parts."
>
> I have enough experience to know that this position is essentially
> false. I can't prove that such indivisible features don't exist, but in
> 30 years of development I have never seen one. In every single case,
> there is always a way to break a large project into smaller chunks.
>
> I am looking for articles and documents that are persuasive on this
> point. I find this job the hardest in convincing a team to adopt an
> agile approach. I even went so far as to pick a complex coding
> assignment, and show that it was possible to break it into programming
> chunks no longer than 5 to 10 minutes of coding each -- but this
> document is not convincing to someone unfamiliar with that particular
> code. One the task is broken into pieces it looks easy, but programmers
> then assume that their own tasks are somehow different and can not be
> broken up.
>
> We all know that thinking though the design before coding will prevent
> you from having to go back and change the code when you find you started
> in the wrong direction. This leads developers to the Big Design Up Front
> (BDUF) syndrome. In many cases they believe that all of the parts of a
> feature are so interwoven that breaking any part off for implementation
> would be foolish. This probably comes from past projects which started
> down the wrong path, and they had to rework. We all have had some
> experience like this, and there is a strong desire to avoid it, even
> though it is not clear to me that the damage of lost time in these cases
> is all that significant.
>
> My own experience has shown that even in devilishly complex project,
> there are parts and aspects that can be broken off, and implemented to a
> customer ready state. How do you convince others of this?
>
> Especially pernicious is that if I claim my feature is indivisible, I
> can avoid exposure for a much longer time. I can work for several months
> virtually in private, which gives me more time to be sure it is right
> before I have to defend it.
>
> Can you please refer me to document and articles that can help persuade
> people that in 99.999% of all features are divisible, and if they think
> theirs is indivisible they are probably just not trying hard enough?
>
>

--
Neil Johnson <neil.johnson@...>
Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com


--
Neil Johnson <neil.johnson@...>
Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

I am sure you have all heard this before: "this feature is going to take 3
months and there is no way to break it into smaller chunks.  It is a holistic
feature, and everything depends on all the other parts."

I have enough experience to know that this position is essentially false.  I
can't prove that such indivisible features don't exist, but in 30 years of
development I have never seen one.  In every single case, there is always a way
to break a large project into smaller chunks.

I am looking for articles and documents that are persuasive on this point.  I
find this job the hardest in convincing a team to adopt an agile approach.  I
even went so far as to pick a complex coding assignment, and show that it was
possible to break it into programming chunks no longer than 5 to 10 minutes of
coding each -- but this document is not convincing to someone unfamiliar with
that particular code.  One the task is broken into pieces it looks easy, but
programmers then assume that their own tasks are somehow different and can not
be broken up.

We all know that thinking though the design before coding will prevent you from
having to go back and change the code when you find you started in the wrong
direction.  This leads developers to the Big Design Up Front (BDUF) syndrome. 
In many cases they believe that all of the parts of a feature are so interwoven
that breaking any part off for implementation would be foolish.  This probably
comes from past projects which started down the wrong path, and they had to
rework.  We all have had some experience like this, and there is a strong desire
to avoid it, even though it is not clear to me that the damage of lost time in
these cases is all that significant.

My own experience has shown that even in devilishly complex project, there are
parts and aspects that can be broken off, and implemented to a customer ready
state.  How do you convince others of this?

Especially pernicious is that if I claim my feature is indivisible, I can avoid
exposure for a much longer time.  I can work for several months virtually in
private, which gives me more time to be sure it is right before I have to defend
it.

Can you please refer me to document and articles that can help persuade people
that in 99.999% of all features are divisible, and if they think theirs is
indivisible they are probably just not trying hard enough?

Thanks for all the pointers!
/Christina

--- In kanbandev@yahoogroups.com, kausikram krishnasayee <kausikram@...> wrote:
>
> Does anyone have a recommendation for an electronic kanban tool? Are there
> any agile project management tools that incorporate some kanban support?
> I've already looked at AgileZen.
>
> Christina,
> if you are looking for a light weight yet powerful tool, i would suggest
> Silver Catalyst, the product my company develops. we support both normal
> agile and lean variants.
> we support the usual features including wip limits, wip overrides cumulative
> flow reports et al. and also have a good backlog management system. and we
> are probably the only tool that support a per user wip limit across multiple
> projects. thats enough self promotion i guess :)
> Send me a personal mail at kausikram@... for any
> queries. would be happy to help :)
>
> --
> Kausikram Krishnasayee
> Company: http://silverstripesoftware.com | Webpage: kausikram.net | Blog:
> chaosbudha.blogspot.com | Twitter: http://twitter.com/kausikram | Email:
> kausikram@... | Mobile: +91 9884246490
>

Keith,

It'd be great if you could put this up on limitedwipsociety.org too. Thanks for
sharing.

David

--- In kanbandev@yahoogroups.com, "Keith" <hooya_groups@...> wrote:
>
> I am new to this group, so I might be covering things that are very basic.  I
did not know about Kanban software method until this week, when I got a thorough
indoctrination by David Anderson, Jeff Patton, Henrik Kniberg, Chris Shinkle,
and David Laribee at the QCon show in San Francisco.  Great job guys -- count me
in as a believer for now.
>
> I have been studying related topics recently, and a few weeks ago wrote this
article "Taiichi Ohno Reinterpreted" where I show how the idea from his book are
directly applicable to software development.  Sound familiar?  I suppose there
won't be anything new for this group, but in the spirit of sharing resources,
here is the link:
>
> http://kswenson.wordpress.com/2009/10/24/taiichi-ohno-reinterpreted/
>
> -Keith
>

Our "backlog" (next few items that team members can work on) is
located on the board, but for the product backlog (a couple of hundred
bugs, feature requests, etc. that we're trying to whittle down) we
just use our defect tracking system (TeamTrack, formerly bugzilla). We
usually don't create cards until things go on the board.

-chris

On Fri, Nov 20, 2009 at 9:38 AM, Neil Johnson <neil@...> wrote:
> Hi,
>
> For those using physical boards what do people use to manage the product
> backlog?
>
> I've looked through
> http://finance.groups.yahoo.com/group/kanbandev/message/5893
> but it seems to focus on tools to visualise the board as well as the
> backlog, I'm wondering if something lighter weight exists?
>
> Many thanks
>
> Neil
>
> Eric Willeke wrote:
>>
>>
>> For my personal and small projects I've been using LeanKit. The choice
>> for a larger environment is very dependent on environment and team
>> distribution, etc.
>>
>> Eric
>>
>>
>>
>> On Fri, Nov 20, 2009 at 4:12 AM, Christina <cskaskiw@...
>> <mailto:cskaskiw@...>> wrote:
>>
>>     Hi,
>>
>>     Does anyone have a recommendation for an electronic kanban tool? Are
>>     there any agile project management tools that incorporate some
>>     kanban support? I've already looked at AgileZen.
>>
>>     If this has been discussed in previous threads, please point me.
>>
>>     Thanks,
>>     Christina
>>
>>
>>
>>     ------------------------------------
>>
>>     Yahoo! Groups Links
>>
>>
>>        (Yahoo! ID required)
>>
>>        kanbandev-fullfeatured@yahoogroups.com
>>     <mailto:kanbandev-fullfeatured@yahoogroups.com>
>>
>>
>>
>>
>
> --
> Neil Johnson <neil.johnson@...>
> Project Manager
> Tel: +44 (0) 845 666 7778
> http://www.mxtelecom.com
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

I am new to this group, so I might be covering things that are very basic.  I
did not know about Kanban software method until this week, when I got a thorough
indoctrination by David Anderson, Jeff Patton, Henrik Kniberg, Chris Shinkle,
and David Laribee at the QCon show in San Francisco.  Great job guys -- count me
in as a believer for now.

I have been studying related topics recently, and a few weeks ago wrote this
article "Taiichi Ohno Reinterpreted" where I show how the idea from his book are
directly applicable to software development.  Sound familiar?  I suppose there
won't be anything new for this group, but in the spirit of sharing resources,
here is the link:

http://kswenson.wordpress.com/2009/10/24/taiichi-ohno-reinterpreted/

-Keith

Hi,

For those using physical boards what do people use to manage the product
backlog?

I've looked through
http://finance.groups.yahoo.com/group/kanbandev/message/5893
but it seems to focus on tools to visualise the board as well as the
backlog, I'm wondering if something lighter weight exists?

Many thanks

Neil

Eric Willeke wrote:
>
>
> For my personal and small projects I've been using LeanKit. The choice
> for a larger environment is very dependent on environment and team
> distribution, etc.
>
> Eric
>
>
>
> On Fri, Nov 20, 2009 at 4:12 AM, Christina <cskaskiw@...
> <mailto:cskaskiw@...>> wrote:
>
>     Hi,
>
>     Does anyone have a recommendation for an electronic kanban tool? Are
>     there any agile project management tools that incorporate some
>     kanban support? I've already looked at AgileZen.
>
>     If this has been discussed in previous threads, please point me.
>
>     Thanks,
>     Christina
>
>
>
>     ------------------------------------
>
>     Yahoo! Groups Links
>
>
>        (Yahoo! ID required)
>
>        kanbandev-fullfeatured@yahoogroups.com
>     <mailto:kanbandev-fullfeatured@yahoogroups.com>
>
>
>
>

--
Neil Johnson <neil.johnson@...>
Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

Hi Christina,

Here is the prior thread on this:
http://finance.groups.yahoo.com/group/kanbandev/message/5893

Also, Jira with Greenhopper is adding WIP limits:
http://twitter.com/GreenHopperTeam/status/5607668892

I'll try to add a Tools page to the Limited WIP Society site soon.

-Janice

--- In kanbandev@yahoogroups.com, "Christina" <cskaskiw@...> wrote:
>
> Hi,
>
> Does anyone have a recommendation for an electronic kanban tool? Are there any
agile project management tools that incorporate some kanban support? I've
already looked at AgileZen.
>
> If this has been discussed in previous threads, please point me.
>
> Thanks,
> Christina
>