I have a long-running debate with a friend of mine about the state of software development.
I argue that by applying agile best practice the majority of software projects can be successful. My friend counters this argument by saying the trouble is that nobody ever applies agile best practice, so software projects continue to fail.
In many ways my friend is right, in the real world agile is often badly applied. The reason why this is has puzzled me for many years.
Common sense
The conclusion I have come to is that much of agile methodology is counter-intuitive to most people.
Some obvious examples of this are:
Pair programming - it must be slower than developers working separately
Test driven development - it is a luxury writing all those tests
Self organising teams - they need a leader or they will not get any work done
This kind of defensive thinking is common and often prevents or hinders an agile approach.
Sustainable pace
Another example is the agile concept of 'sustainable pace'. This argues that a team should work at a pace that it can maintain. This is counter to many managers' way of thinking, they believe that when a development project is 'behind' it will be necessary for everyone to work longer hours to meet the deadline. I have resisted the approach of working longer hours for many years, but have recently started to question my attitude. I have realised that the real World perception of 'working hard' is simply not going to change. What is needed is a way to minimise the damage.
So what exactly is wrong with a development team working long hours and pushing hard for a given deadline? There are two key problems with this approach:
- Burnout, where the capability of the team starts to decline and mistakes become more frequent
- Reduced quality, where testing gets dropped to save time and code quality deteriorates.
There is only one mitigation of the first problem and that is to not push hard for too long. I believe a couple of 2-week sprints is the most a team can sustain at maximum output. They will then need to return to a normal paced sprint just to recharge their batteries.
Quality
Quality is often perceived as a 'nice-to-have'. This is hardly a surprise as during the development phase of a project quality is far less visible to the customer than functionality. So a team might stop writing automated tests and doing code reviews when they are pushing to get the maximum amount of functionality done in a sprint. Unfortunately, in my experience, the reduction in quality almost always costs time, rather than saving it.
Typically there is a burst of new functionality followed by a sustained period of bug fixing and fire-fighting to get it all working. The net time taken is worse.
So, my argument is that you need to build quality in to your process in such a way as to stop it being optional. For example, you can include it in your definition of done and even better fail your builds if quality drops below a threshold. The team can still work hard and pull long hours. But they will be spending a proportionate amount of the additional development time on quality. One way to achieve this is to use a build tools such as Maven in combination with code quality plugins such as PMD, Checkstyle and Cobertura.
It is also wise to consider the use of test automation to aid your regression testing.