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/

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

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

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
>

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

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

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.

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

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

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

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

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

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.

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

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/

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

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
>

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

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

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.

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

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

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