Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

kanbandev · Using the Kanban Method

The Yahoo! Groups Product Blog

Check it out!

Group Information

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

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 2174 - 2203 of 17563   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#2174 From: PAUL BECKFORD <beckfordp@...>
Date: Thu Apr 2, 2009 6:25 pm
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
beckfordp...
Send Email Send Email
 
Hi David,

I agree. My experience is just one data point. The experience of the western business community applying Six Sigma and TQM in the 80's and 90's is an overwhelming body of evidence however.

What the evidence says is that changing corporate culture takes a lot more than adopting Japanese inspired language. Now we know that management are eager to pay lip service to whatever is fashionable, often as means of not having to change at all.

My concern with Kanban is that it plays right into that desire, with its neat linear value streams and fashionable lean language. My advice is don't be fooled. Talking the talk won't get you there. You need to get good at producing software period, and the XP practices are a good start.

When it comes to actually "doing the right thing"  and "getting results" its technical competence that counts most.  Management processes come second.

Paul.

--- On Thu, 2/4/09, David J. Anderson <netherby_uk@...> wrote:
From: David J. Anderson <netherby_uk@...>
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
To: "beckfordp@..." <beckfordp@...>
Date: Thursday, 2 April, 2009, 4:52 PM

Did you mean to post this to the list rather than me personally? I don't
use this Yahoo! ID for email so I didn't get it until now.

Your experience is fair enough - it's your experience. Meanwhile, others
have had a lot of success stripping out Lean to its principles and applying them
in software development. And the data on CMMI and TSP when implemented correctly
also suggests folks are having a lot of success. The adoption of CMMI is wider
than the adoption of Agile. Hence, while your experience is your experience it
doesn't invalidate others results.

David J Anderson
Management Consultant for the IT Industry
Skype-in +1.206.201.2717
Cell +1.206.265.2163


Author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/



----- Original Message ----
From: "beckfordp@..." <beckfordp@...>
To: David J Anderson <netherby_uk@...>
Sent: Thursday, March 5, 2009 1:41:21 PM
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of
its origin!

Hi David,

I was fully trained in Lean back in 1996. Only then they were calling it TQM.
It was at a big US company and we tried to use lean techniques foe everything.
It worked well for somethings, like production, but didn't work very well
for software development. The practices are mostly based on statistical process
control, and use empirical data to drive process improvement. Whilst this worked
well in production where lots of stuff can be accurately measured, it didn't
work so well in software where cause and effect is more loosely aligned. So we
tried using qualitive, rather than quantitative data, but this still didn't
help much. So we gave up trying to apply PDCA directly. Next we moved to CMMI,
and finally to PSP, and TSP, all aligned with lean values.

None of these worked particularly well. I now do XP which works fantastically
well. I'm still guided by many of the principles and the values from my TQM
days, but I find the holistic approach of XP more suited to what is essentially
a craft.

> "I think software does go through phases..."

From a management perspective, Kanban or Scrum or even Waterfall are all valid
ways of managing software development. From a programmers perspective however,
the phases you speak of don't really exist. They are ephemeral, and
aren't linear, they are all jumbled together, with the programmer jumping
from vision, to design to test all within a few seconds.

> I struggled to articulate this in my first book though some guys like
> Alan Shalloway have said that the way I described it really did switch
> a light on for them.
>
> I like the way Chris Matts articulates it. "Software development is
an
> information arrival process." We happen to have given names to stages
> of arrival. Those names are things like analyzed, designed, coded,
> tested. TDD might a different approach but there is still an
> information arrival process. How many tests have been written and how
> many of them are passing. I suspect there is still an "analyzed"
stage
> where the test to be written have been defined.

TDD isn't linear, its cyclical, with each cycle lasting perhaps a few
seconds or as long as perhaps 10 minutes. There are no phases in a traditional
waterfall sense, and TDD isn't just restricted to detail design. For
instance a discovery found during TDD could prompt you to ask your customer a
question, which could cause your customer to revisit his original goals. TDD is
a process of discovery, where analysis is happening all the time, there is no
"analyze" stage.

>
> Regardless of whether there are handoffs or not we can still manage it
> with kanban. There is benefit in limiting WIP and pulling value through.

I think this is where we went wrong when trying to apply TQM to software. I
also think this is where the ISO and CMMI went wrong (I am a certified CMM
project assessor so I have some experience here too). Rather than constraining
the practice of software development to fit our chosen management process, why
not model our management process around the way we actually write software?

Software isn't like anything else. It isn't Engineering in the
traditional sense, and it isn't manufacture. Infact the best analogy
I've seen is fashion design. The difference with XP is that it started out
with the practice of writing code, the TDD cycle, and then expanded that out
into ever wider feedback cycles. Feedback being the emphasis rather than
eliminating waste, resulting in a management process derived from software
development practice.

I'm sure that an highly skilled Agile team can apply Kanban and succeed.
Infact such a team would probably succeed with any management process. My
concern is the message sent to people new to Agile. Kanban as a practice already
exists in both Scrum and XP. Kanban as a process that eschews iterations is a
new idea though and looses the emphasis on feedback that iterations provide.

So whilst Kanban can work in a software context as shown in XP and Scrum, and
in the successful Kanban projects, I'm concerned about the idea that we
should apply Kanban as applied in the TPS directly to software. Having read
Taiichi Ohno's book on the TPS and from my own experience with TQM, it is
clear to me that his version of Kanban was arrived at in a very different
context.

So perhaps Kanban isn't "Best Practice", but yet another
Management Process, along the lines of Scrum.




#2175 From: "David J Anderson" <netherby_uk@...>
Date: Fri Apr 3, 2009 8:17 am
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
netherby_uk
Send Email Send Email
 
Unfortunately Paul, the evidence from real teams just doesn't back up your
opinion...

--- In kanbandev@yahoogroups.com, PAUL BECKFORD <beckfordp@...> wrote:
>
> When it comes to actually "doing the right thing"  and "getting results" its
technical competence that counts most.  Management processes come second.
>
> Paul.
>

We've got plenty of data to suggest that technical competence improves quickly
and ceases to constrain the performance of the organization. IT doesn't take
much to improve a development team to the point where they are not a bottleneck.
The data suggests that as much as 90+% of cycle time, and 75% of potential
productivity is wasted in other ways - mostly dysfunction between teams and
across organizations in a value stream.

With highly technically competent teams we've been able to improve their
productivity by 3x and their cycle time by 90% without making any changes to the
technical competencies or engineering activities.

This is not a new result per se. Barry Boehm's 1981 treatise on Software
Engineering Economics concluded that poor management affects performance of
software teams more than any other factor. Management processes are in fact the
biggest single leverage point on the economic performance of software
development and would appear to have been so for over 30 years.

If you can show us data that backs your opinion please share it with us, and
with the wider software engineering community. I know several universities,
including Carnegie Mellon and USC, who employ research teams looking at this
area and I'm sure they'd love to have more data for their studies.

Regards,
David
http://www.agilemanagement.net/

#2176 From: "beckfordp@..." <beckfordp@...>
Date: Fri Apr 3, 2009 9:06 am
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
beckfordp...
Send Email Send Email
 
Hi David,

You have an interesting style. "I'm right you're wrong, and if you still think
you're right then prove it". Its reminiscent of the play ground, and brings me
back to when I was around 7 years old :)

Data and success. How do you prove success? What are your success criteria?
Productivity is an interesting word. I can become 70% more productive at
producing a mess, or the wrong thing. The failure of western business to truly
adopt Lean thinking is well documented. You only need to read any management
journal from the 1990's or look at the plight of companies like GM despite
spending millions on consultants who use the latest Japanese buzz words. The
problem is cultural and deep rooted. Talking the talk doesn't cut it. What
counts if whether you can deliver, and that comes down to valuing people and
empowering them with the skills needed for success, not convenient marketable
labels like Kanban, Scrum or whatever.


No, I'm not going to go there. Software development is a creative process by
creative people. It is inherently difficult to measure in a meaningful way.
Those who have had success know that it derives from the creativity and the
skills of the people involved more than the process used. "People over process
and tools", now that rings a bell I wonder where I've herd that before?

I was hoping to have a valuable discussion and make a useful contribution based
on my 20+ years experience.

It seems to me that you are more interested in selling your own particular breed
of snake oil. Well I'm not here selling anything, I'm merely offering an opinion
for what its worth.


As for the value of my opinion, well I'll leave that to others to decide...

Paul.



--- In kanbandev@yahoogroups.com, "David J Anderson" <netherby_uk@...> wrote:
>
> Unfortunately Paul, the evidence from real teams just doesn't back up your
opinion...
>
> --- In kanbandev@yahoogroups.com, PAUL BECKFORD <beckfordp@> wrote:
> >
> > When it comes to actually "doing the right thing"  and "getting results" its
technical competence that counts most.  Management processes come second.
> >
> > Paul.
> >
>
> We've got plenty of data to suggest that technical competence improves quickly
and ceases to constrain the performance of the organization. IT doesn't take
much to improve a development team to the point where they are not a bottleneck.
The data suggests that as much as 90+% of cycle time, and 75% of potential
productivity is wasted in other ways - mostly dysfunction between teams and
across organizations in a value stream.
>
> With highly technically competent teams we've been able to improve their
productivity by 3x and their cycle time by 90% without making any changes to the
technical competencies or engineering activities.
>
> This is not a new result per se. Barry Boehm's 1981 treatise on Software
Engineering Economics concluded that poor management affects performance of
software teams more than any other factor. Management processes are in fact the
biggest single leverage point on the economic performance of software
development and would appear to have been so for over 30 years.
>
> If you can show us data that backs your opinion please share it with us, and
with the wider software engineering community. I know several universities,
including Carnegie Mellon and USC, who employ research teams looking at this
area and I'm sure they'd love to have more data for their studies.
>
> Regards,
> David
> http://www.agilemanagement.net/
>

#2177 From: Torbjörn Gyllebring <torbjorn.gyllebring@...>
Date: Fri Apr 3, 2009 9:18 am
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
torbjorn.gyl...
Send Email Send Email
 
Hi Paul,

On Fri, Apr 3, 2009 at 11:06 AM, beckfordp@...
<beckfordp@...> wrote:

>
> I was hoping to have a valuable discussion and make a useful contribution
> based on my 20+ years experience.
>

Im new to this list, and this thread so forgive me if you've already
shared your experience on this.
As I read the current dialogue David is of the oppionon that it's
quite easy to improve the technical excellence of most teams to a
point beyond that of diminishing returns, given that for *most*
organizations organizational dysfunction hinders them to perform at
that level.

I've heard about reports claming that low friction teams can much
better leverage exceptionall individuals but that teams with high
friction lowers the performance and the ability even of their star
performers. Theese two datapoints seems to me to be highly congruent.

Anyhow, you seem to argue the opposite oppinion, that in general most
teams would most benefit from further technical improvements, is that
right? If you have thoose experiences could you please elaborate on
them further?

> It seems to me that you are more interested in selling your own particular
> breed of snake oil. Well I'm not here selling anything, I'm merely offering
> an opinion for what its worth.
>
> As for the value of my opinion, well I'll leave that to others to decide...

Sounds valueable to me.

> Paul.
Thanks
Torbjörn

#2178 From: "beckfordp@..." <beckfordp@...>
Date: Fri Apr 3, 2009 10:13 am
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
beckfordp...
Send Email Send Email
 
Hi Torbjörn,

The problem is "cookie cutter" recipes. IMHO Software development is a creative
process not a deterministic one. So talk of high friction versus low friction
etc is not that meaningful. What matters is the team and whether they can
deliver. The environment is important too, and I agree dysfunction doesn't help,
but can be readily removed if the management really want to. What most good
teams need is to be left alone to get on with the job.

The management process is secondary. I have tried several management processes
first hand, from CMMI, PSP, TSP Scrum, XP etc. In my experience, the approaches
that succeed are the ones that focus on "doing the work". In software the work
is "writing code". Management processes can either support or hinder this basic
activity of "producing clean working code". Either way good teams will still
succeed. They succeeded in the past using Waterfall (I was there and saw it),
they succeed using Scrum, and no doubt they will succeed with Kanban.

The opposite is true too. Poor teams will fail what ever process they use.
Whether that be Waterfall, Scrum, Kanban, XP or whatever.

So the real question is how do we produce good teams then get out their way?
This is the hard question, and it has to do with valuing your people and
developing their abilities over many years. This means training them in the
skills needed and providing them with mentors and coaches they need to learn
further. It means listening to them when they say something can't be done. It
means creating a learning culture where teams can learn from their mistakes and
do better the next time. It means freeing them from fear.

Now a Taylorist management mindset isn't interested in these "hard problems".
They much rather a "cookie cutter" formula. "Buy my snake oil" and all your
problems will disappear. Follow this simple "1, 2, 3 step" recipe and you don't
need to worry about your people and their abilities (or lack of ability). Your
problems will be solved, because it is my recipe (which you can buy at a price)
that counts.

For Management with this mindset, then there are people willing to sell them an
"off the shelf" recipe. I see Kanban as promoted by David, as yet another
management "recipe". It will fail for the same reasons why Scrum as a management
recipe has failed.


If you are serious about getting better then you will do the hard work, empower
your people, develop their skills and let them get on and do the job. Learning
TDD and becoming good at it is hard work. Learning OO Design and becoming good
at it is hard work. Listening to customers and becoming good at it is hard work.
Once your people are good at what they do, the management process becomes almost
immaterial. It just tends to fall out. You could choose Scrum, Kanban, DSDM, FDD
etc. Infact you hardly need to manage at all, your teams will be self managing
and will succeed without you.

If you aren't serious, then you will hire a consultant, learn the right
language, and add terms like "waste", "pull", and "WIP" to your repertoire. This
will allow you to carry on doing what you've always done, which is fail.

Paul.



--- In kanbandev@yahoogroups.com, Torbjörn Gyllebring <torbjorn.gyllebring@...>
wrote:
>
> Hi Paul,
>
> On Fri, Apr 3, 2009 at 11:06 AM, beckfordp@...
> <beckfordp@...> wrote:
>
> >
> > I was hoping to have a valuable discussion and make a useful contribution
> > based on my 20+ years experience.
> >
>
> Im new to this list, and this thread so forgive me if you've already
> shared your experience on this.
> As I read the current dialogue David is of the oppionon that it's
> quite easy to improve the technical excellence of most teams to a
> point beyond that of diminishing returns, given that for *most*
> organizations organizational dysfunction hinders them to perform at
> that level.
>
> I've heard about reports claming that low friction teams can much
> better leverage exceptionall individuals but that teams with high
> friction lowers the performance and the ability even of their star
> performers. Theese two datapoints seems to me to be highly congruent.
>
> Anyhow, you seem to argue the opposite oppinion, that in general most
> teams would most benefit from further technical improvements, is that
> right? If you have thoose experiences could you please elaborate on
> them further?
>
> > It seems to me that you are more interested in selling your own particular
> > breed of snake oil. Well I'm not here selling anything, I'm merely offering
> > an opinion for what its worth.
> >
> > As for the value of my opinion, well I'll leave that to others to decide...
>
> Sounds valueable to me.
>
> > Paul.
> Thanks
> Torbjörn
>

#2179 From: Torbjörn Gyllebring <torbjorn.gyllebring@...>
Date: Fri Apr 3, 2009 10:55 am
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
torbjorn.gyl...
Send Email Send Email
 
Hi Paul,

On Fri, Apr 3, 2009 at 12:13 PM, beckfordp@...
<beckfordp@...> wrote:
> Hi Torbjörn,
>
> The problem is "cookie cutter" recipes. IMHO Software development is a
> creative process not a deterministic one. So talk of high friction versus
> low friction etc is not that meaningful. What matters is the team and
> whether they can deliver. The environment is important too, and I agree
> dysfunction doesn't help, but can be readily removed if the management
> really want to. What most good teams need is to be left alone to get on with
> the job.

> The management process is secondary. I have tried several management
> processes first hand, from CMMI, PSP, TSP Scrum, XP etc. In my experience,
> the approaches that succeed are the ones that focus on "doing the work". In
> software the work is "writing code". Management processes can either support
> or hinder this basic activity of "producing clean working code".

I think summarizes most of the discussion from the last 30 or so years
as portrayed by Brooks, Weinberg, De Marco, and others. It's also how
I read the writings of Ohno and Liker when it comes to TPS, the
Poppendiecks regarding LSD and basically the foundation for the Agile
manifesto.

Let those closest to the work steer and help them improve and grow,
managements purpose is not defining the how but removing obstacles.

>Either way good teams will still succeed. They succeeded in the past using
Waterfall (I
> was there and saw it), they succeed using Scrum, and no doubt they will
> succeed with Kanban.
>
> The opposite is true too. Poor teams will fail what ever process they use.
> Whether that be Waterfall, Scrum, Kanban, XP or whatever.
>
> So the real question is how do we produce good teams then get out their way?
> This is the hard question, and it has to do with valuing your people and
> developing their abilities over many years. This means training them in the
> skills needed and providing them with mentors and coaches they need to learn
> further. It means listening to them when they say something can't be done.
> It means creating a learning culture where teams can learn from their
> mistakes and do better the next time. It means freeing them from fear.

> Now a Taylorist management mindset isn't interested in these "hard
> problems". They much rather a "cookie cutter" formula. "Buy my snake oil"
> and all your problems will disappear. Follow this simple "1, 2, 3 step"
> recipe and you don't need to worry about your people and their abilities (or
> lack of ability). Your problems will be solved, because it is my recipe
> (which you can buy at a price) that counts.

I must have missed much of the discussion here, and it must be
radically different from what David posts about on his blog and what
he talks about at conferances. From hearing him speak and reading his
words I belive that he's actually very in line with what you said.
Focus on learning, dont micromange help your organization and team by
relentlessly seeking out root causes.

> For Management with this mindset, then there are people willing to sell them
> an "off the shelf" recipe. I see Kanban as promoted by David, as yet another
> management "recipe". It will fail for the same reasons why Scrum as a
> management recipe has failed.

I think failiure is highly subjective, I see a lot of teams and
organizations doing Scrum in a way that I can't belive it's creators
ever envisioned it, it's flawed, broken and hardly recognizable, it's
also better than what they were using before it. They're the majority
and for those in the know they're miserable failiures that dilute the
pure message and makes it harder to have constructive disscussions and
really truly reach hyperproductivity. Alas, it's also valuable in its
own right. Kanban and Lean seems to be the new hype and I guess it's
only natural that the most visible proponents get caught in the rush.

> If you are serious about getting better then you will do the hard work,
> empower your people, develop their skills and let them get on and do the
> job. Learning TDD and becoming good at it is hard work. Learning OO Design
> and becoming good at it is hard work. Listening to customers and becoming
> good at it is hard work. Once your people are good at what they do, the
> management process becomes almost immaterial. It just tends to fall out. You
> could choose Scrum, Kanban, DSDM, FDD etc. Infact you hardly need to manage
> at all, your teams will be self managing and will succeed without you.

I fully share this sentiment. Any manager should strive to be
redundant. It takes hard work, integrity and honesty.

> If you aren't serious, then you will hire a consultant, learn the right
> language, and add terms like "waste", "pull", and "WIP" to your repertoire.
> This will allow you to carry on doing what you've always done, which is
> fail.

This is as it has always been, we have multi billion dollar industries
selling silver bullets on any market imaginable, methodologies,
development tools etc, still the really successfull teams and
organizations still seems to be focusing on their customers and
working for the long term.

Now from my vantage point it seems like you're promoting all the hard
work of building a learning, improving, open organization and that
seems to be the same view as David put forth, building the
organization is more important when you've passed the point where
technical expertise is already present. Since building the
organization will help those already competent to improve their
skills, share them and in that manner build stronger technical skills
without intervention.

Im still not sure on your position there? Is it in general worthwhile
to instead of focusing on "politics" focus on "technologoy" and build
a superstrong team and thus transforming the organization from that
direction?

Sorry for being dense.

Regards
Torbjörn

> Paul.
>
> --- In kanbandev@yahoogroups.com, Torbjörn Gyllebring
> <torbjorn.gyllebring@...> wrote:
>>
>> Hi Paul,
>>
>> On Fri, Apr 3, 2009 at 11:06 AM, beckfordp@...
>> <beckfordp@...> wrote:
>>
>> >
>> > I was hoping to have a valuable discussion and make a useful
>> > contribution
>> > based on my 20+ years experience.
>> >
>>
>> Im new to this list, and this thread so forgive me if you've already
>> shared your experience on this.
>> As I read the current dialogue David is of the oppionon that it's
>> quite easy to improve the technical excellence of most teams to a
>> point beyond that of diminishing returns, given that for *most*
>> organizations organizational dysfunction hinders them to perform at
>> that level.
>>
>> I've heard about reports claming that low friction teams can much
>> better leverage exceptionall individuals but that teams with high
>> friction lowers the performance and the ability even of their star
>> performers. Theese two datapoints seems to me to be highly congruent.
>>
>> Anyhow, you seem to argue the opposite oppinion, that in general most
>> teams would most benefit from further technical improvements, is that
>> right? If you have thoose experiences could you please elaborate on
>> them further?
>>
>> > It seems to me that you are more interested in selling your own
>> > particular
>> > breed of snake oil. Well I'm not here selling anything, I'm merely
>> > offering
>> > an opinion for what its worth.
>> >
>> > As for the value of my opinion, well I'll leave that to others to
>> > decide...
>>
>> Sounds valueable to me.
>>
>> > Paul.
>> Thanks
>> Torbjörn
>>
>
>

#2180 From: "beckfordp@..." <beckfordp@...>
Date: Fri Apr 3, 2009 12:10 pm
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
beckfordp...
Send Email Send Email
 
Hi Torbjörn,

In my experience YES. If the management do not truly want change then they will
adopt fashionable language cherry pick the pieces they like, say they are doing
Kanban, Scrum or whatever, skip the bits they don't like and use their newly
adopted label as a cloak to carry on doing what they have done before.

In this scenario, the consultant becomes part of the problem, Kanban becomes
part of the problem...

In my experience excellence is addictive, and once people taste it they want
more. Getting better at what you do is the start.

Lots of organisations do not want to make this investment in people, and this is
where snake oil comes in and the idea that you can rely on process instead.

Incidentally, I see nothing concrete here that David has said that addresses
culture and politics. The assumption, much like Scrum is that if you make the
problems and bottle-necks visible then organisations will respond to the data
and fix themselves.

In my experience, where cause and effect is clear, then this is true. I saw this
in my TQM days, with simple deterministic processes, like in manufacture.

Where cause and effect are unclear, like with a complex, non-deterministic,
creative process such as software development, then simply trying to measure and
do PDCA doesn't work. The data doesn't clearly point to the problem, people
remain confused as to why they are failing, so fall back on old remedies like
working harder and longer. Like I say nothing changes.

Kanban does not equal cultural change. It cannot.

Paul.
>
> Im still not sure on your position there? Is it in general worthwhile
> to instead of focusing on "politics" focus on "technologoy" and build
> a superstrong team and thus transforming the organization from that
> direction?
>
> Sorry for being dense.
>
> Regards
> Torbjörn

#2181 From: "beckfordp@..." <beckfordp@...>
Date: Fri Apr 3, 2009 12:45 pm
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
beckfordp...
Send Email Send Email
 
Hi Torbjörn,

>
> In my experience excellence is addictive, and once people taste it they want
more. Getting better at what you do is the start.
>
> Lots of organisations do not want to make this investment in people, and this
is where snake oil comes in and the idea that you can rely on process instead.

I just wanted to be clear. Getting good at what you do doesn't mean focusing on
technology. This is another false god. "People over process and tools". Relyng
on tools (technology) is as futile as relying on process if you are not good.
No, getting good at what you do means..

* Getting good at listening to customers
* Getting good at collaborating with team mates
* Getting good at using feedback and writing clean code
* Getting good at OO Design
* Getting good at reliably producing valuable software.
* Getting good at introspection and self improvement.

These are all difficult skills that take years to master and are orthogonal to a
management process like Kanban. These are the things that make software
development a craft.

Regards,

Paul.

#2182 From: Torbjörn Gyllebring <torbjorn.gyllebring@...>
Date: Fri Apr 3, 2009 1:12 pm
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
torbjorn.gyl...
Send Email Send Email
 
Hi Paul,

thanks for sharing your view, and I very much do agree.

On Fri, Apr 3, 2009 at 2:45 PM, beckfordp@...
<beckfordp@...> wrote:
> Hi Torbjörn,
>
>>
>
>> In my experience excellence is addictive, and once people taste it they
>> want more. Getting better at what you do is the start.

I think the quote "You are what you constantly do. Execellence,
therefore, is not an act but a habit.", commonly attributed to
Aristotle, neatly summarizes this. Providing an environment conductive
to fostering excellent, or at least good habits therefore should be on
every leaders mind. As an individual I take pride in my work,
regarding software craftmanship that movement is gathering momentum as
we speak.

>> Lots of organisations do not want to make this investment in people, and
>> this is where snake oil comes in and the idea that you can rely on process
>> instead.

Lots of orgniazations don't really want to treat individuals as
fungible, plug compatibly programming units. Process venders have been
trying to accomplish the illusion of this with tomes filled with
detailed instructions, I'm yet to see any clear evidence that anything
touted as lean or agile have in any way tried to down-play the
importance of individuals, quite the contrary. I thought that was one
of the clear objectives of this group, to discuss ways that kanban
helps us focus the power of the individual? Maybe I got it all wrong
:)

> I just wanted to be clear. Getting good at what you do doesn't mean focusing
> on technology. This is another false god. "People over process and tools".
> Relyng on tools (technology) is as futile as relying on process if you are
> not good. No, getting good at what you do means..
>
> * Getting good at listening to customers
> * Getting good at collaborating with team mates
> * Getting good at using feedback and writing clean code
> * Getting good at OO Design

This nit, I have to pick. OO is a great technology but there are other
valid ways to build well crafted software.

> * Getting good at reliably producing valuable software.
> * Getting good at introspection and self improvement.

The last point I think is what most of the hope of lean and agile
hinges on, I would call it the single most important thing. But I tend
to call it "honesty".

>
> These are all difficult skills that take years to master and are orthogonal
> to a management process like Kanban. These are the things that make software
> development a craft.

As an individual I practice my craft, seek the guadiance of peers and
thoose who've gone before me.
But craftmanship in that regard is *how* I do things, it's not what I
do. Therefore as part of an organization I need guidance on what to
build, and how to collaborate.

And as manager for that organization what is needed is information on
how to improve the whole, to me, pull based systems seems to provide
tight feedback loops and rich information helping us make decisions
based on data, not forecasts. That I belive is a good thing.

Anyone selling Kanban or Scrum as a wholesale solution to the problem
of culture change is a madman. But used as vehicles for ideas, a
common reference and a framework for discussion and vision they're
extraordinarly strong tools.  I belive tools like Kanban can help us
make ideas concrete, my experience is that most work better from
tangible concrete things than from mere ideas and visions. That's why
I always opt for physical taskboards (I haven't had the luxury of
using kanban for a "live" project) over digital ones. Physicly moving
cards give a much stronger impression than point and click
accomplishes. The true goal is to get commitment and buy-in, having
something to hold on to seems to aid that so I advocate using it.

It's always easy to misstake the aid for the thing. That's when I need
peers gently reminding me of our true goal, working software, over our
aid, moving tasks to done.

All the best,
Torbjörn

> Regards,
>
> Paul.
>
>

#2183 From: "beckfordp@..." <beckfordp@...>
Date: Fri Apr 3, 2009 1:29 pm
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
beckfordp...
Send Email Send Email
 
Hi Torbjörn,

I agree with you too, and I also believe that Kanban is a useful tool in the
right hands.

Interestingly, I prefer to use a task board aswell, and I much prefer index
cards over digital systems also. These discussions have an habit of becoming
polarised, and in another context I could as easily have been arguing the
benefits of using Kanban (using the term "Kanban" to refer to the practice of
using a token as a signal to limit work in progress, not Kanban as a process
that eschews iterations).

Its the silver-bullet idea, that the tool is the solution that gets my goat :)

Regards,

Paul.


> I always opt for physical taskboards (I haven't had the luxury of
> using kanban for a "live" project) over digital ones. Physicly moving
> cards give a much stronger impression than point and click
> accomplishes. The true goal is to get commitment and buy-in, having
> something to hold on to seems to aid that so I advocate using it.
>
> It's always easy to misstake the aid for the thing. That's when I need
> peers gently reminding me of our true goal, working software, over our
> aid, moving tasks to done.
>
> All the best,
> Torbjörn
>
> > Regards,
> >
> > Paul.
> >
> >
>

#2184 From: Karl Scotland <kjscotland@...>
Date: Fri Apr 3, 2009 9:07 pm
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
kjscotland
Send Email Send Email
 
Hi Paul

2009/4/3 beckfordp@... <beckfordp@...>

Its the silver-bullet idea, that the tool is the solution that gets my goat :)

I've not had time to read all today's mails in detail, but this caught my eye. Who is saying kanban is a silver bullet?

It feels like you description of kanban could be compared to someone who says Scrum is just about Sprints.

Karl
 
--
Karl Scotland
Agile Coach
http://availagility.wordpress.com/

#2185 From: "beckfordp@..." <beckfordp@...>
Date: Fri Apr 3, 2009 9:32 pm
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
beckfordp...
Send Email Send Email
 
--- In kanbandev@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:
>
> Hi Paul
>
> 2009/4/3 beckfordp@... <beckfordp@...>
>
> >
> > Its the silver-bullet idea, that the tool is the solution that gets my goat
> > :)
>
>
> I've not had time to read all today's mails in detail, but this caught my
> eye. Who is saying kanban is a silver bullet?
>
> It feels like you description of kanban could be compared to someone who
> says Scrum is just about Sprints.
>
> Karl
>
> --
> Karl Scotland
> Agile Coach
> http://availagility.wordpress.com/
>
Hi Karl,

Long story. I haven't described Kanban at all. What I've described is how Kanban
is being sold. A more accurate comparison would be to someone who says that
Scrum is all about making $$$$. To be honest I think I've heard all I need to
hear.

Good luck with the conference.

Best Regards,

Paul.

#2186 From: "davenicolette" <davenicolette@...>
Date: Fri Apr 3, 2009 10:30 pm
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
davenicolette
Send Email Send Email
 
--- In kanbandev@yahoogroups.com, "beckfordp@..." <beckfordp@...> wrote:
>
> To be honest I think I've heard all I need to hear.

Perhaps, but to whom have you been listening?

#2187 From: Karl Scotland <kjscotland@...>
Date: Sat Apr 4, 2009 11:31 am
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
kjscotland
Send Email Send Email
 


2009/4/3 beckfordp@... <beckfordp@...>
--- In kanbandev@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:

Long story. I haven't described Kanban at all. What I've described is how Kanban is being sold. A more accurate comparison would be to someone who says that Scrum is all about making $$$$. To be honest I think I've heard all I need to hear.

Who is "selling" kanban then?  Personally, I have found it useful, and as there is little written, and much misunderstanding, I am trying to widen awareness as I think its a useful thing to have in the toolbag. I'm making no money out of it though.

How do we increase awareness and understanding without looking like we're "selling"?

Karl

--
Karl Scotland
Agile Coach
http://availagility.wordpress.com/

#2188 From: brucemount@...
Date: Sat Apr 4, 2009 7:39 am
Subject: Re: Re: Fellow travelers, it is time to free kanban from the sha...
brucemount
Send Email Send Email
 

Scrum is all about making $$$$. To be honest I think I've heard all I need to hear.


I have to say that I agree that certain methodologies (UML, Scrum, Six Sigma) may have started with good intentions, but now seem to merely be money making industries that resist change to protect their business.

What I like about Kanban is it's inherent simplicity, but in terms of making it work and because it is a natural hedge against it become a "business" that subverts the original intent.

Sure, a few people (David) make money talking about it and that does not bother me a bit.....his comments and writings have help a LOT of people, including me.  Karl Scotland has also very kindly shared slides with me at no cost, even though I'm sure it took him considerable time to create them (thank you yet again).

--Bruce



**************
Hurry! April 15th is almost here. File your Federal taxes FREE with TaxACT. (http://pr.atwola.com/promoclk/100126575x1220239440x1201335902/aol?redir=http:%2F%2Fwww.taxact.com%2F08tax.asp%3Fsc%3D084102950001%26p%3D82)

#2189 From: "davenicolette" <davenicolette@...>
Date: Sat Apr 4, 2009 1:32 pm
Subject: Re: Fellow travelers, it is time to free kanban from the sha...
davenicolette
Send Email Send Email
 
Any time an idea, process, product, or whatever starts to get popular, some
people will take advantage of the popularity to try and make a quick buck. I
think it's foolish to assume that once that starts to happen, the whole idea,
process, product, or whatever suddenly loses all credibility and usefulness.
It's also foolish to think that people ought not earn their living by applying
the knowledge and skills they happen to have, just to avoid giving the
impression they're greedy.

Cheers,
Dave

--- In kanbandev@yahoogroups.com, brucemount@... wrote:
>
>
> > Scrum is all about making $$$$. To be honest I think I've heard all I need
> > to hear.
>
> I have to say that I agree that certain methodologies (UML, Scrum, Six Sigma)
> may have started with good intentions, but now seem to merely be money making
> industries that resist change to protect their business.
>
> What I like about Kanban is it's inherent simplicity, but in terms of making
> it work and because it is a natural hedge against it become a "business" that
> subverts the original intent.
>
> Sure, a few people (David) make money talking about it and that does not
> bother me a bit.....his comments and writings have help a LOT of people,
including
> me.  Karl Scotland has also very kindly shared slides with me at no cost,
> even though I'm sure it took him considerable time to create them (thank you
yet
> again).
>
> --Bruce
>
>
>
> **************
> Hurry! April 15th is almost here. File your Federal taxes FREE
> with TaxACT.
>
(http://pr.atwola.com/promoclk/100126575x1220239440x1201335902/aol?redir=http:%2\
F%2Fwww.taxact.com%2F08tax.asp%3Fsc%3D084102950001%26p%3D82)
>

#2190 From: Greg Young <gregoryyoung1@...>
Date: Sat Apr 4, 2009 3:36 pm
Subject: Re: Re: Fellow travelers, it is time to free kanban from the sha...
gumboismadeo...
Send Email Send Email
 
How awesome that as I read this thread google shows me...

"Six Sigma's Average $100K - VillanovaU.com/SixSigma - Villanova Six
Sigma Certification Get In Demand Skills. Get Ahead"



On Sat, Apr 4, 2009 at 7:39 AM,  <brucemount@...> wrote:
>
> Scrum is all about making $$$$. To be honest I think I've heard all I need
> to hear.
>
> I have to say that I agree that certain methodologies (UML, Scrum, Six
> Sigma) may have started with good intentions, but now seem to merely be
> money making industries that resist change to protect their business.
>
> What I like about Kanban is it's inherent simplicity, but in terms of making
> it work and because it is a natural hedge against it become a "business"
> that subverts the original intent.
>
> Sure, a few people (David) make money talking about it and that does not
> bother me a bit.....his comments and writings have help a LOT of people,
> including me.  Karl Scotland has also very kindly shared slides with me at
> no cost, even though I'm sure it took him considerable time to create them
> (thank you yet again).
>
> --Bruce
>
>
>
> **************
> Hurry! April 15th is almost here. File your Federal taxes FREE with TaxACT.
>
(http://pr.atwola.com/promoclk/100126575x1220239440x1201335902/aol?redir=http:%2\
F%2Fwww.taxact.com%2F08tax.asp%3Fsc%3D084102950001%26p%3D82)
>
>



--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

#2191 From: "rob_hathaway74" <rob.hathaway@...>
Date: Mon Apr 6, 2009 10:38 am
Subject: Only plan for what the team can produce
rob_hathaway74
Send Email Send Email
 
To me it seems like people look at Kanban and assume it means no estimation and
even planning...can I offer a different view:

In a waterfall process we do all our planning upfront in a single big batch. In
an Agile process we dramatically reduce the batch sizes into iteration sized
chunks.

One way of reducing the batch size from iterations in agile is to have a trigger
level of completed stories to do more planning. For example create a "planning"
buffer on the board and fix it to 3 slots (3 can be substituted with the average
number of stories your teams complete in a week). The team can pull stories from
this buffer as they complete stories in play.

As stories get pulled from the "planning" queue it is the trigger to do more
planning. At worst you do the planning when the last story is pulled from the
planning queue and it becomes empty.

Planning can now be conducted when the team is ready for it. We don't need big
fixed planning meetings..we can make them smaller, quicker and more focused but,
we're still doing planning. Stories can now start and finish as resource becomes
available. If I've got the relevant engineering practices in place I can release
a story as it's completed instead of waiting till the end of an iteration to do
a release. Changes become easier to deal with less effort having been used.

Do we still need to estimate? Guessing what might be done on a software project
in a specific time period is just a guess and I'm not sure how a team can
operate effectively based on guesswork. The process described above is based on
real completion not on guesswork.

This isn't the only way to do it - just a potentially different way of looking
at planning and reducing the batch sizes in software development. Discuss away.

Rob

#2192 From: "Landes Eric (CI/CER-NA)" <eric.landes@...>
Date: Mon Apr 6, 2009 5:38 pm
Subject: ANN Lean & Kanban Conference - You can still get early bird pricing until April 13th!
dcma_eric
Send Email Send Email
 
Agenda & Program
================

Quite simply the greatest ever assembled group of experts in Lean
software development will be convening in Miami in May to explore the
frontiers of agile and lean in software development. This is your
chance to be a part of the new wave in agile development and
management practices.

Speakers include: Alan Shalloway, Dean Leffingwell, Peter Middleton,
James Sutton, Corey Ladas, Karl Scotland, Amit Rathore, Sterling
Mortensen, Aaron Sanders, Rob Hathaway, Alisson Vale, Max Keeler,
Linda Cook, Eric Landes, Eric Willeke, Chris Shinkle and David Laribee.

The final conference agenda has been released. You can download it here.
http://www.leankanbanconference.com/agenda.pdf

along with the program (draft) released yesterday
http://www.leankanbanconference.com/LeanKanbanProgram.pdf

The new conference format provides Day 1 - May 6th - as a Lean Day and
Day 2 - May 7th - as a Kanban specific day. Day 3 will be open space
and lightning talks.

Pricing
=======
Today we are announcing exciting new pricing for the Lean & Kanban
Conference. We're responding to market feedback and making the event
more accessible.

Full Registration
-----------------

Until March 16th full registration for all 3 days will be offered at
the super low price of $550. All existing registrants will be
receiving a refund in the next few days of the difference between the
previous amount and the new $550 super early bird rate.

After March 16th early bird registration will be $700 until April 16th
after which time the full $800 price will apply.

Register now at http://www.leankanbanconference.com/

Agile Florida special rate
--------------------------

Members of an Agile Florida User's Group can make use of the Super
Early Bird price as a special discount until April 16th. Membership of
an agile group in Florida and residency in Florida (based on Credit
Card details) are required to qualify.

Register now at http://www.leankanbanconference.com/

Lean Day Only Registration - May 6th
------------------------------------

For those who only want to attend the Lean sessions at the conference,
we are offering a special one day rate that will include the evening
reception. The price for this is $335. Register now at
http://www.leankanbanconference.com/

Kanban Day Only Registration - May 7th
--------------------------------------

For those who only wish to attend the Kanban case study presentations,
we are offering a special one day rate of $295. Register now at
http://www.leankanbanconference.com/


Please bear in mind that the numbers at the event are strictly
limited. Please register early to avoid disappointment.

http://www.leankanbanconference.com/

#2193 From: Brian Marick <marick@...>
Date: Tue Apr 7, 2009 3:44 pm
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
briandawnpau...
Send Email Send Email
 
On Apr 4, 2009, at 6:31 AM, Karl Scotland wrote:

> Who is "selling" kanban then?  Personally, I have found it useful,
> and as there is little written, and much misunderstanding, I am
> trying to widen awareness as I think its a useful thing to have in
> the toolbag. I'm making no money out of it though.
>
> How do we increase awareness and understanding without looking like
> we're "selling"?


I'm interested in that question, because I was (largely by accident)
one of the authors of the Agile Manifesto, and the accusations of it
being only a marketing scheme came quickly. The way I deal with it is:

- I paint a glowing picture when I talk to a team about what Agile
would be like (because I've seen teams that live in that picture), but
I make sure to emphasize that it's hard work to get there. (For
example, I sometimes talk to teams about working their way out of a
legacy code mess using the "Strangler App" strategy
<http://martinfowler.com/bliki/StranglerApplication.html>. I use Lisa
Crispin's team as an example and note that it took them years to get
their code base where they wanted. Salespeople don't usually say
things like "... and because of our advanced technology, you can have
results in only years!")

- I talk about what I don't know as well as what I know. I make a
fetish out of telling people that I expect the me five years from now
to look back at the me of today and say, "Wow, was *he* ever naive!"

- I make it clear that I have my own biases and prejudices that
attract me to Agile, that my process is in part due to my personality
<http://www.exampler.com/testing-com/writings/process-and-personality.html
  >.

- I talk about teams I've worked with directly. What people are
worried about is the sort of person who swoops in, convinces
management, installs some rote training, and flies off - without ever
having contact with the day-to-day problems on the ground.

- It's helpful (at the team level) that I'm reasonably active in the
Ruby world. People are reassured that I do things other than spout off
about process. (There's that prejudice that those who can't do, teach.)

- I worry that I'm being overbearing, and I hope that makes me less
overbearing. My advice to writers and speakers: if you can't think of
a recent instance where you used "proof by authority" or "proof by
vigorous assertion" or otherwise ran roughshod over people, you're
unconsciously being a jerk.

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

#2194 From: "chrisjmatts1968" <chris.matts@...>
Date: Wed Apr 8, 2009 10:58 am
Subject: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
chrisjmatts1968
Send Email Send Email
 
Thank you Brian, this is a great post.

I'd like to pick out the Martin Fowler example and expand.

I was fortunate to work at ThoughtWorks and observe Martin a little closer than
others as a result. The example article you chose highlights what Martin does so
well. He chronicles events in IT. What is more, he shines a light on those that
made the breakthrough ( Chris Stevenson and team ) and ensures they get the
recognition. We used to joke that Martin was ThoughtWorks company secretary but
it goes deeper than that. When you see Martin give a keynote, he often
introduces a colleague ( Dan North, Erik D, ....) and then steps back to let
them speak. He does not sell himself, he uses his profile to raise the profile
of others.

He points to the work of others and acknowledges it.

I attended a session at a conference where someone I know gave a presentation.
It got a little embarressing because the presenter kept mentioning me because
quite a bit of it was stuff I introduced them to. If I'm honest I was quite
chuffed to get a couple of mentions. I saw that the same person was on a popular
IT webzine presenting the same material and vanity got the better of me. I
watched it. This time I did not get a single mention, and I realised the reason
I got mentioned before was because I was in the room. Why did they do it? They
were selling themselves and they wanted people to assume they "discovered" the
material.

For me, Integrity "Sells". Acknowledging the source of our knowledge or
inspiration is one way of achieving it.

Letting others assume we "discovered" something is "selling" in a bad way.
Letting people think we are the best at it, or discovered it is selling
ourselves.

David and others have been promoting Kanban for a couple of years now.
Promoting, not selling.

Last week I saw a salesman punting Scrum. Selling an out of date process as the
silver bullet.

I just hope we close the group before we reach the sales culture as I do not
think we are there yet.

Chris

--- In kanbandev@yahoogroups.com, Brian Marick <marick@...> wrote:
>
>
> On Apr 4, 2009, at 6:31 AM, Karl Scotland wrote:
>
> > Who is "selling" kanban then?  Personally, I have found it useful,
> > and as there is little written, and much misunderstanding, I am
> > trying to widen awareness as I think its a useful thing to have in
> > the toolbag. I'm making no money out of it though.
> >
> > How do we increase awareness and understanding without looking like
> > we're "selling"?
>
>
> I'm interested in that question, because I was (largely by accident)
> one of the authors of the Agile Manifesto, and the accusations of it
> being only a marketing scheme came quickly. The way I deal with it is:
>
> - I paint a glowing picture when I talk to a team about what Agile
> would be like (because I've seen teams that live in that picture), but
> I make sure to emphasize that it's hard work to get there. (For
> example, I sometimes talk to teams about working their way out of a
> legacy code mess using the "Strangler App" strategy
> <http://martinfowler.com/bliki/StranglerApplication.html>. I use Lisa
> Crispin's team as an example and note that it took them years to get
> their code base where they wanted. Salespeople don't usually say
> things like "... and because of our advanced technology, you can have
> results in only years!")
>
> - I talk about what I don't know as well as what I know. I make a
> fetish out of telling people that I expect the me five years from now
> to look back at the me of today and say, "Wow, was *he* ever naive!"
>
> - I make it clear that I have my own biases and prejudices that
> attract me to Agile, that my process is in part due to my personality
> <http://www.exampler.com/testing-com/writings/process-and-personality.html
>  >.
>
> - I talk about teams I've worked with directly. What people are
> worried about is the sort of person who swoops in, convinces
> management, installs some rote training, and flies off - without ever
> having contact with the day-to-day problems on the ground.
>
> - It's helpful (at the team level) that I'm reasonably active in the
> Ruby world. People are reassured that I do things other than spout off
> about process. (There's that prejudice that those who can't do, teach.)
>
> - I worry that I'm being overbearing, and I hope that makes me less
> overbearing. My advice to writers and speakers: if you can't think of
> a recent instance where you used "proof by authority" or "proof by
> vigorous assertion" or otherwise ran roughshod over people, you're
> unconsciously being a jerk.
>
> -----
> Brian Marick, independent consultant
> Mostly on agile methods with a testing slant
> www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>

#2195 From: brucemount@...
Date: Wed Apr 8, 2009 7:08 am
Subject: Have any stats on complexity of larger projects?
brucemount
Send Email Send Email
 
Kanbaners:

I am trying to persuade people at Harvard that doing many smaller projects (e.g., Kanban style) is often less risky than a few large projects.

Their argument is that there is an economy of scale by combining multiple features into a single large release.  I agree that that is true in some cases, but often the features have little overlap other than they are part of the same product.

They feel that the risk goes up linearly as the number of features in the release increases.  I remember seeing stats a long time ago showing that the risk goes up exponentially as the number of features increase.

Does anyone have any stats that compare risk versus release size?

Thanks,

--Bruce Mount
  Harvard's Academic Technology Group
  Cambridge, MA



**************
New Deals on Dell Netbooks – Now starting at $299 (A HREF=http://pr.atwola.com/promoclk/100126575x1219939010x1201342897/aol?redir=http:%2F%2Fad.doubleclick.net%2Fclk%3B213771626%3B35379597%3Bw)

#2196 From: Sarath Kummamuru <kcsarath@...>
Date: Wed Apr 8, 2009 11:30 am
Subject: Re: Have any stats on complexity of larger projects?
kcsarath
Send Email Send Email
 
I thought one of the big advantage of using scrum or other agile processes with small iterations was to reduce this risk and sort of mitigate the risk.

There are no longer LARGE projects or LARGE releases in my opinion. ATleast from a team perspective, it is only high quality code delivered sprint after sprint.
Allowing the product owner to decide when they want to release.

This has worked for me esp with project teams that have been about to include test automation for regression into their sprints. Even other wise at regular intervals with a few stabilization/regression/release sprints, teams can deliver pretty good quality product leaving the decision of when to actually make the release to the Product Owner.

Please correct me if i am wrong in saying that short 2 week iterations mitigate the risks of large releases. While this is an ideal situation, I have coached teams that have achieved this to a decent extent with some interim Stabilization or regression sprints before the actual release.

Thanks,
Sarath.

On Wed, Apr 8, 2009 at 4:38 PM, <brucemount@...> wrote:

Kanbaners:

I am trying to persuade people at Harvard that doing many smaller projects (e.g., Kanban style) is often less risky than a few large projects.

Their argument is that there is an economy of scale by combining multiple features into a single large release.  I agree that that is true in some cases, but often the features have little overlap other than they are part of the same product.

They feel that the risk goes up linearly as the number of features in the release increases.  I remember seeing stats a long time ago showing that the risk goes up exponentially as the number of features increase.

Does anyone have any stats that compare risk versus release size?

Thanks,

--Bruce Mount
  Harvard's Academic Technology Group
  Cambridge, MA



**************
New Deals on Dell Netbooks – Now starting at $299 (A HREF=http://pr.atwola.com/promoclk/100126575x1219939010x1201342897/aol?redir=http:%2F%2Fad.doubleclick.net%2Fclk%3B213771626%3B35379597%3Bw)




--
Thanks,
Sarath.

Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com

#2197 From: Giovanni Asproni <aspro@...>
Date: Wed Apr 8, 2009 11:36 am
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
superaspro
Send Email Send Email
 
chrisjmatts1968 wrote:
>
> I attended a session at a conference where someone I know gave a
> presentation. It got a little embarressing because the presenter kept
> mentioning me because quite a bit of it was stuff I introduced them to.
> If I'm honest I was quite chuffed to get a couple of mentions. I saw
> that the same person was on a popular IT webzine presenting the same
> material and vanity got the better of me. I watched it. This time I did
> not get a single mention, and I realised the reason I got mentioned
> before was because I was in the room. Why did they do it? They were
> selling themselves and they wanted people to assume they "discovered"
> the material.
>
> For me, Integrity "Sells". Acknowledging the source of our knowledge or
> inspiration is one way of achieving it.
>
> Letting others assume we "discovered" something is "selling" in a bad
> way. Letting people think we are the best at it, or discovered it is
> selling ourselves.
>
> David and others have been promoting Kanban for a couple of years now.
> Promoting, not selling.
>
> Last week I saw a salesman punting Scrum. Selling an out of date process
> as the silver bullet.
>
> I just hope we close the group before we reach the sales culture as I do
> not think we are there yet.

I think we are giving the word "sell" an unnecessarily bad connotation.

I think selling is fine, and making money out of what we sell (or promote) is
fine.

What I do not accept is doing it without integrity--like the guy in your example
above does.

Personally, among other services, I "sell" Scrum (i.e., make money by coaching
teams), but
I never, ever, make promises I cannot possibly keep--e.g., use Scrum and every
day will
be a sunny day--I always try to make it clear what the problems can (or will)
be,
and I always give credit to whoever deserves it.

Summarizing, I think that selling something can be a good thing, the *way* we do
it can
make it a very bad one.

G

>
> Chris
>
> --- In kanbandev@yahoogroups.com <mailto:kanbandev%40yahoogroups.com>,
> Brian Marick <marick@...> wrote:
>  >
>  >
>  > On Apr 4, 2009, at 6:31 AM, Karl Scotland wrote:
>  >
>  > > Who is "selling" kanban then? Personally, I have found it useful,
>  > > and as there is little written, and much misunderstanding, I am
>  > > trying to widen awareness as I think its a useful thing to have in
>  > > the toolbag. I'm making no money out of it though.
>  > >
>  > > How do we increase awareness and understanding without looking like
>  > > we're "selling"?
>  >
>  >
>  > I'm interested in that question, because I was (largely by accident)
>  > one of the authors of the Agile Manifesto, and the accusations of it
>  > being only a marketing scheme came quickly. The way I deal with it is:
>  >
>  > - I paint a glowing picture when I talk to a team about what Agile
>  > would be like (because I've seen teams that live in that picture), but
>  > I make sure to emphasize that it's hard work to get there. (For
>  > example, I sometimes talk to teams about working their way out of a
>  > legacy code mess using the "Strangler App" strategy
>  > <http://martinfowler.com/bliki/StranglerApplication.html
> <http://martinfowler.com/bliki/StranglerApplication.html>>. I use Lisa
>  > Crispin's team as an example and note that it took them years to get
>  > their code base where they wanted. Salespeople don't usually say
>  > things like "... and because of our advanced technology, you can have
>  > results in only years!")
>  >
>  > - I talk about what I don't know as well as what I know. I make a
>  > fetish out of telling people that I expect the me five years from now
>  > to look back at the me of today and say, "Wow, was *he* ever naive!"
>  >
>  > - I make it clear that I have my own biases and prejudices that
>  > attract me to Agile, that my process is in part due to my personality
>  >
> <http://www.exampler.com/testing-com/writings/process-and-personality.html
> <http://www.exampler.com/testing-com/writings/process-and-personality.html>
>  > >.
>  >
>  > - I talk about teams I've worked with directly. What people are
>  > worried about is the sort of person who swoops in, convinces
>  > management, installs some rote training, and flies off - without ever
>  > having contact with the day-to-day problems on the ground.
>  >
>  > - It's helpful (at the team level) that I'm reasonably active in the
>  > Ruby world. People are reassured that I do things other than spout off
>  > about process. (There's that prejudice that those who can't do, teach.)
>  >
>  > - I worry that I'm being overbearing, and I hope that makes me less
>  > overbearing. My advice to writers and speakers: if you can't think of
>  > a recent instance where you used "proof by authority" or "proof by
>  > vigorous assertion" or otherwise ran roughshod over people, you're
>  > unconsciously being a jerk.
>  >
>  > -----
>  > Brian Marick, independent consultant
>  > Mostly on agile methods with a testing slant
>  > www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>  >
>
>

--
Giovanni Asproni                 Email: gasproni@...
Director, Asprotunity Limited    Mobile: +44 (0)791 746 0453
http://www.asprotunity.com       Phone: +44 (0)207 788 7649
http://www.giovanniasproni.com   Fax: +44 (0)870 762 3212

#2198 From: "chrisjmatts1968" <chris.matts@...>
Date: Wed Apr 8, 2009 12:44 pm
Subject: Re: Have any stats on complexity of larger projects?
chrisjmatts1968
Send Email Send Email
 
Hi Bruce

Risk is a misunderstood term. When talking about risk, we need to be specific
about the kind of risk we are concerned with. More in a mo.

When they claim there is an economy of scale, what savings are they claiming?
Consider three releases being grouped into one major release. The savings
are....

1. One release instead of three. Hence two times cost of a release.
2. One regression test instead of three. Hence two times cost of regression
cycle.

Both of these should be pragmatically automated.

With a larger release there will be more new code and more new bugs and hence
more regression cycles. Hence the regression saving is not as large as you would
expect anyway.

Also if you do something often, you should get faster and better at it.

So the saving is two releases ( small ) plus significantly less than two
regression cycles.

The disadvantage of larger less frequent releases is that you tend not to
improve as much.

Now lets look at the risks.

Smaller changes have less chance of breaking something as less things are
changed. The biggest risk in IT is normally that you break the existing business
model.

Next is the risk that your business model is flawed. We can mitigate that by
creating exploratory releases to test the model. e.g. If your sales guys says
you can sell 1000 units, release a version to allow you to sell 10 units. If you
sell none, scrap it and if you sell lots, then scale.

Most people when discussing risk focus on delivery risk. The risk of getting the
software out on schedule/on budget/etc. I recommend
http://www.toddlittleweb.com/Papers/Little%20Cone%20of%20Uncertainty.pdf

When you group features together, the release happens when the final feature is
ready to ship..... unless you can switch them off. ( The Marvel Summertime
Crossover Event ). Compounding the delivery risk on multiple features is not
straight forward as you need to consider the constraints in the system.

Regards

Chris

--- In kanbandev@yahoogroups.com, brucemount@... wrote:
>
> Kanbaners:
>
> I am trying to persuade people at Harvard that doing many smaller projects
> (e.g., Kanban style) is often less risky than a few large projects.
>
> Their argument is that there is an economy of scale by combining multiple
> features into a single large release.  I agree that that is true in some
cases,
> but often the features have little overlap other than they are part of the
same
> product.
>
> They feel that the risk goes up linearly as the number of features in the
> release increases.  I remember seeing stats a long time ago showing that the
risk
> goes up exponentially as the number of features increase.
>
> Does anyone have any stats that compare risk versus release size?
>
> Thanks,
>
> --Bruce Mount
>   Harvard's Academic Technology Group
>   Cambridge, MA
>
>
>
> **************
> New Deals on Dell Netbooks â€" Now starting at $299 (A
>
HREF=http://pr.atwola.com/promoclk/100126575x1219939010x1201342897/aol?redir=htt\
p:%2F%2Fa
> d.doubleclick.net%2Fclk%3B213771626%3B35379597%3Bw)
>

#2199 From: Greg Young <gregoryyoung1@...>
Date: Wed Apr 8, 2009 1:23 pm
Subject: Re: Re: Fellow travelers, it is time to free kanban from the shackles of its origin!
gumboismadeo...
Send Email Send Email
 
I would agree with this assessment based on my experiences with Martin as well.

Greg

On Wed, Apr 8, 2009 at 6:58 AM, chrisjmatts1968 <chris.matts@...> wrote:
> Thank you Brian, this is a great post.
>
> I'd like to pick out the Martin Fowler example and expand.
>
> I was fortunate to work at ThoughtWorks and observe Martin a little closer
> than others as a result. The example article you chose highlights what
> Martin does so well. He chronicles events in IT. What is more, he shines a
> light on those that made the breakthrough ( Chris Stevenson and team ) and
> ensures they get the recognition. We used to joke that Martin was
> ThoughtWorks company secretary but it goes deeper than that. When you see
> Martin give a keynote, he often introduces a colleague ( Dan North, Erik D,
> ....) and then steps back to let them speak. He does not sell himself, he
> uses his profile to raise the profile of others.
>
> He points to the work of others and acknowledges it.
>
> I attended a session at a conference where someone I know gave a
> presentation. It got a little embarressing because the presenter kept
> mentioning me because quite a bit of it was stuff I introduced them to. If
> I'm honest I was quite chuffed to get a couple of mentions. I saw that the
> same person was on a popular IT webzine presenting the same material and
> vanity got the better of me. I watched it. This time I did not get a single
> mention, and I realised the reason I got mentioned before was because I was
> in the room. Why did they do it? They were selling themselves and they
> wanted people to assume they "discovered" the material.
>
> For me, Integrity "Sells". Acknowledging the source of our knowledge or
> inspiration is one way of achieving it.
>
> Letting others assume we "discovered" something is "selling" in a bad way.
> Letting people think we are the best at it, or discovered it is selling
> ourselves.
>
> David and others have been promoting Kanban for a couple of years now.
> Promoting, not selling.
>
> Last week I saw a salesman punting Scrum. Selling an out of date process as
> the silver bullet.
>
> I just hope we close the group before we reach the sales culture as I do not
> think we are there yet.
>
> Chris
>
> --- In kanbandev@yahoogroups.com, Brian Marick <marick@...> wrote:
>>
>>
>> On Apr 4, 2009, at 6:31 AM, Karl Scotland wrote:
>>
>> > Who is "selling" kanban then? Personally, I have found it useful,
>> > and as there is little written, and much misunderstanding, I am
>> > trying to widen awareness as I think its a useful thing to have in
>> > the toolbag. I'm making no money out of it though.
>> >
>> > How do we increase awareness and understanding without looking like
>> > we're "selling"?
>>
>>
>> I'm interested in that question, because I was (largely by accident)
>> one of the authors of the Agile Manifesto, and the accusations of it
>> being only a marketing scheme came quickly. The way I deal with it is:
>>
>> - I paint a glowing picture when I talk to a team about what Agile
>> would be like (because I've seen teams that live in that picture), but
>> I make sure to emphasize that it's hard work to get there. (For
>> example, I sometimes talk to teams about working their way out of a
>> legacy code mess using the "Strangler App" strategy
>> <http://martinfowler.com/bliki/StranglerApplication.html>. I use Lisa
>> Crispin's team as an example and note that it took them years to get
>> their code base where they wanted. Salespeople don't usually say
>> things like "... and because of our advanced technology, you can have
>> results in only years!")
>>
>> - I talk about what I don't know as well as what I know. I make a
>> fetish out of telling people that I expect the me five years from now
>> to look back at the me of today and say, "Wow, was *he* ever naive!"
>>
>> - I make it clear that I have my own biases and prejudices that
>> attract me to Agile, that my process is in part due to my personality
>> <http://www.exampler.com/testing-com/writings/process-and-personality.html
>> >.
>>
>> - I talk about teams I've worked with directly. What people are
>> worried about is the sort of person who swoops in, convinces
>> management, installs some rote training, and flies off - without ever
>> having contact with the day-to-day problems on the ground.
>>
>> - It's helpful (at the team level) that I'm reasonably active in the
>> Ruby world. People are reassured that I do things other than spout off
>> about process. (There's that prejudice that those who can't do, teach.)
>>
>> - I worry that I'm being overbearing, and I hope that makes me less
>> overbearing. My advice to writers and speakers: if you can't think of
>> a recent instance where you used "proof by authority" or "proof by
>> vigorous assertion" or otherwise ran roughshod over people, you're
>> unconsciously being a jerk.
>>
>> -----
>> Brian Marick, independent consultant
>> Mostly on agile methods with a testing slant
>> www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>>
>
>



--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

#2200 From: Henrik Kniberg <henrik.kniberg@...>
Date: Wed Apr 8, 2009 4:53 pm
Subject: Kanban vs Scrum
hkniberg
Send Email Send Email
 
Hi all! Here's an attempt to clarify how Kanban and Scrum relate to
each other in objective terms - how are they similar, how are they
different, how can they be combined, etc. I keep getting that question
when I explain Kanban to people, so it feels like a relevant topic.

http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html

It's a draft, any feedback is welcome!

If anybody wants to meet & discuss this type of stuff feel free to
join me and David Anderson on May 27.
http://www.crisp.se/futureofagile.

Cheers,

/Henrik

--
Henrik Kniberg
http://www.crisp.se
+46 (0)70 492 5284

#2201 From: Lisa Crispin <lisa.crispin@...>
Date: Wed Apr 8, 2009 5:15 pm
Subject: Re: Kanban vs Scrum
lisa_crispin...
Send Email Send Email
 
Henrik, as I'm interested in Kanban but don't know much about it, this is extremely helpful.

Our Scrum is definitely moving in a Kanban direction. I'd love to hear from teams who were doing Scrum successfully for a long time and migrated to Kanban, how/why they did that and how it worked for them. (Maybe there are threads on this list about that, I've only just recently joined it).

-- Lisa

On Wed, Apr 8, 2009 at 10:53 AM, Henrik Kniberg <henrik.kniberg@...> wrote:


Hi all! Here's an attempt to clarify how Kanban and Scrum relate to
each other in objective terms - how are they similar, how are they
different, how can they be combined, etc. I keep getting that question
when I explain Kanban to people, so it feels like a relevant topic.

http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html

It's a draft, any feedback is welcome!

If anybody wants to meet & discuss this type of stuff feel free to
join me and David Anderson on May 27.
http://www.crisp.se/futureofagile.

Cheers,

/Henrik

--
Henrik Kniberg
http://www.crisp.se
+46 (0)70 492 5284




--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers and Agile Teams_ (Addison-Wesley 2009)
http://lisacrispin.com


#2202 From: Torbjörn Gyllebring <torbjorn.gyllebring@...>
Date: Wed Apr 8, 2009 5:48 pm
Subject: Re: Kanban vs Scrum
torbjorn.gyl...
Send Email Send Email
 
Great read, and I think the most important point is stated last. Begin
with the retrospectives. :)

And I think teams not so much migrate but evolve, or refactor their
process towards Kanban or to more rigours, prescribing, systems. From
my limited experience the movement direction seems to mostly be a
consequence of organizational maturity and trust. High trust solution
oriented groups and teams seems to be moving towards looser control
and flow and more cautious groupings seems to prefer the illusion of
control that clearly prescribed roles gives.

On Wed, Apr 8, 2009 at 7:15 PM, Lisa Crispin <lisa.crispin@...> wrote:
> Henrik, as I'm interested in Kanban but don't know much about it, this is
> extremely helpful.
>
> Our Scrum is definitely moving in a Kanban direction. I'd love to hear from
> teams who were doing Scrum successfully for a long time and migrated to
> Kanban, how/why they did that and how it worked for them. (Maybe there are
> threads on this list about that, I've only just recently joined it).
>
> -- Lisa
>
> On Wed, Apr 8, 2009 at 10:53 AM, Henrik Kniberg <henrik.kniberg@...>
> wrote:
>>
>>
>> Hi all! Here's an attempt to clarify how Kanban and Scrum relate to
>> each other in objective terms - how are they similar, how are they
>> different, how can they be combined, etc. I keep getting that question
>> when I explain Kanban to people, so it feels like a relevant topic.
>>
>> http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
>>
>> It's a draft, any feedback is welcome!
>>
>> If anybody wants to meet & discuss this type of stuff feel free to
>> join me and David Anderson on May 27.
>> http://www.crisp.se/futureofagile.
>>
>> Cheers,
>>
>> /Henrik
>>
>> --
>> Henrik Kniberg
>> http://www.crisp.se
>> +46 (0)70 492 5284
>
>
>
> --
> Lisa Crispin
> Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
> and Agile Teams_ (Addison-Wesley 2009)
> http://lisacrispin.com
>
>

#2203 From: "jdn3times" <jdn3times@...>
Date: Wed Apr 8, 2009 5:57 pm
Subject: Re: Fellow travelers, it is time to free kanban from the sha...
jdn3times
Send Email Send Email
 
I agree.  Obviously, due to Recent Events (TM), people are skeptical, cynical,
cranky, etc. but there is nothing wrong with making money doing something you
enjoy and think is right.  Frankly, it is rare when people can make a living
doing something they enjoy, most people just get by.

jdn

--- In kanbandev@yahoogroups.com, "davenicolette" <davenicolette@...> wrote:
>
> Any time an idea, process, product, or whatever starts to get popular, some
people will take advantage of the popularity to try and make a quick buck. I
think it's foolish to assume that once that starts to happen, the whole idea,
process, product, or whatever suddenly loses all credibility and usefulness.
It's also foolish to think that people ought not earn their living by applying
the knowledge and skills they happen to have, just to avoid giving the
impression they're greedy.
>
> Cheers,
> Dave
>
> --- In kanbandev@yahoogroups.com, brucemount@ wrote:
> >
> >
> > > Scrum is all about making $$$$. To be honest I think I've heard all I need
> > > to hear.
> >
> > I have to say that I agree that certain methodologies (UML, Scrum, Six
Sigma)
> > may have started with good intentions, but now seem to merely be money
making
> > industries that resist change to protect their business.
> >
> > What I like about Kanban is it's inherent simplicity, but in terms of making
> > it work and because it is a natural hedge against it become a "business"
that
> > subverts the original intent.
> >
> > Sure, a few people (David) make money talking about it and that does not
> > bother me a bit.....his comments and writings have help a LOT of people,
including
> > me.  Karl Scotland has also very kindly shared slides with me at no cost,
> > even though I'm sure it took him considerable time to create them (thank you
yet
> > again).
> >
> > --Bruce
> >
> >
> >
> > **************
> > Hurry! April 15th is almost here. File your Federal taxes FREE
> > with TaxACT.
> >
(http://pr.atwola.com/promoclk/100126575x1220239440x1201335902/aol?redir=http:%2\
F%2Fwww.taxact.com%2F08tax.asp%3Fsc%3D084102950001%26p%3D82)
> >
>

Messages 2174 - 2203 of 17563   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

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