So “DON’T!” might sound somewhat opinionated but this is a blog and that’s what blogs are for. As promised here’s an brief explanation of why your should think twice, and then think again, about building your own methodology from scratch…
When we (p&p) started think about this we didn’t think of it as a classic buy vs. build decision but really it is. Thus it comes with all the attendant pros and cons of buying something instead of building your own. In the case of “buying” a process many of the drawbacks normally associated with the buy option simply don’t apply.
The principle drawback for buying something is that you don’t 100% control it and it may be hard to adapt to your needs – think a piece of shrink wrapped software or a house. A process is different. With a process you can change it and agile processes actually expect you to incrementally change them! By starting with an off the shelf process and modifying it over time to meet your needs you also avoid most of the drawbacks normally associated with the build your own option, namely; lack of standardization.
Reusing an existing process, say Scrum or XP, also allows you to leverage the existing training materials and tools. It also allows you to engage outside trainers and coaches more easily and to reuse existing knowledge from the community of practitioners and potential hires. None of which you could do with your own custom process – at that point your own your own.
There’s another reason I’d pick buy over build. Creating a methodology is not an easy thing, many people have tried and only a few have been successful – many of them were a lot smarter than I. Even those successful methodologies took time to mature, often over several projects. It’s also much more expensive than you might think, simply in terms of the time it takes to define your process, document it and then train people on it. Buying into another process reduces both the risk and cost of rolling your own from scratch.
Of course with any buying decision you still need to evaluate the potential purchase before adopting it fully. It’s no coincidence that many people recommend running a pilot project within your organization prior to rolling it out more widely.