One area (among others) where I can be a little pedantic is when a client tells me they are “adopting” methodology “xyz.” I quickly try to correct them saying “you do not adopt a methodology, you construct it.” Yes, there are many pre-built frameworks available for you but, in the end, text book methods rarely fit right out of the book, and if you do not adapt your chosen framework to the context of your project, then you are setting yourself up for wasteful challenges.
A classic example of this is the Rational Unified Process, or RUP. OK — I’m going to come out of the closet and admit I liked RUP. Yes… there, I said it. RUP was great, and my enthusiastic embracing of agile was simply driven by a manifesto that captured pretty much how I was using RUP to construct the methodologies I used for projects. RUP had a lot of good things going for it: it was iterative, it had phases (when properly applied), it helped bring focus to activities, it was risk driven, and it could scale down from the largest project to the smallest one. And therein lay the death of RUP.
RUP could handle projects on the scale of a national air traffic control system, and could also be tailored down to handling even a small team-based project. One practice in RUP was to “construct” the application of RUP, or the instance of RUP you would use for your specific project, before actually starting the project. This was known as the “development case”. The problem was that RUP required tailoring by “scaling down” – meaning that you needed to throw out practices. This generally meant you had to know RUP inside out to know which practices you could safely discard. Few people outside of a skilled Software Process Engineer did and so, in most situations, what I saw were small teams of 10 people working on a year long project using RUP practices intended to manage a project of thousands. There were few project managers or software engineers who were willing to discard practices; they simply adopted RUP wholesale, rather than construct the specific methodology they needed for their project. They adopted, for a 10 person project, a methodology with practices, roles, and artifacts suitable for a national air traffic control system. No wonder people disliked RUP.
In my view, RUP as a process framework was the right idea, it just had the tailoring idea backwards. Instead of tailoring down, what if we “built up” the methodology we were going to use. If we start with the smallest methodology, say a team kernel, and then had a means for adding practices as our circumstances dictated, maybe it would be more successful. I have always thought Scrum — or something “scrummish” — could be a good start for a methodology kernel because the focus in Scrum is on social practices rather than technical practices. Fundamentally, is Scrum is a way for a group of people to work together to get something done. In my opinion, that’s a good place to start.
Starting small and “growing” a methodology is certainly cognitively easier than having to know a methodology in its entirety to know which pieces to chip away. A metaphor I have often used to compare these approaches is the difference between sculpting and brick laying. In sculpting, you must chip away at the marble to discover the artwork inside. One bad chisel stroke and you risk ruining the entire piece. On the other hand, laying bricks is far more tolerant and, with apologies to professional brick layers around the world, requires less skill to get something workable. Even I can lay a few bricks and create something useful, but I certainly couldn’t sculpt anything artistically pleasing.
We need to add one more concept to the idea of growing a methodology, and that is practice pruning. One risk in building up a methodology is that, eventually, some of the practices become obsolete as the team becomes more familiar with the system. Practices not contributing any value consume time and effort. One example is is what I have seen happen when I asked teams to create “use case realizations” when they accepted a scenario for development. This was useful when there was still a lot of architectural risk and unfamiliarity with the architecture; however, once the team was comfortable with the architecture, creating the use case realizations by rote was a waste of effort, so we dropped the practice.
So what I am suggesting is that we should take a pull-based approach to building a methodology — where the changing needs of the project drive the construction of the methodology for that project. This is also an argument for the process of methodology construction being an ongoing one, where we are continuously adding and pruning practices. This does not mean we will have a babel of individual and idiosyncratic methodologies throughout our organization, good project governance is still part of a well run organization. What it does mean is that the way the project satisfies governance objectives is constructed from organizational practices that are appropriate for that type of project. Why would we use the same specific governance practices appropriate for developing a national air traffic for a small 10 person project?
There is a wealth of guidance available for constructing methodologies, and for understanding practices that can help mitigate projects risks. Boehme, Kruchten, and Cockburn have all constructed models for assessing project risks and for selecting appropriate practices based on project context parameters (e.g. size, risk, legacy architecture, etc). Some enterprising organizations have even developed tools which advise on appropriate methodological practices for a project.
The bottom line? It’s better to construct than to adopt, and there is help to show you how.