Wow! This is great story. You guys should think about submitting an
experience report for Agile 2008 and we'll see you in Toronto.

David

--- In kanbandev@yahoogroups.com, "Landes Eric (CI/AMM1-NA)"
<eric.landes@...> wrote:
>
> I like your thought's Stuart.  I may give this a try.  Our
experiment so far with Kanban for Sustaining Engineering has been a
great success.  We have cut our cycle time to half of what it was, and
our backlog is at the lowest point I've ever seen it.  With that in
mind I would like to attempt working on quality issues, and your
suggestion is great.  Thanks for the input.
>
> Best regards / Mit freundlichen Grüßen,
>
> Eric Landes
>
> Robert Bosch LLC
>
> Senior Programmer/Analyst (CI/AMM1-NA)
>
> 401 North Bendix Ave.
>
> South Bend, IN 46628
>
> www.bosch.us
>
> Tel: 1 (574) 237-2290
>
> eric.landes@... <mailto:eric.landes@...>
>
>
>
>
> ________________________________
>
>  From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com]
On Behalf Of Stuart Corcoran
>  Sent: Monday, January 21, 2008 4:04 PM
>  To: kanbandev@yahoogroups.com
>  Subject: [kanbandev] Re: Best Practices for Testing Group
>
>
>
>  Eric,
>
>  We agree you should have a separate QA group of professional testers.
>  Since you don't have that I claim the ROI of defining and implementing
>  a process to employ developers as testers is lower than simply
>  eliminating the per-UAT test step.
>
>  The way it would work is you tell the developers they will not be
>  required to periodically (or constantly) switch roles and become a
>  tester for someone else's work. However, any bugs that escape
>  development are the responsibility of the developer. They will be
>  required to drop their current task and fix and retest the bug. Also,
>  they will not be given any schedule relief for their current task.
>  The message is "you are responsible for quality, so do what it takes
>  to get it right".
>
>  This should lead to self-correcting improvements in developer
>  estimates and behavior. Developers would (and should be allowed to)
>  solicit their peers for not only code-reviews and the like, but actual
>  functional testing.
>
>  Obviously this is simply building up rudimentary a QA/test practice
>  within your development organization, but it's across all developers
>  and isn't that where we want the quality to be built in anyway?
>
>  The average WIP-time will lengthen naturally over time but this is
>  time you would have spent in a pre-UAT test step. And over time it
>  could become more efficient than a separate test step.
>
>  My first job as a developer was in an organization such as I
>  described. Although there were no WIP-time metrics I can tell you the
>  quality was very high. Post-development bugs were rare and considered
>  quite an embarrassment to any developer.
>
>  Good luck,
>  Stuart
>

---

From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of David J Anderson
Sent: Tuesday, January 22, 2008 7:48 PM
To: kanbandev@yahoogroups.com
Subject: [kanbandev] Re: Best Practices for Testing Group

Wow! This is great story. You guys should think about submitting an
experience report for Agile 2008 and we'll see you in Toronto.

David

--- In kanbandev@yahoogroups.com, "Landes Eric (CI/AMM1-NA)"
<eric.landes@...> wrote:
>
> I like your thought's Stuart. I may give this a try. Our
experiment so far with Kanban for Sustaining Engineering has been a
great success. We have cut our cycle time to half of what it was, and
our backlog is at the lowest point I've ever seen it. With that in
mind I would like to attempt working on quality issues, and your
suggestion is great. Thanks for the input.
>
> Best regards / Mit freundlichen Grüßen,
>
> Eric Landes
>
> Robert Bosch LLC
>
> Senior Programmer/Analyst (CI/AMM1-NA)
>
> 401 North Bendix Ave.
>
> South Bend, IN 46628
>
> www.bosch.us
>
> Tel: 1 (574) 237-2290
>
> eric.landes@... <mailto:eric.landes@...>
>
>
>
>
> ________________________________
>
> From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com]
On Behalf Of Stuart Corcoran
> Sent: Monday, January 21, 2008 4:04 PM
> To: kanbandev@yahoogroups.com
> Subject: [kanbandev] Re: Best Practices for Testing Group
>
>
>
> Eric,
>
> We agree you should have a separate QA group of professional testers.
> Since you don't have that I claim the ROI of defining and implementing
> a process to employ developers as testers is lower than simply
> eliminating the per-UAT test step.
>
> The way it would work is you tell the developers they will not be
> required to periodically (or constantly) switch roles and become a
> tester for someone else's work. However, any bugs that escape
> development are the responsibility of the developer. They will be
> required to drop their current task and fix and retest the bug. Also,
> they will not be given any schedule relief for their current task.
> The message is "you are responsible for quality, so do what it takes
> to get it right".
>
> This should lead to self-correcting improvements in developer
> estimates and behavior. Developers would (and should be allowed to)
> solicit their peers for not only code-reviews and the like, but actual
> functional testing.
>
> Obviously this is simply building up rudimentary a QA/test practice
> within your development organization, but it's across all developers
> and isn't that where we want the quality to be built in anyway?
>
> The average WIP-time will lengthen naturally over time but this is
> time you would have spent in a pre-UAT test step. And over time it
> could become more efficient than a separate test step.
>
> My first job as a developer was in an organization such as I
> described. Although there were no WIP-time metrics I can tell you the
> quality was very high. Post-development bugs were rare and considered
> quite an embarrassment to any developer.
>
> Good luck,
> Stuart
>

David (and the rest of the Corbis crew),

My company has finally started making the shift to a Kanban approach,
and in the process of putting together the metrics required by various
stakeholders, I've come across a few questions I think you can answer:

1 - In your presentation deck with Rick Garber "A Kanban System for
Sustaining Engineering on Software Systems" you have a slide that
states  that the "Lead Time to Touch Time Ratio as an indicator of
process waste and scope for improvement has been problematic to
measure accurately". Since I didn't actually get to hear you give this
presentation, could you elaborate a bit about what you've tried and
what issues you ran into?

2 - In the same presentation, you have a chart titled "Mean Lead Time
Trend". Is this chart a monthly average? Have you experimented with
different sampling periods or n-day running averages? I'm trying to
identify a good approach to showing the lead time as it begins to
emerge in our system and be able to use it as a means of demonstrating
improvement on a more consistent basis.

3 - You wrote a blog post "Team Frustration Server" in early October,
2007
(http://www.agilemanagement.net/Articles/Weblog/TeamFrustrationServer.html).
How do you feel about this situation after three more months? Is it
pretty much the same, or has the rate of process change settled down
to a more reasonable level?
I'm currently planning on reconciling this cost by using TFS to store
the high-fidelity truth on everything except current status and having
the board be the truth for status. This allows us to use the default
CMMI work items and states, where everything "interesting" from the
perspective of the Kanban board takes place in the "Active" state. It
gives me just enough historical information to compute lead time,
staleness (time in proposed), and WIP. It does not allow anything on
touch time and limits what's available for Blocked Items.  We also are
getting a rough sizing on requirements based on the task count, but
this is VERY rough and is at this point just a guess as to usefulness.

Thoughts?

Eric Willeke
Software Architect

Don't miss the upcoming APLN Dallas Leadership Summit!
"Agile Leadership: What is it? How do we do it?"
February 21-22, 2008 Radisson Hotel Central, Dallas, TX

Connect with world-class Agile Leaders at the APLN Dallas Leadership Summit. 
Meet, talk and listen to leaders who have applied agile principles to their business enterprise. 
Discover how to lead agile in your organization and scale agile development practices. 
Be a part of one of the fastest growing trends in the technology industry.

The APLN Dallas Leadership Summit educates attendees with dynamic presenters 
such as David Anderson, Pollyanna Pixton, Todd Little and more. 
Hear panel discussions with agile leaders from Fortune 500 companies 
and participate in think tank breakout sessions. 
Network with leaders who are agile leaders at breaks and social events.  

For more information about the APLN Dallas Leadership Summit, sponsorship opportunities, and to register now visit: http://apln.org/summits.html

Yes! Please support the APLN by coming along to the Leadership Summit
in Dallas and here me talk about kanban first hand together with the
excellent Chris Matts talking about Real Option Theory applied to
software development projects. It's all the stuff you've been reading
in this group. This month you have a chance to interact with Chris and
I directly.

The APLN relies on Leadership Summits to generate funding for the
organization. By attending the event, you get great training, great
content, a chance to socialize and build your network with some of the
luminaries in the agile management and leadership space, and you get
to directly support the APLN and its mission to promote better
leadership and management in our industry.

Looking forward to seeing you there.

David
--
http://www.agilemanagement.net/

--- In kanbandev@yahoogroups.com, Pollyanna Pixton <p2@...> wrote:
>
> Earlybird Ends 1 February.
> Sign up now at: http://apln.org/summits.html
>
> *Don't miss the upcoming APLN Dallas Leadership Summit!*
>
> */"Agile Leadership: What is it? How do we do it?"/*/
> //February 21-22, 2008 Radisson Hotel Central, Dallas, TX/
>
> Connect with world-class Agile Leaders at the APLN Dallas Leadership
Summit.
> Meet, talk and listen to leaders who have applied agile principles
to their business enterprise.
> Discover how to lead agile in your organization and scale agile
development practices.
> Be a part of one of the fastest growing trends in the technology
industry.
>
> The APLN Dallas Leadership Summit educates attendees with dynamic
presenters
> such as David Anderson, Pollyanna Pixton, Todd Little and more.
> Hear panel discussions with agile leaders from Fortune 500 companies
> and participate in think tank breakout sessions.
> Network with leaders who are agile leaders at breaks and social
events.
>
>
> *For more information about the APLN Dallas Leadership Summit,
> sponsorship opportunities, and to register now visit:
http://apln.org/summits.html*
>

Hi Eric,

1. The lead time : touch time ratio is really a lead time : assigned
time ratio, and it really only helps us to call out queuing time. It
doesn't give us good insight in to whether the assigned resource was
working the item or whether it was blocked. Reporting on blocked time
is technically possible but challenging and we haven't achieved it yet.

We also found that lead time : touch time was not showing much of an
improvement nor was there an emerging pattern. There was too much
noise in the signal. We have not managed to attenuate the noise
sufficiently to make it a meaningful graph. I've been disappointed
that I didn't see similar results to those achieved with Microsoft XIT
back in 2005.

2. Yes, it's a monthly average and no we haven't experimented with
different sample periods. Sorry! Can't be any more helpful on this one.

3. My thoughts on TFS haven't changed. It is a necessary and vital
part of the organizational and cultural transformation at Corbis but
it still requires a lot of overhead.

We have seen the rate of process change slow on the sustaining
engineering line. It has significantly reduced and stabilized.
However, other major projects continue to see significant process
evolution, so the net effect is that changes to TFS templates, WITDs
and reports are happening pretty much every week.

David

--- In kanbandev@yahoogroups.com, "erwilleke" <eric.willeke@...> wrote:
>
> David (and the rest of the Corbis crew),
>
> My company has finally started making the shift to a Kanban approach,
> and in the process of putting together the metrics required by various
> stakeholders, I've come across a few questions I think you can answer:
>
> 1 - In your presentation deck with Rick Garber "A Kanban System for
> Sustaining Engineering on Software Systems" you have a slide that
> states  that the "Lead Time to Touch Time Ratio as an indicator of
> process waste and scope for improvement has been problematic to
> measure accurately". Since I didn't actually get to hear you give this
> presentation, could you elaborate a bit about what you've tried and
> what issues you ran into?
>
> 2 - In the same presentation, you have a chart titled "Mean Lead Time
> Trend". Is this chart a monthly average? Have you experimented with
> different sampling periods or n-day running averages? I'm trying to
> identify a good approach to showing the lead time as it begins to
> emerge in our system and be able to use it as a means of demonstrating
> improvement on a more consistent basis.
>
> 3 - You wrote a blog post "Team Frustration Server" in early October,
> 2007
>
(http://www.agilemanagement.net/Articles/Weblog/TeamFrustrationServer.html).
> How do you feel about this situation after three more months? Is it
> pretty much the same, or has the rate of process change settled down
> to a more reasonable level?
> I'm currently planning on reconciling this cost by using TFS to store
> the high-fidelity truth on everything except current status and having
> the board be the truth for status. This allows us to use the default
> CMMI work items and states, where everything "interesting" from the
> perspective of the Kanban board takes place in the "Active" state. It
> gives me just enough historical information to compute lead time,
> staleness (time in proposed), and WIP. It does not allow anything on
> touch time and limits what's available for Blocked Items.  We also are
> getting a rough sizing on requirements based on the task count, but
> this is VERY rough and is at this point just a guess as to usefulness.
>
> Thoughts?
>
> Eric Willeke
> Software Architect
>

Hi all,

I like the idea of a kanban system, especially in the 'sustained
engineering' context, as discussed on this list. I haven't tried it in
practice, and I still have some questions.

Suppose a change request has serious legal consequences if it hasn't
been implemented by date X. How does a kanban software development
team handle such a request? As I understand it, a request enters the
first queue and every 'station' along the way tries to deliver as soon
as possible.

But how do I know (or how can the team commit) that 'as soon as
possible' is soon enough to meet date X?

Regards,
Martin

--
   Martin Schapendonk, http://www.schapendonk.org/blog/

No matter how the work is scheduled, your best-case one-piece-flow cycle
time is a lower bound.

If a deadline falls within the normal variation of lead time, then you
can mark the date on the kanban and schedule it in the usual way.

Otherwise, there are a couple of expediting strategies you might apply
to time critical tasks.  The lesser is to jump to the head of the input
queue and then be treated like a normal ticket.  The greater is the
"silver bullet" expedited kanban:

http://finance.groups.yahoo.com/group/kanbandev/message/68

Beyond that, any single work request is subject to the same kind of
"cone of uncertainty" as any other software estimation.  Kanban smooths
out the aggregate, but the individual work request may still vary
widely.  Parallel/redundant (i.e. set-based) work requests can further
smooth out scheduling uncertainty, at the cost of some...redundancy.

Corey


Martin Schapendonk wrote:
>
> Hi all,
>
> I like the idea of a kanban system, especially in the 'sustained
> engineering' context, as discussed on this list. I haven't tried it in
> practice, and I still have some questions.
>
> Suppose a change request has serious legal consequences if it hasn't
> been implemented by date X. How does a kanban software development
> team handle such a request? As I understand it, a request enters the
> first queue and every 'station' along the way tries to deliver as soon
> as possible.
>
> But how do I know (or how can the team commit) that 'as soon as
> possible' is soon enough to meet date X?
>
> Regards,
> Martin
>
> --
> Martin Schapendonk, http://www.schapendonk.org/blog/
> <http://www.schapendonk.org/blog/>
>
>

OK, sounds good.

As you mentioned, work requests can vary greatly in size. When does a
kanban team estimate the size of a work request? Is any effort spend
on estimating the expected lead time for a specific work request?

Martin

On 1/31/08, Corey Ladas <coreyl@...> wrote:
> No matter how the work is scheduled, your best-case one-piece-flow cycle
> time is a lower bound.
>
> If a deadline falls within the normal variation of lead time, then you
> can mark the date on the kanban and schedule it in the usual way.
>
> Otherwise, there are a couple of expediting strategies you might apply
> to time critical tasks.  The lesser is to jump to the head of the input
> queue and then be treated like a normal ticket.  The greater is the
> "silver bullet" expedited kanban:
>
> http://finance.groups.yahoo.com/group/kanbandev/message/68
>
> Beyond that, any single work request is subject to the same kind of
> "cone of uncertainty" as any other software estimation.  Kanban smooths
> out the aggregate, but the individual work request may still vary
> widely.  Parallel/redundant (i.e. set-based) work requests can further
> smooth out scheduling uncertainty, at the cost of some...redundancy.
>
> Corey
>
>
> Martin Schapendonk wrote:
> >
> > Hi all,
> >
> > I like the idea of a kanban system, especially in the 'sustained
> > engineering' context, as discussed on this list. I haven't tried it in
> > practice, and I still have some questions.
> >
> > Suppose a change request has serious legal consequences if it hasn't
> > been implemented by date X. How does a kanban software development
> > team handle such a request? As I understand it, a request enters the
> > first queue and every 'station' along the way tries to deliver as soon
> > as possible.
> >
> > But how do I know (or how can the team commit) that 'as soon as
> > possible' is soon enough to meet date X?
> >
> > Regards,
> > Martin
> >
> > --
> > Martin Schapendonk, http://www.schapendonk.org/blog/
> > <http://www.schapendonk.org/blog/>
> >
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
   Martin Schapendonk, http://www.schapendonk.org/blog/

---

From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Martin Schapendonk
Sent: Friday, February 01, 2008 4:11 AM
To: kanbandev@yahoogroups.com
Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?

OK, sounds good.

As you mentioned, work requests can vary greatly in size. When does a
kanban team estimate the size of a work request? Is any effort spend
on estimating the expected lead time for a specific work request?

Martin

On 1/31/08, Corey Ladas <coreyl@...> wrote:
> No matter how the work is scheduled, your best-case one-piece-flow cycle
> time is a lower bound.
>
> If a deadline falls within the normal variation of lead time, then you
> can mark the date on the kanban and schedule it in the usual way.
>
> Otherwise, there are a couple of expediting strategies you might apply
> to time critical tasks. The lesser is to jump to the head of the input
> queue and then be treated like a normal ticket. The greater is the
> "silver bullet" expedited kanban:
>
> http://finance.groups.yahoo.com/group/kanbandev/message/68
>
> Beyond that, any single work request is subject to the same kind of
> "cone of uncertainty" as any other software estimation. Kanban smooths
> out the aggregate, but the individual work request may still vary
> widely. Parallel/redundant (i.e. set-based) work requests can further
> smooth out scheduling uncertainty, at the cost of some...redundancy.
>
> Corey
>
>
> Martin Schapendonk wrote:
> >
> > Hi all,
> >
> > I like the idea of a kanban system, especially in the 'sustained
> > engineering' context, as discussed on this list. I haven't tried it in
> > practice, and I still have some questions.
> >
> > Suppose a change request has serious legal consequences if it hasn't
> > been implemented by date X. How does a kanban software development
> > team handle such a request? As I understand it, a request enters the
> > first queue and every 'station' along the way tries to deliver as soon
> > as possible.
> >
> > But how do I know (or how can the team commit) that 'as soon as
> > possible' is soon enough to meet date X?
> >
> > Regards,
> > Martin
> >
> > --
> > Martin Schapendonk, http://www.schapendonk.org/blog/
> > <http://www.schapendonk.org/blog/>
> >
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

--
Martin Schapendonk, http://www.schapendonk.org/blog/

Eric, thanks for your comments.

I'm familiar with the point system and planning poker. But, I know it
in relation to Scrum, with fixed sprint length. IMHO, such a system
has a bigger need for estimates, to determine if something fits within
a sprint.

A kanban system has no iterations and a work request can be any size.
There is no real need to see if it fits, because if it can be worked
on, it can be put in the queue (or did I misinterpret something?).

Do you use point value to estimate lead time? E.g. a kanban estimated
10 points will take us (estimate! average!) 20 days and 15 points will
take us 30 days?

What do you answer (based on what information) when the business asks
"what's the planning, when do I get it"?

Martin

On 2/1/08, Landes Eric (CI/AMM1-NA) <eric.landes@...> wrote:
>
>
> Not sure if this is helpful Martin, but we are trying to  estimate each work
item using a point system.  This is more to help the  team understand work in
the queue and over time, we can report back to upper  management on what's
actually in the queue.  For these items our team does  planning poker.  But for
us, since we do a FIFO process to select from our  backlog, the estimation is
more for management reporting than for the  developers.
>
> Eric  Landes
>
>
>
>
>    ________________________________
    From: kanbandev@yahoogroups.com
[mailto:kanbandev@yahoogroups.com] On Behalf Of Martin    Schapendonk
> Sent: Friday, February 01, 2008 4:11 AM
> To:    kanbandev@yahoogroups.com
> Subject: Re: [kanbandev] How to handle    strict deadlines in a kanban?
>
>
>
>
>
>
> OK, sounds good.
>
> As you mentioned, work requests can vary greatly in    size. When does a
> kanban team estimate the size of a work request? Is any    effort spend
> on estimating the expected lead time for a specific work    request?
>
> Martin
>
> On 1/31/08, Corey Ladas <coreyl@...> wrote:
> > No matter    how the work is scheduled, your best-case one-piece-flow cycle
> > time is    a lower bound.
> >
> > If a deadline falls within the normal variation    of lead time, then you
> > can mark the date on the kanban and schedule it    in the usual way.
> >
> > Otherwise, there are a couple of expediting    strategies you might apply
> > to time critical tasks. The lesser is to    jump to the head of the input
> > queue and then be treated like a normal    ticket. The greater is the
> > "silver bullet" expedited    kanban:
> >
> > http://finance.groups.yahoo.com/group/kanbandev/message/68
> >
> >    Beyond that, any single work request is subject to the same kind of
> >    "cone of uncertainty" as any other software estimation. Kanban smooths
> >    out the aggregate, but the individual work request may still vary
> >    widely. Parallel/redundant (i.e. set-based) work requests can further
> >    smooth out scheduling uncertainty, at the cost of    some...redundancy.
> >
> > Corey
> >
> >
> > Martin    Schapendonk wrote:
> > >
> > > Hi all,
> > >
> > >    I like the idea of a kanban system, especially in the 'sustained
> > >    engineering' context, as discussed on this list. I haven't tried it in
> >    > practice, and I still have some questions.
> > >
> > >    Suppose a change request has serious legal consequences if it hasn't
> >    > been implemented by date X. How does a kanban software    development
> > > team handle such a request? As I understand it, a    request enters the
> > > first queue and every 'station' along the way    tries to deliver as soon
> > > as possible.
> > >
> > >    But how do I know (or how can the team commit) that 'as soon as
> > >    possible' is soon enough to meet date X?
> > >
> > >    Regards,
> > > Martin
> > >
> > > --
> > > Martin    Schapendonk, http://www.schapendonk.org/blog/
> >    > <http://www.schapendonk.org/blog/>
> >    >
> > >
> >
> >
> >
> >
> > Yahoo! Groups    Links
> >
> >
> >
> >
>
> --
> Martin Schapendonk, http://www.schapendonk.org/blog/
>
>
>



--
   Martin Schapendonk, http://www.schapendonk.org/blog/

Adding to the general thread (having read all the posts)...

It's worth mentioning that if the request is really urgent the
"expedite" (or silver bullet) processing time can be much shorter than
the typical lead time numbers.

However, we don't want to be expediting too much or at all. But worth
keeping up your sleeve. If something has a hard delivery date and that
date is soon, then expedite it.

As Chris Matts suggests, if something has a hard date but it is
farther out and the cost of failure to hit the date is high then you
need to introduce it to the kanban system early enough to be confident
it will be complete before the required date.

The choice of when to put it in the system is heavily dependent on
cost of failure. I really need to write a lot more on this topic as
its been on my mind a lot recently and features heavily in my keynote
speech in Sweden next week. Look out for some blog posts on this topic
later this month.

David

--- In kanbandev@yahoogroups.com, "Martin Schapendonk" <martin@...> wrote:
>
> Hi all,
>
> I like the idea of a kanban system, especially in the 'sustained
> engineering' context, as discussed on this list. I haven't tried it in
> practice, and I still have some questions.
>
> Suppose a change request has serious legal consequences if it hasn't
> been implemented by date X. How does a kanban software development
> team handle such a request? As I understand it, a request enters the
> first queue and every 'station' along the way tries to deliver as soon
> as possible.
>
> But how do I know (or how can the team commit) that 'as soon as
> possible' is soon enough to meet date X?
>
> Regards,
> Martin
>
> --
>   Martin Schapendonk, http://www.schapendonk.org/blog/
>

Everybody thanks for the valuable comments. Although it does sound
interesting, I won't have the opportunity to visit Dallas in a few
weeks time (The Netherlands <--> Dallas is a bit far), so I'll pass on
that opportunity.

Corey, am I correct (based on your blog) that you are in favor of the
3rd scheme you describe? Use MMFs as 'high level' work requests, break
them down into rightsized chunks and do not consider anything done
until the MMF is done?

Martin

--
   Martin Schapendonk, http://www.schapendonk.org/blog/

Well, I try to be careful about what I'm "in favor of," as I am in favor
of whatever makes the most sense for the capability of the team in
question.  I would say that extracting MMFs from broader requirements is
almost always right.

The 3rd scheme goes along with a more advanced analysis and design
capability.  If you're using Design Structure Matrices, operationally
defined requirements, and/or Nam Suh's design axioms, then the 3rd
scheme is natural and efficient.  Any MMF will break down into a set of
rows in the DSM.  When the rows are all resolved, the MMF is done.  A
beneficial consequence is that kanban limiting is simpler than point
limiting.  The ability to break work up into similarly-sized pieces is a
more advanced capability that some might aspire to.  If your estimation
skills are actually accurate, you are already part of the way there.

Corey


Martin Schapendonk wrote:
>
> Everybody thanks for the valuable comments. Although it does sound
> interesting, I won't have the opportunity to visit Dallas in a few
> weeks time (The Netherlands <--> Dallas is a bit far), so I'll pass on
> that opportunity.
>
> Corey, am I correct (based on your blog) that you are in favor of the
> 3rd scheme you describe? Use MMFs as 'high level' work requests, break
> them down into rightsized chunks and do not consider anything done
> until the MMF is done?
>
> Martin
>
> --
> Martin Schapendonk, http://www.schapendonk.org/blog/
> <http://www.schapendonk.org/blog/>
>
>

All,
In the course of reading the latest thread on strict deadlines, I
realized how often this group uses terms that carry a great deal of
meaning for people that understand the context of the group. This is
wonderful, but I have to wonder how long it would take somebody
joining the group for the first time to figure out what an MMF
represents, or exactly what is meant by Heijunka or Delphi.

To address this and hopefully bring my understanding of some of the
terms more in line with the rest of the group, I used the "Database"
function of the group to create a basic glossary that we can fill out
with meanings. If a link is then added to the description on the
group's home page we may be able to help newcomers pick up on the
discussions more quickly.

I added a few terms, mostly by flipping through recent posts and
calling out words that struck me as overly technical or as being used
with a meaning that may not be fully apparent. Other than expanding
some of the abbreviations I did not make any effort to enter
definitions; there are others on this board much more qualified if
they are able to contribute the time.

Contribute at:
http://finance.groups.yahoo.com/group/kanbandev/database?method=reportRows&tbl=1

Great initiative.

> All,
> In the course of reading the latest thread on strict deadlines, I
> realized how often this group uses terms that carry a great deal of
> meaning for people that understand the context of the group. This is
> wonderful, but I have to wonder how long it would take somebody
> joining the group for the first time to figure out what an MMF
> represents, or exactly what is meant by Heijunka or Delphi.
>
> To address this and hopefully bring my understanding of some of the
> terms more in line with the rest of the group, I used the "Database"
> function of the group to create a basic glossary that we can fill out
> with meanings. If a link is then added to the description on the
> group's home page we may be able to help newcomers pick up on the
> discussions more quickly.
>
> I added a few terms, mostly by flipping through recent posts and
> calling out words that struck me as overly technical or as being used
> with a meaning that may not be fully apparent. Other than expanding
> some of the abbreviations I did not make any effort to enter
> definitions; there are others on this board much more qualified if
> they are able to contribute the time.
>
> Contribute at:
>
http://finance.groups.yahoo.com/group/kanbandev/database?method=reportRows&tbl=1
>
>
>

---

From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Martin Schapendonk
Sent: Friday, February 01, 2008 9:50 AM
To: kanbandev@yahoogroups.com
Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?

Eric, thanks for your comments.

I'm familiar with the point system and planning poker. But, I know it
in relation to Scrum, with fixed sprint length. IMHO, such a system
has a bigger need for estimates, to determine if something fits within
a sprint.

A kanban system has no iterations and a work request can be any size.
There is no real need to see if it fits, because if it can be worked
on, it can be put in the queue (or did I misinterpret something?).

Do you use point value to estimate lead time? E.g. a kanban estimated
10 points will take us (estimate! average!) 20 days and 15 points will
take us 30 days?

What do you answer (based on what information) when the business asks
"what's the planning, when do I get it"?

Martin

On 2/1/08, Landes Eric (CI/AMM1-NA) <eric.landes@us.bosch.com> wrote:
>
>
> Not sure if this is helpful Martin, but we are trying to estimate each work item using a point system. This is more to help the team understand work in the queue and over time, we can report back to upper management on what's actually in the queue. For these items our team does planning poker. But for us, since we do a FIFO process to select from our backlog, the estimation is more for management reporting than for the developers.
>
> Eric Landes
>
>
>
>
> ________________________________
From: kanbandev@yahoogroups.com
[mailto:kanbandev@yahoogroups.com] On Behalf Of Martin Schapendonk
> Sent: Friday, February 01, 2008 4:11 AM
> To: kanbandev@yahoogroups.com
> Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?
>
>
>
>
>
>
> OK, sounds good.
>
> As you mentioned, work requests can vary greatly in size. When does a
> kanban team estimate the size of a work request? Is any effort spend
> on estimating the expected lead time for a specific work request?
>
> Martin
>
> On 1/31/08, Corey Ladas <coreyl@...> wrote:
> > No matter how the work is scheduled, your best-case one-piece-flow cycle
> > time is a lower bound.
> >
> > If a deadline falls within the normal variation of lead time, then you
> > can mark the date on the kanban and schedule it in the usual way.
> >
> > Otherwise, there are a couple of expediting strategies you might apply
> > to time critical tasks. The lesser is to jump to the head of the input
> > queue and then be treated like a normal ticket. The greater is the
> > "silver bullet" expedited kanban:
> >
> > http://finance.groups.yahoo.com/group/kanbandev/message/68
> >
> > Beyond that, any single work request is subject to the same kind of
> > "cone of uncertainty" as any other software estimation. Kanban smooths
> > out the aggregate, but the individual work request may still vary
> > widely. Parallel/redundant (i.e. set-based) work requests can further
> > smooth out scheduling uncertainty, at the cost of some...redundancy.
> >
> > Corey
> >
> >
> > Martin Schapendonk wrote:
> > >
> > > Hi all,
> > >
> > > I like the idea of a kanban system, especially in the 'sustained
> > > engineering' context, as discussed on this list. I haven't tried it in
> > > practice, and I still have some questions.
> > >
> > > Suppose a change request has serious legal consequences if it hasn't
> > > been implemented by date X. How does a kanban software development
> > > team handle such a request? As I understand it, a request enters the
> > > first queue and every 'station' along the way tries to deliver as soon
> > > as possible.
> > >
> > > But how do I know (or how can the team commit) that 'as soon as
> > > possible' is soon enough to meet date X?
> > >
> > > Regards,
> > > Martin
> > >
> > > --
> > > Martin Schapendonk, http://www.schapendonk.org/blog/
> > > <http://www.schapendonk.org/blog/>
> > >
> > >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> --
> Martin Schapendonk, http://www.schapendonk.org/blog/
>
>
>

--
Martin Schapendonk, http://www.schapendonk.org/blog/

Did a Kanban keyword search:
http://submissions.agile2008.org/taxonomy/term/588

Keep checking back, and please submit your reviews!

In putting together a workshop for Agile 2008, I ended up distilling my
thoughts down to three key concepts - Kanban, Flow and Cadence - hence
KFC.

The submission is here:
http://submissions.agile2008.org/node/957

I'd really like some feedback from this group.

In particular, in coming up with the snappy title, did I end up missing
out some important ideas, or did I end up trivialising the subject?

Please comment on the submissions site, or if you don't want to create
an account, then reply to this thread.

Thanks

Karl

Hello, I have just submitted one Lean session.

"Learning Kaizen from Toyota [with Mind Map]"
http://submissions.agile2008.org/node/2400

I'm thinking of submitting another session realted to Kanban more
directly...

-Kenji

Aaron Sanders wrote:
>
> Did a Kanban keyword search:
> http://submissions.agile2008.org/taxonomy/term/588
> <http://submissions.agile2008.org/taxonomy/term/588>
>
> Keep checking back, and please submit your reviews!
>
>

I won't make a habit of using my own group to promote my new business
but I know that many folks in this group would be pleased to hear that
I've started my own consulting and training practice with Corey Ladas
and Jim Benson - Modus Cooperandi. http://www.moduscooperandi.com/

We're offering training classes in kanban as well as the popular Zen
of Agile Management class I've been teaching at conferences this past
two years.

In addition, we can work directly with your organization to coach and
advise on an agile/Lean transition for the entire IT/Software Product
group.

Learn more at http://www.moduscooperandi.com/ or contact me directly
at this email address.

Regards,
David

-
David J. Anderson
Founder, Modus Cooperandi
Performance Through Collaboration
http://www.moduscooperandi.com/
Tel: +12062012717
Cell:+12062652163
Skype: agilemanager
Blog: http://www.agilemanagement.net/Articles/Weblog/blog.html

Do you want to add real options to your service offering?

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

-----Original Message-----
From: "David J Anderson" <netherby_uk@...>

Date: Fri, 15 Feb 2008 17:20:50
To:kanbandev@yahoogroups.com
Subject: [kanbandev] ANN: Modus Cooperandi Kanban training and consulting


I won't make a habit of using my own group to promote my new business
  but I know that many folks in this group would be pleased to hear that
  I've started my own consulting and training practice with Corey Ladas
  and Jim Benson - Modus Cooperandi. http://www.moduscoo
<http://www.moduscooperandi.com/> perandi.com/

  We're offering training classes in kanban as well as the popular Zen
  of Agile Management class I've been teaching at conferences this past
  two years.

  In addition, we can work directly with your organization to coach and
  advise on an agile/Lean transition for the entire IT/Software Product
  group.

  Learn more at http://www.moduscoo <http://www.moduscooperandi.com/>
perandi.com/ or contact me directly
  at this email address.

  Regards,
  David

  -
  David J. Anderson
  Founder, Modus Cooperandi
  Performance Through Collaboration
  http://www.moduscoo <http://www.moduscooperandi.com/> perandi.com/
  Tel: +12062012717
  Cell:+12062652163
  Skype: agilemanager
  Blog: http://www.agileman
<http://www.agilemanagement.net/Articles/Weblog/blog.html>
agement.net/Articles/Weblog/blog.html

I submitted a new one.

--------------------------------------------------
New Car Development in Toyota
http://submissions.agile2008.org/node/2769

Nobuaki Katayama, the chief engineer of Lexus/SC and IS, talked to
software engineers about the process of new car development in Toyota,
at Developer¡Çs Summit 2008 in Tokyo on Feb. 13, 2008.

In this session, I¡Çll give his presentation, translated into English in
place of him.
--------------------------------------------------

http://submissions.agile2008.org/node/2769

-Kenji

Congratulations, David and Corey!
I have been a fan of both of your blogs.

-Kenji

David J Anderson wrote:
>
> I won't make a habit of using my own group to promote my new business
> but I know that many folks in this group would be pleased to hear that
> I've started my own consulting and training practice with Corey Ladas
> and Jim Benson - Modus Cooperandi. http://www.moduscooperandi.com/
> <http://www.moduscooperandi.com/>
>
> We're offering training classes in kanban as well as the popular Zen
> of Agile Management class I've been teaching at conferences this past
> two years.
>
> In addition, we can work directly with your organization to coach and
> advise on an agile/Lean transition for the entire IT/Software Product
> group.
>
> Learn more at http://www.moduscooperandi.com/
> <http://www.moduscooperandi.com/> or contact me directly
> at this email address.
>
> Regards,
> David
>
> -
> David J. Anderson
> Founder, Modus Cooperandi
> Performance Through Collaboration
> http://www.moduscooperandi.com/ <http://www.moduscooperandi.com/>
> Tel: +12062012717
> Cell:+12062652163
> Skype: agilemanager
> Blog: http://www.agilemanagement.net/Articles/Weblog/blog.html
> <http://www.agilemanagement.net/Articles/Weblog/blog.html>
>
>

Thank you Kenji.  We like your work too!

Corey


Kenji HIRANABE wrote:
>
> Congratulations, David and Corey!
> I have been a fan of both of your blogs.
>
> -Kenji
>
> David J Anderson wrote:
> >
> > I won't make a habit of using my own group to promote my new business
> > but I know that many folks in this group would be pleased to hear that
> > I've started my own consulting and training practice with Corey Ladas
> > and Jim Benson - Modus Cooperandi. http://www.moduscooperandi.com/
> <http://www.moduscooperandi.com/>
> > <http://www.moduscooperandi.com/ <http://www.moduscooperandi.com/>>
> >
> > We're offering training classes in kanban as well as the popular Zen
> > of Agile Management class I've been teaching at conferences this past
> > two years.
> >
> > In addition, we can work directly with your organization to coach and
> > advise on an agile/Lean transition for the entire IT/Software Product
> > group.
> >
> > Learn more at http://www.moduscooperandi.com/
> <http://www.moduscooperandi.com/>
> > <http://www.moduscooperandi.com/ <http://www.moduscooperandi.com/>>
> or contact me directly
> > at this email address.
> >
> > Regards,
> > David
> >
> > -
> > David J. Anderson
> > Founder, Modus Cooperandi
> > Performance Through Collaboration
> > http://www.moduscooperandi.com/ <http://www.moduscooperandi.com/>
> <http://www.moduscooperandi.com/ <http://www.moduscooperandi.com/>>
> > Tel: +12062012717
> > Cell:+12062652163
> > Skype: agilemanager
> > Blog: http://www.agilemanagement.net/Articles/Weblog/blog.html
> <http://www.agilemanagement.net/Articles/Weblog/blog.html>
> > <http://www.agilemanagement.net/Articles/Weblog/blog.html
> <http://www.agilemanagement.net/Articles/Weblog/blog.html>>
> >
> >
>
>

Chris,

I would say at this point that Real Options is certainly high on the
list of things we think are interesting.  Perhaps you could take this up
with David offline?

Corey


chris.matts@... wrote:
> Do you want to add real options to your service offering?
>
> ------------------
>
> -----Original Message-----
> From: "David J Anderson" <netherby_uk@...>
>
> Date: Fri, 15 Feb 2008 17:20:50
> To:kanbandev@yahoogroups.com
> Subject: [kanbandev] ANN: Modus Cooperandi Kanban training and consulting
>
>
> I won't make a habit of using my own group to promote my new business
>  but I know that many folks in this group would be pleased to hear that
>  I've started my own consulting and training practice with Corey Ladas
>  and Jim Benson - Modus Cooperandi. http://www.moduscoo
<http://www.moduscooperandi.com/> perandi.com/
>
>  We're offering training classes in kanban as well as the popular Zen
>  of Agile Management class I've been teaching at conferences this past
>  two years.
>
>  In addition, we can work directly with your organization to coach and
>  advise on an agile/Lean transition for the entire IT/Software Product
>  group.
>
>  Learn more at http://www.moduscoo <http://www.moduscooperandi.com/>
perandi.com/ or contact me directly
>  at this email address.
>
>  Regards,
>  David
>
>  -
>  David J. Anderson
>  Founder, Modus Cooperandi
>  Performance Through Collaboration
>  http://www.moduscoo <http://www.moduscooperandi.com/> perandi.com/
>  Tel: +12062012717
>  Cell:+12062652163
>  Skype: agilemanager
>  Blog: http://www.agileman
<http://www.agilemanagement.net/Articles/Weblog/blog.html>
agement.net/Articles/Weblog/blog.html
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Oops sorry

Thought i had.

Damn that reply all button.

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

-----Original Message-----
From: Corey Ladas <coreyl@...>

Date: Fri, 15 Feb 2008 21:18:02
To:kanbandev@yahoogroups.com
Subject: Re: [kanbandev] ANN: Modus Cooperandi Kanban training and consulting


Chris,

I would say at this point that Real Options is certainly high on the
list of things we think are interesting.  Perhaps you could take this up
with David offline?

Corey


chris.matts@... wrote:
> Do you want to add real options to your service offering?
>
> ------------------
>
> -----Original Message-----
> From: "David J Anderson" <netherby_uk@...>
>
> Date: Fri, 15 Feb 2008 17:20:50
> To:kanbandev@yahoogroups.com
> Subject: [kanbandev] ANN: Modus Cooperandi Kanban training and consulting
>
>
> I won't make a habit of using my own group to promote my new business
>  but I know that many folks in this group would be pleased to hear that
>  I've started my own consulting and training practice with Corey Ladas
>  and Jim Benson - Modus Cooperandi. http://www.moduscoo
<http://www.moduscooperandi.com/> perandi.com/
>
>  We're offering training classes in kanban as well as the popular Zen
>  of Agile Management class I've been teaching at conferences this past
>  two years.
>
>  In addition, we can work directly with your organization to coach and
>  advise on an agile/Lean transition for the entire IT/Software Product
>  group.
>
>  Learn more at http://www.moduscoo <http://www.moduscooperandi.com/>
perandi.com/ or contact me directly
>  at this email address.
>
>  Regards,
>  David
>
>  -
>  David J. Anderson
>  Founder, Modus Cooperandi
>  Performance Through Collaboration
>  http://www.moduscoo <http://www.moduscooperandi.com/> perandi.com/
>  Tel: +12062012717
>  Cell:+12062652163
>  Skype: agilemanager
>  Blog: http://www.agileman
<http://www.agilemanagement.net/Articles/Weblog/blog.html>
agement.net/Articles/Weblog/blog.html
>
>
>
>
> Yahoo! Groups Links
>
>
>
>




Yahoo! Groups Links