The con job that is Shu-Ha-Ri

On another blog I posted the following:

That’s true. Ha is to question the norm. After you have gone through the training and expense of the Shu stage.

When you get to Ri they don’t make any money off of anyone, whether it’s’ aikido or scrum.

So, the thing is, can one bypass the “Shu” stage of endeavours that are non worthwhile, without spending any time or money?

To me, the answer is yes.

To Agile, Inc, the answer is heck no, right?

I’m not buying it — the notion that one cannot question an endeavor until one has spent shu amount of time and money on it. People could come up with 20 methodologies and force everyone through the shu stage before they are even allowed to question it.

Not only is the patrician, and outdated, it’s beyond the pale when it comes to telling the customer they are too ignorant to question anything until they have bought shu cars etc.

As you can see I’m not a big fan of the Shu-Ha-Ri concept. Not only is it fortune cookie level eastern thinking, it can fundamentally translated as: “Grandfather knows best. Grandfather is Ri. After you have kids and they are in college, you can be considered to be in the Ha stage, and after you are a grandparent you can be Ri. In the meantime, don’t question anything”.

Gussying it up in new age clothes doesn’t change it.

But it is a little more sinister than that — since you can’t question anything until you reach Ha stage, and you have to expend money  and time to go through the Shu stage, it’s a convenient cover story to sell you product, even product you question and don’t believe in, unquestioningly.

I’m sorry, noone should be forced to accept anything based on the fact that they are a “beginner” in a methodology someone just created.

They could be quite advanced in general and can see through things.

Even Einstein was quite fond of “gedanken” (thought) experiments versus real world experiments.

Sure, it’s nice to have the real world experience, in anything and everything, but it’s nice to be able to think through things and avoid suboptimal paths.

Shu-Ha-Ri is a concept, that, in the software world, needs to be lain to rest for good.

If people want to apprentice themselves to some master on their own time, that’s fine, or they can apprentice themselves to cobbler or luthier.

As a business technique, it’s sole purpose is to suppress dissent and gather revenues, pushing as many of the sheep through the shu stage as their bank accounts can stand.

If you can’t compare two different concepts without trying them both, then what they are trying to do is get you to spend the money to try both. That’s all there is to it.


Posted in Uncategorized | Tagged , , , | 4 Comments

Where the Agile/Scrum Community got it wrong, and why the backlash continues to grow

Everywhere you go it seems, people are being more and more critical of Agile and Scrum. What happened? Where did it go wrong? Isn’t Agile all Fuzzy Bunnies and Goodness?

Here’s my take on where the Agile Movement went astray

  • Creating a “movement” to begin with

    Creating a “movement” to begin with was a mistake; good technical ideas don’t need “movements” to support them.A movement implies that it is separatist in nature, dividing the world into those that are part of the movement and those that are not.

    Movements use emotion and propaganda techniques to sway people to their side.

    Creating a “separatist” movement makes it hard or impossible to work with people not  part of the movement — of course the Agilists think all these people should be fired.

    This is not the way to work with stakeholders.

  • Creating a Manifesto to begin with

    Was also a bad idea. A manifesto implies some radical notions, upon which to base a separatist movement, with communist overtones.Most of the agile manifesto is unrelated to most projects

  • Stolen/Appropriated Ideas

    Most of Agile/Scrum is either based on iterative, incremental development, which predated the Agile movement, or based on outdated japanese manufacturing techniques, which also predated the Agile movement.They take these techniques, and wrap them in new rituals, and claim it as there own.

    There are plenty of (more effective) ways of doing iterative and incremental development, but the Agilists don’t want you to know that

  • Obvious Profiteering from an Early date

    No sooner was the ink dry on the manifesto, that a raft of books, immersions, seminars, and certification mills sprang up.This left a bad taste in the mouths of many, both inside and outside the “movement”.

    If something looks like a profiteering game, it probably is

  • Infallibility/Personality Cult

    Most of Agile canon (especially Scrum canon) is built around the notion that it is infallible.If it didn’t work for you, you did it wrong.

    You have to do it the way the founders say to do it, or you’re not doing it right.

    However these founders are mere mortals, the techniques are indeed fallible, and the failure of the “movement” to deal rationally in these areas leads more and more people to realize, that the Agile movement doesn’t work.

Even wikipedia feels that Agile is similar to cults.


They catalog:

Another criticism  is that Agile’s drive to impose itself into business systems is cultish in its nature. Faith-based similarities include:

  • Agile claims absolute universality, of being applicable to all levels of business, and useful to all members in any given organization.
  • Agile claims infallibility (that its technique is absolutely correct as-is, and not to be changed or questioned).
  • Agile requires meetings that involve ritual activity (“planning poker”, for example).
  • Agile requires system-specific jargon for comprehension (Kanban, story points, scrum, epic, etc.), terms which are not readily understood by the layman or un-initiated.
  • Agile attempts to create an ideological “monopoly of method”, excluding alternatives, competitive models, and any mixture or dilution of its core principles.
  • Agile seeks to become closely allied with the “heads of state” (business leaders, in this case) to gain favor, authority, and reinforcement of its claims.
  • Agile employs professional, full-time clergy (i.e. “Scrum Masters”) who alone possess the appropriate credentials of education and formal ordination (e.g. Agile certifications).
  • Agile attempts to gain new members through viral reproduction and the socialization of the un-initiated into the ranks.
  • Agile tries to minimize diversity of opinion by accepting different views within the system only rather than through the formation of new methodologies or alternatives.

It’s time to get back to the fundamentals of what works — iterative and incremental, and get rid of all the rituals, propaganda, and fluff that plagues agile.

Welcome to the post-agile world!


Posted in Uncategorized | Tagged , , , , , | 1 Comment

Death by Agile Fever

In an enlightening and entertaining post, Alex Bell takes to task the Zeal that blinds many to the obvious shortcomings of Agile.

Bell categorizes the following Agile fevers:

  • Lemming Fever
  • Easy Button Fever
  • One Size Fits All Fever
  • Elbow Grease Fever
  • Hallelujah Fever
  • Parrot Fever
  • Cook the Books Fever

As well as several others.

He also coins the term “Fragilista” to denote an Agilista who is thin skinned and lacks the strength to control his or her emotions in response to a perceived attack on Agile.

Many of the ideas he brings up are strongly related to my post here.

Ultimately, Bell feels that these Fevers are caused by the arrogance, ignorance, and insular narcissistic attitudes of many in the Agile community.

He claims: “The antidote for the many forms of Agile Fever is education. Unfortunately, the infectees who are most desperately in need of such education are often unaware of what they don’t know about Agile, are unreceptive to learning about what they don’t know, or believe that those trying to educate them are simply village idiots who have not yet seen the brightly burning Agile light.”

What’s your take?

Posted in Uncategorized | Tagged , , , , | 2 Comments

Moved content to new site

I have moved a lot of my content related to agile to it’s own site — this one —

Most of the content has been preserved through the move but some things like ratings and tweets have not…

Feel free to browse around and make comments! If there are broken links please leave a comment on this page and I will attempt to fix as I have time available


Posted in Uncategorized | Leave a comment

Know — And Choose — What you are optimizing for

There are a lot of software development approaches and methodologies out there.

What do they do? Which should you choose?

First of all, I think you need to know — and choose — what you are optimizing for.

Are you looking to develop software for the lowest possible price with a “minimally viable” product as the result?

Are you looking to develop software that is rarely updated (think embedded), but needs to function perfectly?

Continue reading

Posted in Uncategorized | Tagged , , , , , , | 1 Comment

Should “Agile” methodolgies just be called “Lightweight” methodologies?

In a recent exchange on InfoQ, regarding the recently released Voke report on Agile, I opined the following:

I just wanted to add and concur that originally these were called “lightweight” methodologies and I think the term is accurate — whether they are for lightweight projects or lightweight developers.

Maybe some fraction of SW development does indeed fall into these categories — or yet another “startup/Minimalism” category.

One of the major points to happen from the “Snowbird” conference was the jettisoning of the term lightweight for “agile”.

It was thought that “lighweight” would indicate non serious or disposable. So — after much discussion “agile” was settled on, as a more marketable glittering generality.

However, if said methodologies, had been indeed marketed, under the more realistic and accurate name of “lightweight” we wouldn’t be seeing the problem we see today.

The fact that there was a deliberate effort to make this a universal solution, driven, possibly, and only possibly, of course, by the notion of a future profit potential, have we seen this phenomenon.

Let’s call a spade for what it is — if this is a lightweight methodology for lightweight programmers or lightweight product owners or lightweight projects in general, fine call it that.

I can certainly see if someone has a $15k budget for a project, and “BUFD” would cost $10k, sure, jettison that, let’s code ‘n’ fix til we TDD towards a solution.

But that is what it is…a solution for some small projects or some serious unknowns…not a universal panacea.

In other words, I agree there is a time and a place for lightweight methodologies, and the clarity to call them what they are.

The fact that “agile” in a rush to stampede the world, has, mistakenly assumed all projects fall under their “lightweight” domain, is the crux of the issue we are facing today.

The Voke report, as well as most real world market information, suggests that agile is far from panacea.

It may indeed be appropriate for lightweight work and let’s celebrate that.

But when heavy lifting is required, perhaps a different approach is called for.

Let’s stop even referring to “agile.” Let’s call it what it is — lightweight.

A spade is a spade, it has it’s purpose, and so do Lightweight methodologies like Scrum and XP and most of Agile.

There is no need to get a bulldozer when all you need is a shovel, shall we call a spade a spade finally?


Posted in Uncategorized | Tagged , , , , , | 4 Comments

Voke releases Research Report on Agile Realities

In an interesting report former Voke has released a new report on Agile.

Among the findings:

  • Out of over 200 survey participants, we received only four detailed comments describing success with Agile.
  • Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
  • Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.
  • Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.
  • We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.


Sounds like what I’ve been saying over a decade now?


Posted in Uncategorized | Tagged , , , , | 10 Comments

Kanban for Software Engineering?

There is a lot of buzz in the community over kanban lately.

Although I think there are some good ideas in the Lean/kanban system, I think that most of it’s power is lost when it is applied to software engineering.

I’m very familiar with the whole notion of Lean/kanban/Value Streams etc, having developed software to essentially automate such a system for the Semiconductor Industry.

The product was so concerned with value streams and product flows it was called — wait for it — wait for it — FlowStream.  This Software was probably used to run most of the factories making chips for the machine you are using right now.

But we didn’t use a kanban system for developing the software — why not?

Continue reading

Posted in Uncategorized | Tagged , , , | 3 Comments

Range Estimation versus Point Estimation

One topic of interest to all developers is the subject of estimation.

Should it be done in hours? Days? T-Shirt Sizes? Point based? Range based?

In this post I’m going to talk about Range based versus Point based estimation.

Imagine, if you will, two types of gunsights. One the familiar cross type, and the other with a small circle around where the middle of the cross would be.

The odds that the bullet, will go exactly into the middle of the cross, is very unlikely for a number of factors, but the odds that it would go somewhere into a small circle, are in fact, quite high.

This is called the circular error probability. It is the same when playing golf. You may not hit it to a particular spot, 175 yds away, but you might reliably hit it in a circle somewhere between 170 and 180 yds away.

This is what range estimation is.

Instead of saying the task will take 8 hours (point based estimation), say it will take 4-12 hours, or whatever the correct CEP value may be.

There are a lot of advantages to this

  1. Averaging a large number of tasks like this reduces the overall error in the estimation system, as overshots will be corrected (stastically) by undershots leading to more overall accuracy at the project level
  2. It prevents the blame game

What’s the blame game? Easy. If you use point based estimation, the odds of getting it right are unlikely. The likely case is you will underestimate, and probably get blamed, or overestimate, and be blamed.

This takes the blame game out of the equation, while acknowledging variabilities in estimates.

Feel free to give range a try — it even goes well with real time units!


Posted in Uncategorized | Tagged , , , , , , | 5 Comments

The Perennial Waterfall Strawman/Myth

Just as the ‘abominable snowman’ never existed, and is merely used to frighten children from playing in the snow too long, “Waterfall” is just as nonexistent and is used by agile coaches as propaganda scare tactics to frighten developers into buying into Agile, Lean, kanban, or whatever the flavor of the month is in project management.

Agilists constantly talk about ‘Waterfall’ in derisive terms, however we can get an idea what this mythical beast is like from the depictions of the Agilists.

  1. Waterfall requires absolute command and control
  2. Tasks are assigned
  3. Testing never happens until after the project is finished
  4. The customer is not involved until it’s too late
  5. Everything must be done in strict phases, the phases must be horizontal in nature (eg, no UI gets done until ALL of the database is done, etc), and once a phase is complete it will never be modified in the future
  6. A huge amount of upfront design is done before coding

These are all myths.  Anyone who has even read Royce’s original paper on the subject would know that.

Let’s look at the reality

  1. Royce’s paper does not even use the word “Waterfall” — hence there is no “Waterfall” method at all
  2. Royce never mentions assigning tasks
  3. Royce never mentions a command and control environment
  4. Royce specifically states that a hard phase approach as described in #5 above is unworkable, and shows quite clearly feedback mechanisms between the phases
  5. Royce never states that phases should be done horizontally
  6. Royce specifically states that the customer should be involved early, and testing should be done sooner rather than later
  7. etc

So the Agilists present a false dichotomy: Either you choose a (fictitious) Waterfall process that never existed, and make everyone slaves to documentation and management, or you choose their latest Agile scheme, and become slaves to daily Scrums, Poker Games, and begging the Customer to tell you what you should do.

The fact is, there are a lot more choices out there. There are many flavors of traditional management out there; choosing tasks can be done when there are documents and planning.

There are many ways of doing iterative traditional practices as well…see the “my approach” link above for more information.

The next time you hear someone promising you will fail with waterfall you can be sure of a few things:

  1. They don’t know what they are talking about
  2. They don’t believe in facts or logic
  3. They’ll say anything to get the sale

You can always respond smartly with: “Beware the Jabberwock!”


Posted in Uncategorized | Tagged , , , , , , , | 7 Comments