Glenn Gillen

I've spent almost all of my career with something along the lines of "freelancer", "consultant", or "contractor" on my business cards and the forms HR departments make me sign. On the two occasions that hasn't been the case I've been working for as part of a development team that was primarily developing solutions for external customers, or managing a team of contractors working on launching a start-up. So I've been really very fortunate to work across a really broad spectrum of clients and environments and with some brilliant people, which over time makes it easier to appreciate what works and what doesn't.

You're probably doing it wrong

Coming into a new company is always interesting, no matter how wonderful the people or the environment there is always at least one aspect of their job that they don't enjoy. More often that not it's some process that has been enforced by management types who had the best of intentions, but didn't appreciate the impact on those caught in the process. I've been that manager, I've implemented that process, and I apologise to those in the past that were affected by it.

The worst manifestation of this is the implementation of "agile" at most places I've worked. What seems to happen is a progressive manager reads about the productivity gains and other benefits of being "more agile" and either implements it in a piecemeal fashion, picks and chooses the bits that makes the most sense, or thinks that somehow magically telling people to read the agile manifesto and crack to it will make it happen. Other times it's a developer that wants to make everyones lives better and their company more productive but doesn't have the authority to implement the changes alone. It's the same end result.

I'm going to follow this post with another on my tips for "doing agile right", and practices to generally avoid. I have to give credit however to Graham Ashton, working closely with him for almost 3 years refined my understanding of how to do it properly and I hope he does a post of his own to cover anything I may miss. In the interim I'll give you a secret to help you take the first step to salvation. Every time you go to write something, fill in some plan, have a meeting, or do anything mandated by your "process" ask yourself "is this going to make me deliver the product faster?". If the answer is no, don't do it.

You're not there to write *insert language of choice here*

I heard this explained best by Obie Fernandez during a Q&A session when someone asked how you convince customers that you're not going to offer an upfront fixed-cost bid on some work. I'm paraphrasing here, but he essentially said that Hash Rocket customers don't sign up for a project or deliverable but rather they engage Hash Rocket for their expertise and experience. Either you freelance or your an employee it's the same thing, whoever has employed you hasn't got you in to just cut code. They've assessed a whole range of your background and experience before moving forward with you, and they ultimately want to use that experience to their advantage and solve at least one problem they have. Whether you're writing code in Java or Ruby or PHP is inconsequential, you make a judgement call on what is best for the business and what will allow you to get the job done most effectively given your experience. In some places, that means you have to fall in line with existing technologies because at the end of the day that is "best for the business". Which brings me back to my original point…

Nobody gives a damn about what tools you use

And by nobody, I mean nobody outside the people who also have to use the tool(s) in question. A senior manager need not care if I'm writing Ruby or Python, using Rails, Django, or Sinatra. They've got a problem they need fixed, get it done as effectively as possible. My post yesterday about the benefits of testing with cucumber is another example. I've worked in places where we've tried this approach, giving the customer the ability to see the output of the test suite (sometimes even letting them write the stories), being able to see as features one-by-one go from being red to green as the continuous integration box output the results of the latest commit to a nice website where everyone can see where we are. And then when everything goes green there is much rejoicing, clapping of hands, and popping of champagne.

Except it never happens. The customer looks at the test output for a week, at best a month, and then stops caring. And why should they care? After you write the story (more on that in the next post) their interest in reading it ever again is almost zero. Whether or not you've ticked some boxes, made some text go green, or moved index cards from one end of a board to the other is of no importance to your customer. All they care about is working software. Delivered, working software. You can proclaim a "story" is finished until you are blue in the face they don't truly believe you until they've played with it themselves and made sure it meets all their expectations, including the ones they forgot to tell you about.

A lot of tools are just getting in your way

So if your customer is never going to read your story, why go to the hassle of incorporating it into a core part of your workflow in a fashion that only serves to slow you down? And I'm not pointing the finger just at testing tools here, I'm putting almost any tool I've used that is trying to bridge the gap between developer and customer into the firing line. I've never found a project management tool that made me think "Wow! This is incredible, I'll never work without this tool again" because they're all basically shit, just some less shit than others (Mingle and Pivotal Tracker are reasonable). Even when I've been managing a team I've been less than enthused about using them, and I'm convinced that if you're sharing a workspace with the others in your team that many of these tools offer no real benefit over far more simple and possibly less tech focussed solutions.

Their worst crime though is duping people into thinking that they're actually helping to foster an agile environment and workflow. If you look at the original manifesto and break it down, most tools are actually taking you further from the core principles.

Sit down and speak to your customer and then go do some work. Question the value of anything that happens in between.