Mythodology
I’m enjoying the term mythodology – collecting fieldstones for an article, I’m re-reading “Weinberg on Writing – the fieldstone method”
Doing an internet search for mythodology, I found Marco Abis named his website mythodology. As he says on mythodology:
Towards the end of 2005 I found it in the book “Weinberg On Writing” in relation to the (in)famous writer’s block (but interestingly the quote is from Tom Gilb):
‘Writer’s block is not a disorder in you, the writer. It’s a deficiency in your writing methods-the mythology you’ve swallowed about how works get written-what my friend and sometime coauthor Tom Gilb calls your “mythodology.” Fieldstone writers, freed of this mythodology, simply do not experience writer’s block.’
[..]Agile methods are the next (current?) step but are still only scraping the surface of the problem having myths themselves which get in the way of the true Quality.
Hear hear!
As Agile ‘methods’ (I’m still / more and more against methods ) become mainstream oversimplification becomes rampant, as was to be expected.
October 23rd, 2007 at 11:22 am
Hi there. If I got it correctly you consider my sentence an oversimplification (which may well be). Would you care to elaborate a little? thanks a lot
October 24th, 2007 at 3:02 pm
Hi Marco, thank you for your response!
Well, I guess my sentence was oversimplified
I was trying to agree with you. My inline rant against methods might have gotten in the way of getting across my agreement with you…
I am (and have been) for a long time on the quest for the Quality Without A Name (sometimes achieving it, sometimes not).
So let me try again:
Agile methods are scratching the surface of what is possible.
As agile methods become mainstream, I am seeing oversimplified understanding more frequently.
Most notable mythodologies: ‘Agile Scrum’ and ‘Agile’.
far as I know, there is a methodology called Scrum, that falls under the umbrella of methods that a long, long time ago led to the agile manifesto.
‘Agile’, or more precisely Agile Software Development, is an umbrella and a set of values and principles. It is not a methodology because there are no specific practices attached.
I also see oversimplified applications more frequently.
For instance:
- people who say they use retrospectives but have never read up about it (or attended a retrospective held by an experienced facilitator, and then receive guidance afterwards, which is how I learnt). Which has a high risk of the retrospective being ineffective.
- people who (say they) apply scrum or xp by rote. People attend a course or read a book and then apply some stuff literally, without reflecting on it or adapting it to their context. Books and courses are a starting point for relentless reflection and continuous improvement (I emphasize that heavily in courses I give, as well as making people aware of the importance of context).
On scratching the surface: Of the three methods I deal with most frequently, I find Scrum the most superficial, followed by XP (adds technical practices that are valuable to kick ass in many environments – Scrum is sorely lacking those. ) and Lean Software Development (out of the box) has most meat to it (in addition to XP LSD writings draw attention to seeing the whole).
I hope to write more about myths in the near future. I would enjoy hearing you more about specific myths.