Priorities and Agile

On 2010/07/19, in agile, rant, signal, webdev, by a b

My place of working practices Agile.  My place of working is also on a push to crack down on software craftsmanship.  One big thrust of this is T.D.D., as well as following good design principles, like SOLID and whatnot. Lately, though, we have also had a bit of trouble with getting our customer’s needs met.  I feel like see a pattern here, and maybe even a solution.

It seems to me a big part of Agile comes down to balance. In it’s very definition, the things that are ‘favored’ (individuals, interactions, working software, collaboration, response to change) are just that; favored. They aren’t strictly demanded, and there isn’t a formula for measuring the percentage of implementation.

I think the problem is that the ‘commit to technical excellence and good design’ principle of Agile is getting a bit more than favored.  It’s becoming a goal in itself, a measurement that is superseding what I feel are more important goals.

A frequently overlooked principle is the bit about “maximizing simplicity”, which is measured by the amount of work *not* done.  Technical excellence and good design are important, but the customer keeps the lights on, so delivery of working software should take precedence.  That is supposed to be the *only* measure of progress.  Now, my personal assumption is that ‘working’ is defined by the customer; not by the dev team, not by architecture, not by the test suite.  That’s just me, and I know that’s not everyone’s view.

Craftsmanship, pragmatically applied, is non-negotiable.  TDD is teh best design tool, evar.  The SOLID principles are invaluable, especially for code that will live long enough to be extended, maintained, or improved.   I’m 100% for all of those things, as long as we’re doing *just enough* of each an all of those things.  To me, just enough is the amount that it takes to deliver working software of business value, and no more.

If we lose sight of that, we may make some impressive technical contributions, but we risk failing to achieve what we are ultimately setting out to do.

The thing is, it’s obvious (and should be expected) that all of us in this organization have different definitions of where the ‘just enough’ line falls, or what ‘working software’ should include.  This is where the balance part comes in, and where interaction will help us combine our different views.

I would argue that we need make sure we’re doing the rest of Agile as passionately as we’re doing the craftsmanship part.

 

Comments are closed.