Development process

With new management, the development process is evaluated again. This evaluation led me to discuss what a good development process is and what the phases of development are. I had discussions with several team leaders for gathering the mindset and understand what the assumptions for this development process are.

To my disappointment the mindset was classic waterfall requiring defined steps, explicit products of each process. Where each step needs to be completed fully before continuing the next phase, using design reviews as decision gates.

I won’t repeat why waterfall is problematic, it has been already discussed in previous post but I was surprised that team leaders were still convinced it’s the correct method of developing software.

Why was the waterfall the method chosen by the tem leaders? I’m not sure, but it seems it’s the most straightforward, most understood and vastly used by development companies. It’s also easy to implement as it segments the responsibility between different groups with specified timeline.

My personal opinion is that waterfall is not suitable anymore for development due to several reasons:

1. Software can use short development / release cycles for gradual improvement

2. Requirements are not completely known at design phases, so when they become known, the development has already started

3. Cross involvement is low as each step is handled only by one group.

In current state of technology and solutions, using waterfall is like going back to ancient development techniques and lose a lot of possible gains due to lack of flexibility.