Compromise

So, Allan Kelly has picked up on something that I kind-of pretty much did say at XpDay this year—but not quite. I certainly am "part of the UK Agile set", especially if we emphasize the "UK" bit. What I'm not is part of the gang of independent consultants in London who are many of the high-profile early adopters in the UK, and it's true that I never worked for Connextra or any of the other highly-publicized, London-based "Agile" shops. Why is this worthy of note? Only because it relates to a sign of un-wellness in the community that I perceived at the session where Allan heard me say that. It was a double-header, a somewhat strange work-shoppy type of thing, followed by a panel. It was while speaking on this panel that I said what Allan noticed.

The point that I was, perhaps unsuccessfully, trying to make was that the disenchantment with the current state of the Agile world is perhaps more to do with the geographically constrained, hot-house world of ex-Connextra, ex-another place, folks circulating around the same bunch of clients in London than with anything wrong with the community at large.

In particular, this idea that any "mojo" has been lost, or that by accommodating corporate culture in amongst Agile adoption some "compromise too far" has occurred seems very off base to me. We pretty much agreed on the panel that the question "Have you compromised your Agility?" is a silly one, since "Agile" is primarily a marketing buzzword and it labels what is pretty much a bag of platitudes. How can we tell that these are platitudes? Well, they don't help us choose between reasonable alternatives: the hardest-core hard-core SSADM, PRINCE-2 wonk around, if asked in those terms, would probably tell you that working software is more valuable than comprehensive documentation (and probably add "you idiot" under their breath). They might not necessarily behave in a way aligned with that judgment mid project, that that's a whole other story. Fretting about whether or not you've compromised a platitude doesn't seem like the way forward.

There was a lot of talk about "Excellence", too.

And all of this (along with "wither the Agile Alliance?" and "what can we do about Scrum?") may seem like a topic of crucial import, if you spend a lot of your time inside the echo-chamber. Are we Agile? No, I mean, are we really Agile? Truly? Are we Excellent? Is this the real, true, expression of the Principles? I've seen long-lived Agile teams tie themselves in knots (and tear themselves apart, and get—rightly—caned by their business sponsors) over this sort of self-absorbed stuff.

Now, I have in mind a team I know that adopted some (not all) Agile principles. Are they purely Agile? No. Are they living the dream? No. Did they have to make compromises between textbook Agile and their corporate culture to get where they are? Yes. Might they do better if they hadn't to? Yes. But...

Are they three times more productive than they were before? Yes! Is the internal and external quality of their system hugely greater than before? Yes! Do their management revel in being able (for the first time ever) to believe, trust and make intelligent decision based on their status reports? Yes!

I am most reluctant to embrace, in fact I absolutely repudiate, a model of what it means to be Agile that demands that I call them failures because their (ongoing) improvement required compromise with their corporate culture. I'm not terribly interested, these days, in fine-tuning some on-going Agile adventure. I'm interested in taking what are now increasingly well-tried techniques and using them to get the big wins, the big increases in quality and productivity that so many shops are crying out for.

Architecture is contextual, but don't play dumb

A great post from Jacob on the contextual nature of architectural choices. Shock news: he doesn't think that dependency injection frameworks are right for him and his business.

He makes a good case for in-house development being the place where YAGNI is the primary principle, at least so far as the choice to spend effort (= money) on technology choices like that. I sympathize: I've seen in-house teams (with a declared adoption of XP, no less) get into huge rows with their business sponsors because their devotion to a certain architectural stance cost them productivity. They burned up man-decades on trying to get the damn thing to work, ended up with an incomprehensible codebase and then, because it was the right thing, started all over again, only with a determination to get it right this time. IIRC, they eventually ended up implementing this framework three times. Productivity went down and down. The "coach" and "customer" couldn't be in the same room at the same time. So sad. Key to this falling-out was the idea that the (paying) customer isn't entitled to an opinion about how the work is done.

Meanwhile, a side discussion at one XPDay session this year touched on the question of taking into account a need that the customer has told you they have, but that they haven't given a high enough priority to for it to be in the current release. It would be wrong, according to one understanding of YAGNI, to implement this release in a way sympathetic to that upcoming goal. But why? If the customer has told you that some need is coming (soon, that is, as in "next release", and not "in the next five years"), and this lets you make a smarter choice about implementing the nearer-term goals...well, it would be foolish to ignore that information, wouldn't it?

YAGNI means "don't spend six months building a framework to support six days development", it doesn't mean ignore highly certain knowledge about the immediate future direction of the system.