We’ve all seen the headlines or heard the news that software projects and major IT fails. When this happens we look for a place to lay the blame – in the press they often go for the individual to be held to account but in the industry we end up blaming the tools and the methods.
There is sizable minority of people who now believe that agile methods fail. Not having performed an extensive survey it is difficult to tell precisely what evidence there is and it wouldn’t be a great surprise to find that some hold these strong beliefs on the basis of a single project failure.
Methods do not fail. They can’t and how could they as they are merely models invented by one person to be used by others to help them in real life. It is reality that fails, not models.
The map is not the territory.
Maps are merely a representation of reality – someone would have gone out and used their eyes, measuring tools and instruments to record a picture or model of the real world. This is all fine until the map is used. It can be used to guide a person through terrain helping them to make decisions about direction, making interpretations of the real world. Alternatively, it could be used as if it was infallible and followed with blind faith. This would ultimately lead to mistakes, where the original map may not be accurate or new features in the territory have appeared, and it could lead to danger as it does not, of course, cater for live traffic conditions or extremes of weather.
In the world of software there are examples of following the methods as if they address all real-world circumstances. People often miss the intent behind the method and follow the rules, either explicit within the method or implied or invented. In doing this, they move away from some of the fundamentals of agile, beginning to favour process and tools above individuals and interactions. When this happens others end up being disenfranchised.
For example, Scrum is a well-adopted method in the agile world and many people have adopted the tools and techniques very successfully. However, we often work with organisations where teams are seeking more and more improvement in the method rather than in delivery, that is trying to optimise the theoretical model rather than improve delivery. Even worse than this they invent their own beliefs or they inherit the beliefs of others that say “you are not doing Scrum unless…”. Most recently I heard a well practised agile enthusiast in an academic seminar say “you are not doing agile unless you are doing continuous integration”.
We also see organisations for their ways of working to fit with the chosen methods. For example the design team responsible for a major transactional site were being forced into fixed-length time-boxes for their work, for no other reason than that is what it says in the methodology, only to find their work does not fit.
We have rules that regulate our daily activity in society, largely to protect the property, health and lives of individuals. We should have guidance, principles and values in our working methods that help us to do a better job. We should see rules as constraints on our ability to inspect and adapt and begin to take ownership and responsibility for the things we do.
Success and failure happens only in the real world – it’s down to people, not methods.