Agile Methodologies Will Not Save You From Project Failure
– We won’t make the deadline!
– Use Agile!
– It won’t help us if we don’t have enough people!
– Then find another clever word!
Many people associate project failure with the choice of development methodology: if they had chosen Scrum/Agile/DevOps, everything would have been fine. To be honest, these people don’t understand software development.
Alistair Cockburn analysed several software projects delivered using different models. He found no correlation between success or failure and the development methodology used. Cockburn concluded that development effectiveness does not depend on the methodology used.
There are more than a dozen methodologies available today, but none of them guarantees success. Choosing a methodology should be the first thing you do when you start a new project. Basically, the choice depends on the product being developed and the people involved in the development. The main principle of performance assurance is
The process model should adapt to the team, not the team to the process model.
Product
Suppose we are developing software to control a spacecraft or a water supply management system. All the requirements are known in advance, there is extensive technical documentation of the product, there are strict requirements that must be met, and so on. Not surprisingly, such projects use cascade development methodologies or the tried and tested ‘waterfall’ methodology.
Developing a modern web service requires a completely different approach when we have only vague requirements to start with, and these may change all the time. This is where the well known Scrum/Agile and other ‘agile’ methodologies come in. Their use in this case is justified by the fact that you can get rapid feedback in a rapidly changing external world.
The above can also be applied to the size of the product being developed. After all, different processes should be used for projects involving 10 people than for projects involving 1000 people.
People
A team of students and a team of highly skilled professionals require a different approach to workflow organisation.
I continue to believe that Scrum and other Agile-like methodologies were created for those who simply cannot work independently (but want a sense of autonomy). I have identified several types of teams for myself, depending on which you can build the process of working within:
- Professionals - everyone knows their job and how to do it. They can take responsibility for the outcome. They don’t care what methodology is used, they don’t need it, especially not one imposed from above. Often they do not need a manager as such, as they are able to work independently without constant control and with outstanding results. A manager can only act as a shield from clients and the business.
- Bearded programmers are fairly experienced professionals, but they need regular supervision and support, so clearly defined job descriptions are often not necessary.
- Green beginners - need constant supervision, support in finding a solution.
The manager must study his team and choose an intelligent methodology for it. Each team needs a different approach. The manager’s main task is to:
- Build a team that works for results with sufficient efficiency.
- Establish a team process that makes it comfortable to work.
- Coordinate the team’s interactions with other departments and the customer so as to minimise disruption and maximise results.
- Remove the obstacles in the way of the team’s goal.
Conclusion
A lot of young project managers I’ve talked to write into their track records that they’re the main factor in the product’s success, and without them it would all go down the drain. Managers, stop! The success of a project is not in the actions of the manager, not in the process by which it was created. Success is the team that worked on the project.
As Tom DeMarco wrote in ‘Deadline. A Novel of Project Management’, project management is about managing people, otherwise it’s administrative nonsense.