Tag Archives: philosophical

Agility as Religion, Part 2

Last week I waxed lyrical on the circumstances that are necessary for real change in an organisation and the inevitable challenge that pursuers of agile methods are faced with in light of these prerequisites.

To recap: since a software developer’s ultimate goal isn’t producing some code, but  delivering value to the customer, she is forced to consider ways in which her circle of influence can be expanded to meet her circle of concern (where the primary concern is delivering real value to the customer).  In most organisations, change beyond the development team necessarily requires action at a senior management level.

As a professional software developer, I have a duty to do the best I can when it comes to delivering value to the customer, despite my circumstances.  In my book, a professional is more than just someone who does work for money; a professional is someone who has the customer’s interests at heart—everything flows out of this.

Professionalism means being proactive; more specifically: the Covey flavour of that phrase.  In practice, this translates to moving beyond practices with-which we feel comfortable.  Software development became my career mostly because I enjoyed programming, starting at a young age, but as the years went on, I found myself becoming increasingly frustrated by what were, in my opinion, ill-informed decision-making practices of superiors.  The crux of this thread is that it is up to us, as software developers to put on our sales hats and become persuaders in addition to programmers; experience has taught me that nobody else is going to do it for us (just typing that sentence makes me realise how silly it was to expect someone who doesn’t have a software background to make that leap).

All of that waffle boils down to the first step:

Look in the mirror and truly understand that in order to widen your circle of influence, you are the one who is going to have to change first.

The “you” in the above statement can be an individual, but it can also be a team.

Then, put on your sales hat and engage the guy or gal who can make these changes. Fully comprehend that the person who you’re trying to persuade is approaching things using her own paradigm, and adjust your thinking appropriately.  As passionate as your pitch may be, trying to persuade a chartered accountant of the benefits of agile development by carrying on about TDD, pair programming and continuous integration won’t get the traction that you were hoping for.  Before others will change, you need to change: become that accountant, feel the sorts of things that are important to her; pitch it on her terms.

Simple as the solution may be, carrying it out is hard.  I believe the solution to the biggest problems in software development are simple to describe, but hard to implement.  Case in point: the concept of two people working on the same piece of code together is a simple one; the act of convincing the holder of the purse strings that putting this behaviour into practice will yield better results over the long term is hard.

The Key to Successful Software

With a title like that, you’re probably expecting to hear about the elusive silver bullet–that one ingredient that makes projects finish on-time and within budget.  We all know that that’s a pipe dream … or is it?  If there were three things that were the most critical factors in determining if a software endeavour were to succeed, what would those be?  What would the most important of those three be? One word: People (capatilisation intentional).

Joel Spolsky runs a successful software company, and ‘casts to the masses on a regular basis; and guess what makes him excited?  Figuring out the best way to get the very best people on board.  He’s identified the proverbial Goose (that lays the golden egg) and things can only get better.  Developers have the latest toys at their disposal; enormous, luxurious displays, motorised desks and their own offices (with a view!).  Because Joel has realised that once you’ve bagged the alpha geek, the story is only beginning—a really productive “smart and gets things done” geek works best when surrounded by the most scintillatingly cool toys (multi-screen/big screen and really fast machine) and quiet … yes quiet (or put another way–“freedom from interruption/distraction”) makes an enourmous difference to productivity.  Justin Etheredge echoes some of these sentiments in this well-written whinge-fest.  Joel has spared no expense in clearing the path for his people because he groks it.  That being said though, not just anyone is hired at FogCreek and often good people are overlooked, but at the end of the day it’s all in aid of attracting the Best of the Best because once again … he groks it.

When the lone hero development model breaks down due to sheer project size, we need to move onto teams … or groups of co-working people.  It’s just an extension, so excellent people beget excellent teams and as Martin Fowler points out, it isn’t methodologies that succeed or fail, it’s teams that succeed or fail.  Excellent teams will always succeed.