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.