headers
PAUL | 1 Dec 2010 04:12

Re: New Agile Vehicles


Hi Ron,

> Well, to me, your original posting was so nihilistic as to make me
> wonder why you bothered to post it. :) Since none of us are rational
> enough to be swayed by it, or by anything, our behavior is
> essentially random. Influencing us is impossible.
> 
> And yet, somehow we seem to improve as individuals, as teams, and
> even as influencers. It's a puzzlement.

I promised you something a bit more positive. Well I've got further in the book now so here it is :) It's
interesting the reactions to what I wrote. If you think about it, what I said is no more then common sense,
yet the reaction was somewhat irrational, as if I had killed hope itself.

Well the positive news is that the only thing in the dock was false hope. If we accept that change is hard we can
give up on the false hope that when the going gets difficult all we need to do is ditch our current vehicle and
find a shinny new one.  I would bet on something tried and tested over something shinny and new anyway :)

If Scrum or XP isn't working for you, the answer isn't necessarily Kanban or yet another new variation on the
same theme. How about just getting better at driving the vehicle you've got?  After all Scrum is built on the
idea of apply, inspect and adapt, so if the problem really is with the vehicle and you find that you need snow
tires then go get some, uprated break?, then get  them too. Pretty soon you've got a new custom vehicle of
your own making (you've also still got those dry weather tires for when it stops snowing :)).

Chances are though is that the vehicle is just fine, and you haven't got very good at driving it yet :) The
patience comes in by setting appropriate expectations. By focusing on the driver over the vehicle, we can
make allowances for all the false starts new drivers are likely to make, and provide safe opportunities
for them to fail safe whilst they learn.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Steven Gordon | 1 Dec 2010 07:13
Picon

Re: Re: New Agile Vehicles

That is good advice for "drivers", but does not really help "vehicle
providers".

We are pretty good at "driving" our own "vehicles" on our own projects.
 Unfortunately, our learned skill does not translate easily to new
"drivers", so we are alway tempted to try to design an improved "vehicle",
one that is easier for beginners to keep on the road but will be just as
good as ours when they gain experience.

SteveG

On Tue, Nov 30, 2010 at 8:12 PM, PAUL <beckfordp <at> btopenworld.com> wrote:

>
>
>
>
> Hi Ron,
>
>
> > Well, to me, your original posting was so nihilistic as to make me
> > wonder why you bothered to post it. :) Since none of us are rational
> > enough to be swayed by it, or by anything, our behavior is
> > essentially random. Influencing us is impossible.
> >
> > And yet, somehow we seem to improve as individuals, as teams, and
> > even as influencers. It's a puzzlement.
>
> I promised you something a bit more positive. Well I've got further in the
> book now so here it is :) It's interesting the reactions to what I wrote. If
(Continue reading)

Permalink | Reply | 1 comment |
headers
PAUL | 1 Dec 2010 12:42

Re: New Agile Vehicles


Hi Steve,

> That is good advice for "drivers", but does not really help "vehicle
> providers".
> 

There's advice here for "vehicle providers" too. Providing shiny new vehicles to others is a precarious
business to be in (worse so if you offer a money back warranty should your new vehicle end up in a ditch). 
You'd be better off moving into the driving instructor business instead :)

> We are pretty good at "driving" our own "vehicles" on our own projects.
>  Unfortunately, our learned skill does not translate easily to new
> "drivers", so we are alway tempted to try to design an improved "vehicle",
> one that is easier for beginners to keep on the road but will be just as
> good as ours when they gain experience.
> 

Driving off the road may not be as bad as it sounds, especially if you have the good sense to pick roads where
there is nothing to hit. At least the newbie driver has managed to get the vehicle moving. Perhaps next time
he'll manage to keep it on the road too :)

Regards,

Paul.

> SteveG
> 
> On Tue, Nov 30, 2010 at 8:12 PM, PAUL <beckfordp <at> ...> wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joshua Kerievsky | 1 Dec 2010 13:06
Gravatar

Re: Re: New Agile Vehicles

On Tue, Nov 30, 2010 at 7:12 PM, PAUL <beckfordp <at> btopenworld.com> wrote:

> I promised you something a bit more positive. Well I've got further in the
> book now so here it is :) It's interesting the reactions to what I wrote. If
> you think about it, what I said is no more then common sense, yet the
> reaction was somewhat irrational, as if I had killed hope itself.
>
> Well the positive news is that the only thing in the dock was false hope.
> If we accept that change is hard we can give up on the false hope that when
> the going gets difficult all we need to do is ditch our current vehicle and
> find a shinny new one.  I would bet on something tried and tested over
> something shinny and new anyway :)
>

MS DOS was tried and tested.  Should we still be using it?

> If Scrum or XP isn't working for you, the answer isn't necessarily Kanban
> or yet another new variation on the same theme. How about just getting
> better at driving the vehicle you've got?  After all Scrum is built on the
> idea of apply, inspect and adapt, so if the problem really is with the
> vehicle and you find that you need snow tires then go get some, uprated
> break?, then get  them too. Pretty soon you've got a new custom vehicle of
> your own making (you've also still got those dry weather tires for when it
> stops snowing :)).
>

Car manufacturers issue recalls when their vehicles regularly malfunction
and they improve their vehicles when customers complain or rating agencies
like Consumer Reports give them bad ratings.
(Continue reading)

Permalink | Reply | 6 comments |
headers
PAUL | 1 Dec 2010 13:50

Re: New Agile Vehicles


Hi Joshua,

It all depends on the audience I think...
--- In extremeprogramming <at> yahoogroups.com, Joshua Kerievsky <joshua <at> ...> wrote:

> I've seen a trend towards what I'll call "lean enchiladas."  These processes
> have been crafted by experienced XP/Agile folks who have spent years
> experimenting to remove waste and minimize process in order to focus more
> mercilessly on successful product development.  Lean enchiladas don't
> resemble Scrum or XP enough to say that they are new models of those old
> processes.  They are new Agile vehicles.  Few know about them and some are
> perhaps happy about that.  I think the world needs some better Agile
> vehicles and I would encourage folks to describe them.
> 

I've used all (most of) these supposedly new echniladas, often within a single project. I didn't need a
label or a recipe book though, we would work without a backlog when there wasn't one, skip iteration
planning when it wasn't needed, we'd apply, inspect and adapt as made sense at the time.

I would encouraged able drivers to do the same. I would offer completely different advice to the novice though.

My main beef is how some of these enchiladas are sold as alternatives, they are not. If you get the values and
principles then  they are just different practices. If you don't then they can be a source of confusion.

Perhaps not on this board, but on others, ideas that are decidely non Agile are being regurgitated and
presented as new (for example anyone who as considered CMMI level 5  knows all about SPC and conrol charts).

Here is the rub. The best people at adopting Agile tend to be the ones that were doing pretty well with
waterfall despite its limitations. The worst Agile adopters I've come across, weren't fairing too well
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joshua Kerievsky | 1 Dec 2010 14:23
Gravatar

Re: Re: New Agile Vehicles

On Wed, Dec 1, 2010 at 4:50 AM, PAUL <beckfordp <at> btopenworld.com> wrote:

> No vehicle is going to compensate for incompetence at the wheel!!
>

I know someone who doesn't know how to parallel park.  I was amazed when
driving with him, and pointing out a parking spot, only to be told that he
isn't comfortable with parallel parking.

Parallel parking isn't easy to learn.  Most folks accept that.  Ricardo
Semler (http://en.wikipedia.org/wiki/Ricardo_Semler) doesn't.

He thinks it is absurd that for 100 years the automobile industry failed to
innovate a way out of the absurd moves we have to make to parallel park a
car.  (See the video here:
http://www.extracoaching.com/business/leading-by-omission-ricardo-semler).

Rather than blaming folks for being incompetent, we need to innovate ways to
make successful software development easier.

--

-- 
best,
jk

--
Joshua Kerievsky
Founder, CEO
Industrial Logic, Inc.
Web: http://industriallogic.com
Twitter:  <at> JoshuaKerievsky,  <at> IndustrialLogic
(Continue reading)

Permalink | Reply | 4 comments |
headers
Laurent Bossavit | 1 Dec 2010 14:36

Re: Re: New Agile Vehicles

Hi Josh,
> Rather than blaming folks for being incompetent, we need to innovate  
> ways to
> make successful software development easier.
>

A few random thoughts here...

The excellent "Making Software" book has an excellent chapter by Mark  
Guzdial on "Why is it so hard to learn to program", with extensive  
discussion of recent research and experiments around the topic. There  
are interesting hints that people actually know how to express  
solutions as computations, but become incompetent when they have to  
express those solutions in existing programming languages.

Yet, with the rate at which new programming languages spring up, you'd  
think if the solution was going to come from that area of innovation  
we would have happened on it by now.

Also... This Sunday I tweeted the following:

   We rarely mention the most basic problem: most programmers are not  
well educated for the job they do. -- David Parnas

Somewhat to my surprise this was retweeted by 40+ people, which I'm  
interpreting as broad agreement. I'm not sure if that's "blaming folks  
for being incompetent" but we seem to recognize that part of the issue  
is with education.

Do you find, for instance, that before they can be successful people
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joshua Kerievsky | 1 Dec 2010 14:49
Gravatar

Re: Re: New Agile Vehicles

On Wed, Dec 1, 2010 at 5:36 AM, Laurent Bossavit <laurent <at> bossavit.com>wrote:

> Yet, with the rate at which new programming languages spring up, you'd
> think if the solution was going to come from that area of innovation
> we would have happened on it by now.
>

Perhaps we have to distinguish between improvements and innovation.  Cars
have improved from 100 years ago, yet most of them still don't make it easy
to parallel park.  Are the new languages improvements on old languages or
real innovations that make software development far easier?

> Also... This Sunday I tweeted the following:
>
>   We rarely mention the most basic problem: most programmers are not
> well educated for the job they do. -- David Parnas
>
> Somewhat to my surprise this was retweeted by 40+ people, which I'm
> interpreting as broad agreement. I'm not sure if that's "blaming folks
> for being incompetent" but we seem to recognize that part of the issue
> is with education.
>

Great tweet, BTW.  I was one of the retweeters.  David Parnas rocks.  I feel
fortunate to have met him at the XP200x conferences in Sardinia.

> Do you find, for instance, that before they can be successful people
> and teams need to *un*learn some things?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Laurent Bossavit | 1 Dec 2010 15:01

Re: Re: New Agile Vehicles

> Perhaps we have to distinguish between improvements and innovation.  
> Cars
> have improved from 100 years ago, yet most of them still don't make  
> it easy
> to parallel park. Are the new languages improvements on old  
> languages or
> real innovations that make software development far easier?
>

It's hard to tell. When carmakers innovate they are driven by the need  
to sell more cars, so you'd expect those innovations to be continuous,  
conservative rather than revolutionary.

When programmers innovate in the area of programming languages they  
tend to be driven more by a desire to be recognized for their  
cleverness and should be less constrained by pre-existing assumptions.  
At one point there was a wave of "visual languages", and then it died  
down. (Only much later did some research, apparently, show that visual  
brought little or no improvement in programming performance.)

Perhaps the issue is more that we are paying too little attention to  
those underlying assumptions and therefore are failing to innovate in  
ways that challenge them.

A good example is the way we talk about "complexity" or "technical  
debt" or even "duplication" as if they were purely properties of some  
piece of source code, forgetting that source code isn't just some  
object "out there" but something that is the creation of a human mind  
and something that the human mind keeps interacting with, over time;  
therefore any discussion of design qualities which omits from
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gary Brown | 2 Dec 2010 00:25
Picon

Re: Re: New Agile Vehicles

Hey, Josh!

----- Original Message ----- 
From: "Joshua Kerievsky" <joshua <at> industriallogic.com>
To: <extremeprogramming <at> yahoogroups.com>
Sent: Monday, November 29, 2010 6:19 AM
Subject: Re: [XP] Re: New Agile Vehicles

> On Sat, Nov 27, 2010 at 12:47 AM, PAUL <beckfordp <at> btopenworld.com> wrote:
>
>> Few of us are actually practising and moving the art forward.
>>
>
> My colleagues and I continue to practice this stuff as part of building 
> and
> selling software to people and companies around the globe.  We're closing 
> in
> on 2 million in gross sales, having started with just an idea. Along the
> way, we've jettisoned a good deal of traditional agile practices.  Now I
> look at what we're doing and wonder if it would make for a better starting
> point for groups in a similar situation.  I've been reading the book 
> Rework
> (37Signals) and am happy to see that they do many of the things we do 
> (e.g.
> not maintaining a backlog).

I think it would be safe to say that your context at IL is a bit different 
than most Agile shops, whether beginning or highly experienced.  When you 
want to add a new album to eLearning, how do you communicate that with your 
team?  Do you a make a list of ideas that you want to express in the new
(Continue reading)

Permalink | Reply | 6 comments |

Gmane