Trending
Thorough planning versus flexibility. Can these business drivers join forces? Agile appears to be winning the battle of application development. The adoption of this method has been increasing vigorously this last decade. Companies are even using similar methods to carry out other – not tech related – projects. So, flexibility it is?
The difficulty with Agile when it comes to software development is that most companies can’t start their projects of as a green field. This means starting a brand new project, clean slate. Without legacy from existing infrastructures and technologies Agile adoption would not only be a lot easier, but also the most logical option if you want to increase innovation and anticipate (or cause!) disruption. After all, the chance for innovative solutions is much higher when a project has minimal scope definitions.
The impediments in Agile adoption are amongst other the existing IT systems that are built based on different, less flexible methods like Waterfall. Often the two worlds collide which causes serious problems. So, if you still want to create some disruptive force within your organisation, dealing with the of Waterfall and Agile is a substantial challenge.
Why Agile?
Agile arose because practice proved that is was difficult to successfully complete large software projects. You can’t actually define all the requirements and functionalities of the final product in advance. With Agile all needed competences are united in a self-managing team that creates a fully functional end product every few weeks. It usually starts out with little functionality, but together with a representative of the future users the team decides each cycle which new functionality will be added. An additional advantage is that the product is thoroughly tested, because after a cycle the final product must work. If you’re dealing with a (heavily) changing environment where speed is more important than quality, Agile method is the way to go.
Why Waterfall?
The Waterfall model is a sequential (non-iterative) design process. In the Waterfall method you determine in advance exactly what functionalities you want and the development team builds exactly according to the defined specifications. After development and testing you will have a working end-product. When it’s exactly clear what the end result should be, extensive documentation is important, the scope is not likely to change and the first time right quality is more important than speed, Waterfall method is a fine way to develop stuff.
What if you are using both in your environment?
Unfortunately you can’t always choose freely between these two ways of working. On the one hand you have to deal with existing ICT that is built according to the waterfall principle and trapped in a strict application life cycle where releases are scheduled at fixed times. On the other hand, you want to build new software with Agile to move quickly into production and being able to change rapidly. Due to the different duration of the production cycles these methods don’t really .
The new software must often work with the old software, creating friction. Well-defined APIs and protocols for communication won’t help you here, because the old systems can’t change fast enough to fit into the iterative cycle of Agile development. Moreover, these completely different ways of working may even prevent the developers from understanding and working together.
Is it fixable?
This post from David Taber might help you out with a few tips to combine these methods. But overall, there is no simple solution here, unless you could start all over again of . But, as I said earlier, that is often not the case. Another solution is creating a second IT environment so you can go for a two-speed IT solution. And if that’s not an option either, you will need to accurately define the scope in what kind of projects Agile can be used. This means that some parts of your application landscape aren’t compatible with Agile. Then you have to take the underlying technology and process developers into account. Other parts of the landscape can first be converted so it can be incorporated in the Agile development cycle.
Why change methods?
Is Waterfall bad? Not at all. In some cases it works great. But the duration of projects prevents you from being flexible, adaptable, and scalable. Newcomers in markets, start-ups, do have the advantages to start from scratch in a green field. These competitors have embraced an agile way of working and can develop and scale quickly and put your business offside. Maybe Agile is more mindset than method. Agile expert Michael Dougherty wrote about how you can implement all values from the Agile Manifesto, but still be off target. Also I recently read this interesting panel discussion of Agile Europe 2016 that goes into detail about this, and states: “There is no one true way or one definitive set of methods when it comes to navigating the ambiguities of a rapidly changing world.”
Whatever way you pick, the important message here is to not get stuck in your old IT infrastructure due to a method that is not flexible enough. In that case you will be cornered. You do have a choice: disrupt your own business to meet the on-demand economy or get disrupted by others.