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 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.
@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.
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 @RonJeffries: On emigrated say the heart of agile. :)
@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: https://en.wikipedia.org/wiki/Golden_Rule
The Golden Rule is seen in every major religion: https://www.ted.com/talks/karen_armstrong_let_s_revive_the_golden_rule
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. https://www.hillelwayne.com/post/are-we-really-engineers/
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.) https://podcast.oddly-influenced.dev/episodes/glenn-vanderburg-on-engineering/transcript, 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?
@RonJeffries @totheralistair you're not wrong but don't forget stuff like 3D printing could bring that down for some physical things.
I can imagine a designer adjusting a widget based on some feedback, printing off a 1/10 scale rough print in just a few minutes as a double check before a full scale print that would potentially be available in a few hours.
@Bdellar indeed - and for each industry different - they are enablers
@Bdellar
yes, and I would add "high collaboration"
@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…