What a software development method means to me

Iterative/agile software development methods like IBM Rational Unified Process, XP and Scrum are very popular lately. To some, they are like a silver bullet, the 100% fail safe way to develop software. To others, software development methods are just fancy names for common sense stuff, and therefore a waste of time and money.

I don't think doing agile will guarantee success by itself. Inversely I don't think "our project failed because we did RUP" is a good argument either. Any software development method only deals with the parts of software development that are generic enough to capture in global guidelines and rules. That still leaves a huge area where no software development method will help you. Even the parts that are covered by a method can still go wrong. A method only gives some basic advice how to reach the right goals without getting burned by the wrong risks. However, no activity diagram in the world will tell you what the customer really wants or how a complicated algorithm is best implemented without scalability issues. The real work still needs to be done by the people involved in the project. Individual quality of the members and the team as a whole, the commitment of all stakeholders and realistic expectations ultimately decide whether the project succeeds.

However, I do think that a project team can use a development method as an effective tool. To me, a method provides the following important benefits:

• A common vocabulary: a method gives names to all kinds of things in a software development process. This makes it much easier to learn about certain topics, get started in an organisation and communicate about the process.

• Structuring work and responsibilities: knowing when who needs to do what, who needs to make certain decisions at what point in the project. A method helps you cover the important basics with minimal effort, in a way that is compatible with the overall intentions of the method.

• Risk and change detection: all methods provide some check points, test strategies, evaluation activities and registration policies to detect risks and changes to the project goals. Do not confuse "detection" with "management" though. Simply keeping a list of risks and changes is not enough.

• How to handle change: a central theme of every software development method is how to deal with change. The method takes a stand and tunes the rest of the method to match this strategy. In the past, most methods perceived change as a project risk because it could change project planning and -budgets and this would somehow cause chaos. Change was supposed to be prevented by making as many decisions up front as possible. Later on, people could use these decisions to deflect changes or at least point fingers at people to be "responsible for the change". In this context, change implied an error in a previous decision.

  However, modern methods realize that change is something you should embrace instead of prevent. If there is a need for change, that means that either the problem is changed or better understood, or the solution can be improved. Not changing at all means holding on to the past, and doing nothing with the knowledge of today. Current methods like to delay decisions, be more flexible of when to do certain activities and use several safety nets (like automated testing and regular releases) when implementing a change.

Picking a method that matches your culture and needs is important. If you are not ready to embrace change, doing all-the-way XP may not be a good idea. Being in RUP projects myself mostly, I also get great ideas from other methods. Picking and choosing from methods and keeping a good balance is the game here. They even have a word for that in the RUP vocabulary! 🙂