Thursday, 21 February 2013

Agile, it's a funny old word.

It seems to be a common theme in the development world today about being "agile". With recruiters reporting that this "skill" is fast approaching the point where it will take over from "HTML" on developers CV's, the word "agile" is now losing its value. The meaning behind it is being lost to the realms of the buzzword, and as a result it is becoming harder to find the people who truly understand what we mean when we say it.

So what do we really mean by "agile"? This is a question that tends to be asked in interviews, and is greeted by a whole array answers. What we want to hear about is a passion to deliver value faster, incrementally, and collaboratively with the business. We want to hear about minimal marketable features, breaking down work into small chunks and regular releases. We want work to flow through the team via a pull methodology rather than it being pushed into the pipe.

The bottom line of it all is that 'agile' is just a word. It is all about the way you work and how you go about doing things on a day to day basis. To me, a lot of what 'agile' preaches is just common sense. It doesn't need to be badged up as some kind of buzzword, or worshiped as some kind of religion.

Its not just IT, but the whole business that needs to adopt these working practices in order for them to work. It requires a change in mind set, to put trust in the development teams and how they work. Despite common views, developers are just as committed to delivering value as anyone else in the business. They need the support and environment in order to do this the best way possible.

I have often seen departments suffer from "us and them" syndrome. This cannot be the case if you truly want to be a value driven business. These walls need to be knocked down and everyone needs to wake up and smell the coffee and realise that everyone is in this together. Once you reach this point, and everyone starts to work together - that is when you can really start to deliver. End to end delivery teams, responsible for taking an idea from inception to delivery. Quick and responsive feedback loops between the people doing the code and the people driving the ideas. Collaboration and taking everyone's views and inputs to a solution in to consideration in order to get the best possible result. This is the world I want to live in.

The bottom line, ladies and gentlemen, is that we should not get hung up on words or the latest craze - but we should strive to continually improve and take the best common sense approach when developing software.

Tuesday, 12 February 2013

Operational Excellence vs Technical Perfection

In the modern world of software development, where focus on quality is just as (if not more) important as quantity, it is becoming increasingly important and difficult to find the correct balance between the two.

As companies begin to work in a more 'agile' and lean fashion, adopting techniques such as TDD and pairing, the type of person that they tend to chase in terms of recruitment is also changing. Developers with good skills and experience in TDD and XP are in very high demand as a result of this. The danger here is that a lot of developers with this skill set are very opinionated and have very strong feelings with regards to how software should be written. It is difficult to keep some of the more purist of mind happy, as they want to do everything in a perfect way. The majority of what they say is correct, but it is not always practical to put it into effect. These people have great ideas, and want to have a positive impact on day to day work - this is something we should actively encourage and not stifle. Not getting their ideas into reality can often lead to them feeling under utilised or under valued.

This leads us to the challenge of living in the real world. Given an infinite amount of time these developers would work towards the perfect solution. This is what I would call a development utopia. It is a myth, a world that developers can only dream of, where everything is tested, readable, etc. In reality there will always be better code, and no matter who has written something or how it has been written, the likelihood is that there will always be ways to improve and refactor the code by the next person to see it. The outcome here is that tasks can take a very long time to complete - meaning a much slower time to market for delivering value.

The business stakeholders want to release as many features to the customers as possible. The business value utopia would be quite the opposite of the developer one, with a total disregard for quality of code or the future and only a short sighted what can we get now mentality. They don't necessarily care how we do something, but that we get it done and delivered.

When working in a commercial environment, the overall aim of the team should be to deliver value. However we should all be clever enough to learn from our mistakes that we should not sacrifice the future in order to get more now. This is where we need to work more collaboratively with the business in order to find some kind of balanced middle ground. Yes, we should invest in our software to ensure that we can still make changes in the future, but do we really need to engineer the perfect solution every time? By the same measure, the business need to accept that we can not just churn out tickets constantly if we want to ensure future development capability.

There will always be times where quality needs to be sacrificed in the short term in order to deliver critical business functionality or issues, and as developers we need to be flexible to any such demands. The counter side to this is that the business should not abuse this way of working and should have a very strict way in which to identify any such work. Additionally, the business should be bought in to the way in which technical debt works - and give development teams time to tidy up after themselves should the above ever occur. I have seen first hand where team's will react in a negative manner when such an event happens. Rather than reacting in this way we should be positive about doing our best to help the company as a whole - if we want the business to allow us to work how want to, we also need to be receptive to their needs.

The bottom line is that we are all at work to deliver things that the business wants. Delivering the perfect solution but taking 2 years to do so does not represent value. Delivering 100 things in a week but leaving the code base in an unworkable state going forward might get some immediate gains but would ultimately cripple the business in the future. This is why we need to find the balance between operational excellence and technical perfection.