Menu:

Home

The nineties of the previous millennium were the big time of Software Development Methodologies – and although now there’s more emphasis on small, fast and agile processes, the Methodologies are still alive. I suggest an unusual approach to review and assess Methodologies: why not write down a list of basic requirements? We (hopefully) agree on requirements for software to be developed and create more or less detailed specifications; why not doing the same for Methodologies or any other kind of ”silver bullet”? And because not only software is buggy, there’s no justification to believe that Methodologies are free of bugs as well – especially if you are a skeptical software tester.

Like any smart idea, also this is a stolen one: Brian Marick ( http://www.testing.com/ ) suggested this approach in his article ”New Models for Test Development” with respect to software development and test models.

Well … here’s my list of requirements for any Software Development Methodology – or any other kind of silver bullet:

• A Methodology must offer a step-by-step approach to the desired situation – and each step should offer some success and benefit. Any Methodology, which will lead you through a valley of blood, sweat and tears before reaching the Promised Land won’t be a good idea, you may get lost in this nasty valley. Or to say it in a less metaphorical way: a Methodology, which doesn’t deliver any real benefits before it’s fully implemented isn’t made for real life. Even worse it will offer a perfect excuse for any problem and failure: if it doesn’t work, you won’t have tried hard enough following the Methodology.
• Methodologies have to be robust. They had to take into account bad or incomplete specifications, changing requirements, slipping schedules and unexpected problems. Of course Methodologies are created to avoid or at least reduce these kinds of things, but even a perfect Methodology can’t avoid all kind of grievance. So a Methodology has to deal with them. At least it shouldn’t prevent improvisation or limit the degrees of freedom to react in a sensible and flexible way in case things don’t run smoothly. I think there’s more to say about the robustness of Methodologies - this will result in a new list of requirements. For example in my opinion Methodologies that suggest inflexible centralized and hierarchical structures won’t work well in critical situations.
• A Methodology has to take into account the sociological aspects of software development, for example of team dynamics, corporate and departmental politics, career ambitions, motivation, promotion and the desire for personal growth, job security and empowerment. For these sociological aspects are often the most critical ones with respect to the success and failure of projects, neglecting or ignoring them could be dangerous, even if a Methodology works very well for all other aspects of the development process.
• Methodologies must clearly outline the underlying prerequisites, assumptions and believes. They must also show their constraints and boundaries. Methodologies are based on models of the Software Development process, which try to reflect reality – but they aren’t reality. A Methodology may fit very well for one project, but may fail for another – therefore it has to offer all information (such as prerequisites, assumptions, believes, constraints and boundaries) you need to judge whether a Methodology is appropriate for your specific software development business. Many authors and consultants, who write books or give counsel about creating bug free and successful software (or about becoming a good-looking millionaire), doesn’t tell you all of their underlying models and concepts, that’s part of their business.
• While bad processes and methodologies are dreamed up by someone far away from daily business, the good ones reflect the combined experience of many successful and disastrous software projects of many companies around the world. That’s what makes them valuable and useful! However they often don’t tell you the war stories and lessons learned, only some high-level dos and don’ts. Some lessons may be valid for all kind of software projects, but most will be restricted to a given context. If this context is missing in a process or methodology, they may be useless and even dangerous. Even if a methodology combines the experience of all software development projects ever run and even if focuses on those topics that are true for every kind of software, people may interpret the rules and recommendations based on their own background – so there’s a lot of room for misinterpretation. My point is that any methodology not only must outline the underlying prerequisites, assumptions and believes (see the previous point), but must also show the lessons learned which lead to the dos and don’ts.
• With the exception of the boring painting-by-numbers ones, each software development project is a learning experience for all participants involved. The developers may apply new technologies or new tools, the testers will face new bug patterns and all will learn more about the customer’s requirements and expectations (including the customer herself). The challenge is to make use of learning in the course of a running project, i.e. to change and adjust project plans, schedules, requirements, strategies and so on. Each process and each Methodology that ignore and suppress this learning will only be appropriate for a small class of simple straightforward projects, which run in a very stable environment.
• A Methodology must make sense to all stakeholders – if it doesn’t, it won’t work.

The big benefit of any methodology doesn’t result from a brilliant set of methods being proposed by the methodology, but by the fact, that all project participants and stakeholders speak a common language.