What is a Methodology?

>> Saturday, December 12, 2009

Since the beginning of my IT career some 25 years ago, I have entertained a sound reserve towards software development methodologies. I have always found it ironic that in our industry we label "methodology" a checklist of documents and a set of document templates that must be produced or filled in at different stages of a project. Such "methodologies" are very good at specifying what "deliverable" must be produced and when they should be deposited but usually very silent on how exactly do we produce the ultimate deliverable, i.e. the software system itself. It is true, that traditional methodologies also describe a series of software development phases and how should be doing what at each phase. But again, how exactly do we work within each phase was/is often left to the imagination.

For this reason, I was always more attracted by the literature that describes and discusses how to effectively and efficiently design software and how to write and manage code and systems. Strangely, this literature tended to shy away from the term methodology and preferred to use expressions such as "software engineering".

It was therefore refreshing for me when the Agile movement came into light. For once, I was hearing and reading about a "methodology" that corresponds to my own experience and inclinations. One that I could relate to. One that talked about practices, techniques, systems and tools. That puts the emphasize on the delivery of software instead of the delivery of documentation. An approach that prescribes the use of tests, of continuous refactoring, that talks about team organization, work habits, and human interactions. Those were the early days of the Agile movement with a lot of talk about extreme programming and unit testing.

However, methodologists at heart were not to be left on the sidelines. They woke up and smelled the coffee and had the intuition that there might be something for them in this new trend. Since it was difficult to sell the idea of a list of documents for each of the different stages of an agile project (agile is lean and iterative remember?) they instead invented a new religion with priests (scrum masters) and ceremonies (dailys, retros, demos etc). I am not arguing that all this is B.S. but I do see a dubious trend when people consider they are agile because they are holding SCRUM ceremonies. I may be naive, but to me, ceremonies are meant to be (or should be) a means to help teams and organizations increase their agility. If ceremonies become an obstacle to agility, then we should get rid of them and invent something else. 

On the same basis, we now find "agile" tools on the market that help organizations follow the SCRUM way of doing things. Considering yourself agile because you use such a tools is completely fallacious. I personally consider it much more important, for the sake of agility, to use automated testing tools and build systems then to use a SCRUM compliant project management tool.

So long,


0 commentaires:

Post a Comment

  © Blogger template Webnolia by Ourblogtemplates.com 2009

Back to TOP