Tuesday, 19 August 2014

Plea for Agility

Not so much a blog as a plea for agility.

I'm an Agile guy. I'm not a "white-robbed pointy hat" Agile guy, but a capital A, Agile, guy, and I think it works. In fact I know it works cause I've seen it work, I've been there, done that, want to do it again.

In the recent past I have heard some conversations and seen some things that have made my Agile bones shiver.

The first, was a conversational snippet that I overheard from a Product Owner...

"the cost of re-factoring is far too expensive 
we need more up-front design" 

Now, in no way am I saying "no design", but, how about Just-Enough-Design. ThoughtWorks has a whitepaper on it (http://www.thoughtworks.com/insights/articles/providing-just-enough-design-can-make-agile-software-delivery-more-successful), in that paper, Eewei Chen says, by doing 'big-up-front' design, we ‘hedge our bets’ too early on getting the design perfect before any development or usability testing has even taken place.

Captain Crom over at TheAgilePirate.Net has a great article on a social experiment he witnessed (http://theagilepirate.net/archives/104), his learning's are a real eye-opener, in the end he came up with a great philosophy for design, paraphrased by me...

"explain why it does something rather 
than what it should do"

I would also add to this "and also why it should not do something and the justification of this decision". To me this is the essence of innovation. By giving creative people space to work within a rule set, aka the why, they can create new and interesting ways of "the what"

This fits nicely with the Agile manifesto - "Working software over comprehensive documentation" - it doesn't take a long time to explain why something should behave in a certain way, it does take a long time to explain what it should do in every situation possible. And even better often this can be done in a picture or diagram.

Radan Skoric thinks that not re-factoring often and allowing the bugs to be fixed in maintenance mode is "self-evident why that is bad", well, common sense is not that common, and good practice is even less common (http://www.toptal.com/freelance/large-scale-refactoring) - but, I TOTALLY AGREE!

The second bone shivering experience was when in the daily stand-up a team member looked at an active work item and not only didn't know what it was seemed to be looking at it like it was the first time. To make things worse this was active for two days - not pending or not-started - but active.

"I'm not sure what that [active] task is"

This may not sound all that bad, maybe he forgot for a minute what it was, or he moved it accidentally (this is an online task board), but it was more the way he looked at it. There was pure confusion on his face. This is a task that he should be intimate with; it was his only task; it was assigned during sprint planning and a discussion about it with the senior developer had already happened. How can it be that this is the 'first time' he is looking at it.

To round out this, yet another mish-mash of thoughts and ramblings, I wanted to show this graph.
This is outlines the cost of refactoring, or at least not refactoring often enough. The biggest benefit I have seen from continual refactoring is that it does not become a burden, never is it "oh no I'm going to be stuck down in this code for weeks refactoring", it's just a part of every day development. It becomes, "I saw something that wasn't quite right, so I fixed it", and therefore it wasn't a big deal. This is seen in the “Broken Window Theory” (check out http://pragprog.com/the-pragmatic-programmer/extracts/software-entropy), I love this theory and full believe that it happens every day in software development, especially in a dev-shop where there is a loose methodology and no governing body making sure that the windows are fixed quickly.

No comments:

Post a Comment