Build your own!

Lately I got a question about my experiences in waterfall and agile development models, as two separate things. I started to think about development methodologies and realised based on my own experiences that it should be seen as a strange question. And as I got more and more involved in the question the more time I spent on thinking on the matter. A development model is a working model that has to be carefully put together to fit the specific purpose, the culture, the governance model, the architecture processes, the organisation, the finance model, and other things. It has to be adapted to its environment. I often meet people that scuff at waterfall method. I wonder if they understand that they probably scuff at themselves and their own ignorance. Waterfall is the name of a structured sequential process of activities to be performed. It is common to most industrial processes. The name comes from a metaphor; “Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back”. To me all software development processes have waterfalls, small ones and big ones. The question is how many interations (pilots, sprints, etc) you plan in order to achieve the objectives. Each result will be hidden until it is delivered, and the possibilities to turn back are limited. The spitting on waterfall as a method is buried in other aspects like to much documentation, too much time consuming controls, lack of dialogue with the business, lack of adaption to the type of case, disturbance from annoying architects, and more. It is not about waterfall. Waterfall and Agile are both IT language. I think it is time to come out of the bubble and be professional as other industry sectors. Developments are, whether they are done under projects or maintenance, a recurring process. As in any other industry it is about continuous optimisation of the processes. Instead of talking methods we should talk about processes and procedures. First of all we must agree what environment the developments recide in. The following questions have to be asked;

• What is the governance model?
• Is there a project steering model in place?
• Is there architecture and architecture processes to be integrated?
• Are there any organizational aspects to align with?
• Will it be development teams at many geographical sites?
• Are there cultures that have to be taken care of?
• What type of developments do we have?
• Are our projects managed under a portfolio?

Then we build a basic model based on best practice from all models available that meets the answers on the questions. The basic model should be built like a framework aligned with steering/governance models, architecture and with room for adaptations to different types of development. For instance, Integration, App, Webb and Embedded software development all require different working methodologies. Don’t forget to include both new project based developments and developments under maintenance. Create a mindset where you build your own process influenced by different official methods. What is the meaning of saying “we use AUP v 1.1”? My experience is that selection of a specific method tends to create focus on a discussion about how to implement the model in practice, rather than focus on what to deliver. No, I think it is time jump out of the IT bubble and proudly build your own optimised process based on your business. Give it a name. Apply procedures for continuous improvement, influenced by the lean movement involving all participant and stakeholders. Keep it simple and flexible, and never let the process become more important than the result it shall produce and the business it shall support.