Is Waterfall the right process for software development?
Does it enable the creation of software that meets user needs?
After a lengthy debate, we’ve decided Waterfall is the future for Bluefruit.
In an effort to better mesh with the worldwide business community and match our processes to the long-standing waterfall world, Bluefruit Software is moving to a Waterfall software development process. The closed, siloed nature of Waterfall that ignores the distraction of new knowledge from testing, will enable us to adhere to rigid development plans created by architects prior to the project start. While there might be some sacrifices, this should allow us to deliver consistently against the planned deliverables and tick all required project plan boxes. Plus, we’re not sure client’s like getting to have code every two weeks. They might prefer to wait for months and then check in when we are close to being finished.
According to one of our engineers:
“Waterfall is an excellent process for software development when trying to work with in very strict controls. We will just have to assume that everything possible is known at the start of the project, that nothing will change as the project progresses, and that if the client wants to add new requirements or make changes to the scope – they are happy to wait for the next project.”
We’re sorry, but we can’t do this.
Bluefruit is sticking with Agile. There is no way we can consider a project management process that starts to fall apart when faced with inevitable changes, that are a natural part of a project lifecycle. We know our clients and we know their end users and if there is anything we can guarantee about a project, it’s that by the end, things will change to ensure the project is a success.
Even if it’s just for an April Fools’ joke, pretending not to love a software development process that enables us to take what we learn in development and use it to create the right software solutions for our clients and their end users? We can’t do it! For us delivering code every two weeks for critical client feedback, continuously analysing user stories and client requirements, and testing constantly means that everything works in balance. Keeping costs down and ensuring that our clients end up with the code that they need. So, we’re sticking with Agile, thank you very much.
Sorry for the false alarm.
If you are a part of a software or product team and are interested in how Agile can work with waterfall processes, let us know. We’ve done a lot of work with companies who are currently waterfall but are interested in transitioning into a more agile way of working or who are happy for their outsourced development team to deliver software in an agile way.
And if you’re a software engineer who would love to work with an Agile obsessed company, check out our careers page, we’d love to hear from you.