coding is like sculpting - but is it agile?

I've had a recent epiphany:  coding is like sculpting.  I guess it took me a while to see the connection (since I'm not a sculptor), but as I imagine it, sculpting goes something like this:

• Get a big pile of clay.
• Reduce the pile of clay to the size of the intended sculpture.
• Start cutting the clay into a roughly hewn representation of the sculpture.
• Examine your work - is the design going as intended?  If so, continue, else start over.
• Refine your sculpture with finer cuts - yielding a less coarse result.
• Examine your work again.  If on track, continue, else back-up.
• Continue refining your piece - refining, backing up, continuing, etc.
• Repeat for as many steps as needed.

I've lived with Agile for many years - and my conclusion is that Agile is purposefully designed to support the idea that coding is like sculpting.

Every sprint is your opportunity to move your sculpture forward to it's next level of refinement.  Said another way, at the end of each sprint, your sculpture should be a finer version of what you sculpted the prior sprint.

Agile gives this a name:  the vertical slice.  Every sprint should be a working model that moves (feature-wise) closer toward the end result.

I begrudgingly admit these facts, since I admit I set about writing this to bash Agile for not supporting the notion that coding is like sculpting - when in fact, I concluded the opposite.  Score one for Agile.

why software projects are like progress meters

Why is it so hard to make a decent progress meter?  How many times have you seen a progress meter do something ridiculous like:

• Get stuck at 71% for a long time.
• Get stuck at 100% for a long time.
• Get to 100%, then start over at 0% and go to 100% again.
• Repeat the prior bullet five times.
• See a time estimate of 324518 hours, then two seconds later, see an estimate of two minutes.

I'm being rhetorical when I ask "why can't we make better progress meters?"  I expect answers like, "how can I account for a network blip?" or "what should I do if the user suddenly loads the machine?" or "the work units being measured aren't equal complexity".

Funnily enough, executing a software project is quite similar to watching a progress meter.  Low effort planning, inexperience, failing to account for interruptions, and other combinations of factors can cause your software project to go totally awry of the estimate, get stuck at 71%, and in some cases, spawn off entirely new projects.

It all starts with the estimation process. A good estimate is the prescription for a smoothly run project.  Sadly, though, I've heard more than once, "the software process can't be accurately estimated".  This matter-of-fact resignation is bogus.  Authoring quality estimates isn't easy - but it allows your development and project managers to more accurately plan upcoming work.  So let's get to it:  my suggestions.

My first suggestion:  for those of you who write software estimates - try harder.  Study the existing code intensively, you may find logic that (nearly) meets the need.  Also, consider writing experimental logic "outside the app" to test your approach.  You won't be able to author a decent estimate until you've "cut a mental path" through the challenging parts of the project.  Once your estimate is done and the work begins, there should only be small mysteries remaining.

Second, know your "load" - your meeting schedule, how much time you spend on email, whether you'll be taking vacation, etc.  This is an Agile concept - knowing how many hours per day/week you can work on your projects.

The third suggestion may be obvious: let experience be your guide. However, you may be asked to work in unfamiliar code.  In these cases, spend a couple hours studying the code - then review your thoughts with one or more of your team members.  When no one is available to consult, you may need to more than a few days studying the code in order to provide a reasonable estimate.

Finally, make every effort to break your estimate into sub-one-week tasks. Admittedly, I struggle with this.  I argue with myself that I can call on my experience - that "I've done something similar before".  Invariably, though, my three week estimate either takes a week or five weeks.  In other words, I goofed my estimate because I didn't break it down.

If you put some effort into it, you should be able to author estimates that allow you to execute your software project with reasonable predictability - which is a heck of a lot more than I can say about most progress meters.  :)

tampering voids warranty

I've been in software R&D for more than 17 years.  I find the recent  trends towards Extreme Programming, Agile, Scrum, etc., very interesting to observe.  Before I share my observations, consider my background:  in those 17 years, I've been a technical first-level manager for ten years, and a second-level director for two years.  I've seen these processes in action as a developer, manager, and director.  In fact, one of my responsibilities as director was "development process".  I've been through Agile training and I've used leading software (Rally) for planning/tracking iterations.

upper management's view

Upper management tends to see Agile and it's kin as "the next great thing".  It makes sense:  these processes promise high quality deliverables and fine grain control of release dates.  Also, because customer involvement is high, the deliverable will be precisely what the customer wants - no more, no less.  These are things the VP R&D struggles to get right every day - Agile processes are seen as a "silver bullet".

first and second level manager's view

First and second level managers get the bum end of the deal when it comes to rolling out Agile.  They have to understand the new process well enough to manage within it.  They have to deal with the full spectrum of developer reactions to this change:  some developers will fully embrace it, some will do everything they can to avoid Agile process.  They have to answer to the VP R&D - and try to explain why the "silver bullet" is taking so long to work.

developer's view

Developers all have something in common:  they are motivated to write awesome code and get recognized for doing so.  Daily scrums, day+ long planning sessions every iteration, and retrospectives - are just a bunch of meetings that get in the way of being awesome.  The majority of developers tend to resent the number of meetings, seeing them as low value.  The final issue:  Agile makes developers feel a bit claustrophobic, since every aspect of their day has to be "part of the iteration plan, in support of their team".

the challenge

If you read about Agile and it's kin processes, they all say the same thing:  "If you don't follow every aspect of the process, it won't work".  I call this a "tampering voids warranty" disclaimer - and I don't like it.  If someone approaches me with the-next-great-thing and it has a "tampering voids warranty" disclaimer, there's a 99% chance I'll reject it.  Let me explain a bit further with an analogy.

I see anything that has a "tampering voids warranty" disclaimer as an immutable puzzle piece.  You're the other puzzle piece.  Since the-next-great-thing puzzle piece is perfect and immutable - you have to change yourself, your team, your family, etc., to make the fit work.  The human nature response to this is to resist.  Not because of the old saying that "change is hard".  People resist because deep down, we all know that there is no silver bullet and the-next-great-thing isn't perfect - it goes against human intuition.  Also, the more you ask someone to change, the more benefit that person should see from having made the change.

Coming back to Agile, the people being asked to change are the developers and the first and second level managers - and no matter how much you polish it, they will see the change to Agile as a net loss for them.  However, the VP R&D didn't have to change at all - all s/he had to do was say, "we're an Agile shop now" - and s/he and the company get all the benefits.

so - what to do?

I wish I had a magical answer here - but I don't.  And you wouldn't believe me if I said I did, since I just made the case that there is no silver bullet process.

What I will say is this:  to be a great manager, director, or VP, you have to resist falling prey to the-next-great-process - especially ones that come with a "tampering voids warranty" disclaimer.  Great products come from great people - not process.  You simply can't invest heavily enough in your people - and I'll be honest, molding great developers/managers is a lot of work - but it always pays off.

As for process, I say tear off the "tampering voids warranty" tag and see what happens.  Trust your team to come up with variations on the process, and let it evolve.  Remember:  the most important aspect of the process you choose is that it brings benefit to people you're asking to change.