Re: [extremeprogramming] What has changed for you over the past 20 years?

"R Dymond" <[email protected]> Tue, 3 Dec 2019 22:57:39 -0700
Newsgroups gmane.comp.programming.extreme-programming
Message-ID <CANOj=qPdQXmr-kn_csSdsbA7-8Z1MrqkHC_yQG55eb186+nW9A@mail.gmail.com>
My first Agile project was in 2002, so not 20 years, however that first
project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected
stepchild of Scrum, to somewhat mysterious/intriguing ghost of development
gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I
follow (ie Jeff Nelson chromebook inventor), it seems among these non XP
practicing smart engineers Agile developer skills aren't considered
necessary or required. That to me is sad though not unexpected. Developers
have as much difficulty changing their habits as anyone else. Besides,
we're too busy.

At a recent client that has success adopting Agile in their hardware
manufacturing group, their software group remains a flailing mess, the
current S/W project running millions over budget (waterfall) and the CTO
recently fired for it. That CTO connected me with that S/W group before the
sh*t show got rolling but they declined my services.

That same fired CTO sponsored agile in 5 pilots, all hardware, and all
delivering. In those pilots we emphasize less welding and more (overbuilt)
interfaces (mostly ignored because if cost) more modularity, more
standardization, and TDD thinking, which translates into hypothesis to test
rig and interface, then design to pass. These are not quite unit tests, but
somewhere between unit and functional tests. Selling these ideas in
mechanical engineering teams today is like selling OO in the 90s. Some get
it and love it, others don't care, and most are sorta neutral.

By decoupling and enabling reuse we decrease the amount of engineering
labour required to build new H/W systems. Many engineers do not think this
is a good idea, since they're paid for every hour of engineering required
("and we're going to engineer the sh*t outa this thing"). Similarly, sales
of standardized parts generate less profit then sales of specialized
parts.  Case in point, try to mount wheels for a bmw on a similar sized
sedan from another manufacturer. There are dozens bolt patterns to hold a
wheel on a car, the reason for so many has to do with profit, not passing
the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail
TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look
at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started
working with Scrum in 2010 I have trained most the staff on Scrum.
They have over
1000 developers. We sold a total of 2 XP/TDD immersion courses with a well
known XP Coach after strenuous internal marketing from HR and finally a Dev
Sr Mgr assigning people to the classes. This same company spends millions
per year on dev training and regularly sell out courses on Swift, C++,
python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the
issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince
developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=
[email protected]> wrote:

> George, thank you for raising the discussion to the top level.
>
> Things that have changed for me over the past 20 years:
> 1. XP as a practice has been forgotten and many parts of it have fallen
> out of use.
>
> 2. I find myself continuously reinstalling [XP and Agile] best practices
> at the jobs I'm taking on. Continuous Integration, unit testing,
> refactoring, iterative development...
>
> 3. Teams are practicing either 'run as fast as you can' SDLC which is
> essentially a no-practice, or full blown waterfall, as in
> 'let's-plan-a-year-out' with all consequences.
>
> 4. Raise of the 'Product Manager' job which is a strange combo of a member
> of sales organization and a surrogate user. Engineers no longer can talk to
> users.
>
> 5. Use cases is not a thing anymore. Use cases were replaced with user
> stories that are short blurbs leading to ambiguity in implementation and
> testing and last moment changes in requirements.
>
> 6. Large scale projects. SW organizations can easily be in hundreds of
> people that ends up in a zoo of way of doing things unless top leadership
> pushes a particular approach down.
>
> 7. Code reviews now must which is great.
>
> All in all, I feel that new entrants into the software development job are
> not educated in the engineering part of it. As a result the SDLC is largely
> defined by idiosyncrasies of the engineering leaders. Or teams
> self-organize and end up with no-process.
>
> Slava
>
> On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <[email protected]>
> wrote:
>
>
> (This thread was buried in another thread; I'm trying to transplant it to
> the top level so it gets more exposure.)
>
> Things that have changed for me over the past 20 years:
>
> 1) Nobody says "XP" or "Extreme Programming" anymore, even when they're
> doing many of the practices.
>
> 2) Developers didn't test 20 years ago. Now unit test suites are
> ubiquitous, and many of them are well-maintained.
>
> 3) Everybody's talking about User Stories, which were weird 20 years ago.
> Unfortunately, the tools have taken over the meaning, and I need to chant,
> "The card is a token for an ongoing conversation" over and over. Sometimes
> it gets through.
>
> 4) I no longer focus on the practices when I spread them; I just start
> using them when I pair with someone, and they catch on (or don't).  Maybe I
> should have specific sessions where I focus on, say, refactoring, or TDD.
>
> There's probably more I've forgotten. 1999 was a long time ago.
>
> --George
>
> A lot of people mistake a short memory for a clear conscience.
>     - Doug Larson
> Subject: Re: [extremeprogramming] What has changed for you over the past
> 20 years?
> Date: Tue, 29 Oct 2019 08:39:12 -0700
> From: Jay Bazuzi <[email protected]> <[email protected]>
> Reply-To: [email protected]
> To: [email protected]
>
> From Arlo I heard a story that Corey Haines would experiment with doing a
> project without one of the practices that he normally relied on for
> success. He found that his defect rate was steadily decreasing over time,
> project to project, but when he skipped TDD his defect remained the same
> (he wasn't learning) and when he skipped Refactoring his defect rate went
> up (quality depends on design more than on tests).
>
> That seems to match your experience, JB.
>
> -J
>
> On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <[email protected]>
> wrote:
>
> On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <[email protected]>
> wrote:
>
> Thanks, JB,
>
> I was surprised.  Let's see what happens.  The timing is interesting as I
> was just recently prompted to dig out some old articles/papers I've written
> and have some reflective time to publish updates... what is timeless since
> the early 2000s and what has evolved (at least for me).
>
>
> This leads to a wider discussion regarding what has changed for you as an
> XP enthusiast and practitioner over the years. I'd like to keep the
> question wide open, so don't hold back.
>
> I recently experimented with evolutionary design without tests and I found
> it enjoyable and illuminating.
>
> I worked with a group of 3 people. They wanted to practise microsteps and
> to see a design evolve. For 3 hours, I drove while they typed. They
> practised the microsteps inside their IDE (elementary refactorings,
> keystrokes) and we went through 2 features of one of my teaching examples,
> "test"-driven (meaning that we wrote and ran the tests in our heads). It
> worked surprisingly well! They got to see some simple design evolve (albeit
> with no pressure from tests) and that made them happy. They could more
> clearly _see_ the power of evolutionary design, related to being able to
> defer commitment and change directions as needs change. We also just went
> more quickly than we would have had we written the tests.
>
> Of course, I told them that if we got into trouble, then we'd start
> writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)
>
> So it turns out that after a decade or two of practise, one can live
> without the tests a surprising amount---at least in some contexts.
> --
> J. B. (Joe) Rainsberger :: https://tdd.training :: http://www.jbrains.ca
> :: http://www.thecodewhisperer.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#160378): https://groups.io/g/extremeprogramming/message/160378
Mute This Topic: https://groups.io/mt/39418691/2417047
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-