Follow

I see this sometimes: To be agile requires technical practices, that's the foundation. If technical practices are ignored (which is the common case), we get FlaccidScrum.

I might agree, but I need to ask, what are the technical practices for an org transformation project? and what are the technical practices for installing a clean water system in a rural village?

Expansion on the question: XP was mostly tech practices for programming. Scrum contains no tech practices for any domain. People complain about SCrum that it misses XP's tech practices. Now I see general comments that "agile in general" is missing XP's tech practices, but they don't say "XP's tech practices", they say just "tech practices."

But agile is applicable everywhere, not just programming. When you are not in programming, XP's tech practices are not relevant ---- so, if we choose to agree that tech practices are essential to agile, we have to ask what are those tech practices that apply to some other endeavor.

People who know me also spot here that this is my way of rebutting the assertion that tech practices are the foundation of agile. if you/they can't name the tech practices for other fields, then the assertion "tech practices are the foundation of agile" is false.

So it is both an interesting question in its own right, and a challenge to the assertion. Typical Alistair styles, lol.

@totheralistair Gardening has permaculture, industry as lean, urbanism as tactical urbanism, software has agile… I don’t see agile as a universal way. All of the above have underlying practices so imho I will tend to think agile require tech practices to work. I don’t see how you can achieve short feedback loops in software to adapt quickly if you don’t use automated tests, continuous integration and deployment…

@totheralistair IMHO this is a little bit sad that most people think that XP "was mostly tech practices for programming" and not ways to build kickass teams

@alexvictoor
i don't know if you were there when it was created, it was definitely pitched as mostly tech practices for programming.
Any kickass team construction was a side effect that appeared after the fact --
then, there are surely ways to build kickass teams that don't require red-green refactoring and automated regressions unit tests.

@totheralistair I think XP’s tech practices are so noticeably because of the general lack of an engineering culture in most of the industry. It is possible that other industries had solved that problem before Agile came along. My sense is that most Scrum implementations are in software and therefore it is the wrong approach on its own.

@chetHendrickson
re: scrum: replace "most" with "some" and i'll be on the same track as regards scrum in software. ... now, let's take would-be-agile teams away from software, and leave off the word scrum entirely .... and .... we're back to my original post.

@totheralistair If we try to apply agile to everything, we must inevitably lose content. To begin with "working software", right there on the tin. Sure, there are parallels in other disciplines, but when we remove the differences, we're left with little more than platitudes, it seems to me.

@RonJeffries @totheralistair: For a while now I've been using "solutions" instead of "software" when talking about Agile.

The name of The Manifesto alone restricts it to software, however, the values, principles, practices, and tools should be applied beyond software. imho

Focus on people working together to deliver value collaboratively and adapting to an ever-changing context.

In a way, that idea is a widely applicable platitude.

@itsjoshbruce @RonJeffries

you know, if i had to start over from scratch, i would possibly just choose 4 words that contained no reference to sw at all.

like:
collaborate - deliver - reflect - improve

and then see how that might fit different contexts.

@totheralistair Yes, sure. Since all the tech practices and focus of "agile" have been washed out anyway, why not go for vague (but valuable) generalities right out of the box?

@itsjoshbruce @RonJeffries @totheralistair

“should”?

As an early adopter and small-scale innovator in the “Agile” world, I’ve learned that we who build and operate software-intensive products and services have consistently been 10, 20, 30 years behind other industries in our discovery and adoption of these ideas. Sometimes even 10, 20, 30 years behind _ourselves_, as we seem collectively to be rather forgetful.

A little humility is called for, I think.

@keithb_b @RonJeffries @totheralistair: Most of them revolve around human interaction. I’ve seen the problems being addressed in all industries I worked in. Most had nothing to do with software. So, for me, it’s a “should” - highly recommended.

@itsjoshbruce @RonJeffries @totheralistair Maybe I misunderstood your second para, which seems to suggest removing the “software” from “manifesto for agile software development” and then promoting its practices avd values. And in many industries we’d get a shrug and then be schooled in what we’ve missed. The software development discipline is not in a leadership position on this.

@keithb_b @RonJeffries @totheralistair: Not sure. Might be the difference between concept and attribution.

In the US The Golden Rule (concept) is often attributed to Christianity: en.wikipedia.org/wiki/Golden_R

The Golden Rule is seen in every major religion: ted.com/talks/karen_armstrong_

imho - The Golden Rule "should" be for everyone whether religion is practiced in general or Christianity specifically...just a good idea, even if it might be a platitude.

Who "leads" or gets credit, doesn't matter.

@keithb_b @RonJeffries @totheralistair:

ps. Even if those practicing the concept don’t call it The Golden Rule; attribution isn’t important.

@keithb_b @RonJeffries @totheralistair: Interested to hear what industries would shrug and school software development.

What values, principles, practices, and tools they would have not found in the software development industry?

@itsjoshbruce @RonJeffries @totheralistair

Pretty much any field where folks must collaborate and the stakes are high.

I’ve learned to expect that when I look for experience reports on the latest bright idea that software folks have latched on to I will find that, for example, nurses have been there, done that, found the flaws, patched them up, then moved in to something better…decades ago.

We are not as unique and not as advanced as we like to imagine.

@keithb_b @itsjoshbruce @RonJeffries @totheralistair

Mr. "The Truth is in the middle" steps in. See Hillel Wayne's comparison of "real engineers" and software people. hillelwayne.com/post/are-we-re

Or @glv's comments on engineering.

They both find that each side has particular blind spots and unquestioned habits that the other has gotten more correct. (For example, software people do version control better.) podcast.oddly-influenced.dev/e, has transcript.

@RonJeffries
there is a different way to look at this ... suppose we borrow what was learned from the agile sw dev crowd, and see how it applies elsewhere. Then "sw" isn't on the tin any more, and isn't even in the equation.

Sw ppl don't own the word 'agile', it was around as a fine word long before, and will be long after.

So if anyone not in sw wanted some of the same soup, what ingredients would it contain?

@totheralistair they can't have the same soup. Software isn't like anything else. They could have biz and dev people working together. They /might/ be able to evolve a product, but probably not every ten minutes. Etc. Seems to me the parallels are pretty clear, mostly around folx working together making the thing.

@totheralistair To clarify, you’re saying that iterative, adaptive approaches are applicable to other domains, right? And the question is, what do we mean by “technical practices” in those other domains, right?

@totheralistair I think for me, it’s the ability to adapt and change whatever it is that you’re working on, quickly and easily. XP gives us that in software.
For, say, an Agile Transformation, it would be the ability to change plans, to be flexible in your objectives. You’re dealing with people and organisations, not software, so good people skills are the key “technical practice” I’d say.

@totheralistair What are your feedback loops? How are you sense-making within the organisation? You need the “technical practices” to make a change, see what it did, and to reflect on that.

@Bdellar indeed - and for each industry different - they are enablers

@totheralistair Reminds me of what L. David Marquet says about the ability "give control" requires "organisational clarity" and "technical competence".

Re: org transformation, this feels like it's about technical architecture constraints (whether software or not). With installing clean water systems in villages, it's small-scale civil engineering practices. Easy maintainability being a much bigger deal.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.