4

Is the building process such as waterfall or agile used to implement a system, linked to the way an enterprise system is rolled out in an organisation? As an example: A system is developed using an incremental approach and is implemented into the organisation as each increment is finalized. or A system is developed using the waterfall approach and is implemented into the organisation using a big bang deployment?

Does prior studies always combine the natural pairing such as waterfall and big bang or incremental and phased, or does it consider the roll out of the system to be separate from how the system is implemented?

3 Answers 3

1

There's a relationship between the development methodology and the deployment of the system.

Can a system be implemented with a waterfall process and then be implemented using a phased approach into a organisation?

Yes, it can be. But that can be expensive, especially for large-scale software systems or mission-critical systems.

Is the building process such as waterfall or agile used to implement a system, linked to the way an enterprise system is rolled out in an organisation?

It can be. It partly depends on the relationship between the receiving organization and delivering organization. The choice of methodology may give options or make some options more feasible.


On one extreme, you have a purely sequential waterfall where you don't have an implemented, integrated, and tested system until the end. You don't have code until after your design is "finished" and you don't have tested code until after all the code is "done" and you don't release or deploy the code until after it is tested.

Once the software is delivered, the receiving organization has a options. First, they can choose to cut over to the new system immediately or deploy the new system and slowly roll over functionality from existing processes and systems. There are costs and risks associated with both. Cutting over in a big bang may lead to the discovery of unknown problems with no short term solution. Rolling over functionality slowly means that the organization needs to pay for the costs associated with using and maintaining two systems during the transition process.

On the other extreme, you have the iterative and incremental (agile) methods. Many, such as Scrum, call for working software at the end of every increment. However, they don't necessarily call for the release of that working software. In the most lean development process, you can (in theory, anyway) release or deploy working and tested software multiple times per day.

After each increment, the receiving organization can choose to accept or not. Even if the increment is not accepted, there is an opportunity to demonstrate pieces of the software in a test environment and obtain feedback from customers and users. This is an overall risk reduction for both the receiving organization and the developing organization. There is an added advantage for the receiving organization - in brownfield development, the option to interface with an existing system to slowly replace functionality is available. As this happens, the receiving organization may even realize that they don't need all of the functionality of an existing system, causing the project to complete before the new software has the entire set of functionality of the old system (adapting to changing requirements, a goal of the agile methods).

2
  • And then of course somewhere in the middle is phased and iterative waterfall development, you get the best of both worlds. My experience has led me to find these tend to be the most successful (big) projects.
    – maple_shaft
    Oct 26, 2016 at 11:43
  • @maple_shaft I'd agree that the most successful big projects are somewhere in the middle, but it's not really a best of both worlds situation. For example, Spiral with throw-away prototyping can be good for reducing risks, but you can choose to waterfall your final spiral and end up with a less risky development, but close to equal risk in the deployment as a straight up waterfall from the beginning. It's just a bunch of trade-offs between a lot of different factors.
    – Thomas Owens
    Oct 26, 2016 at 12:35
1

The implementation and deployment methodology can be different. The decision depends from the situation.

But, if you are using an agile methodology, an incremental deployment (if possible) will make the agile methodology much more effective. The feedback data of the agile methodology will not come only from testing, but also from real use.

0

No

I've worked on Waterfall projects/programmes that had many phases and sub-projects all being delivered separately (not as frequently as a typical agile project but still not a "Big Bang"). Each component independently followed its' own typical Waterfall approach.

Agile projects do not need to deploy every iteration to production. I can envisage a situation where no iterations are deployed to production for a significant period effectively causing a "Big Bang" release when the deployment is finally made. This would be a perfectly sensible approach to creating an e-commerce website for example. The first few iterations would be tested internally and refined before the full launch. That way there would be less chance of deploying a half-baked site and losing customers. You would, of course, continue to develop and deploy AFTER launch though so although it might initially seem to an external party that the site was developed monolithically, the speed of the subsequent updates would indicate that the project is being run in an agile way.

The choice about whether to use a Big Bang approach has, in my experience had a lot more to do with the organisational architecture and the integration requirements. It would be inadvisable for example to incrementally release an ERP into an environment where an existing ERP is intended to be replaced. This would introduce a whole range of issues for the users (which system do I do this process in now? How do I get a complete picture of the ledgers? etc.) and would introduce significant risk. For a greenfield ERP deployment a more incremental approach is workable. Certainly deploying the various modules of a large ERP incrementally is common.

4
  • I've worked on Waterfall projects/programmes that had many phases and sub-projects all being delivered separately (not as frequently as a typical agile project but still not a "Big Bang"). Each component independently followed its' own typical Waterfall approach. That's not waterfall. That sounds like what Steve McConnell calls Waterfall with Subprojects and can avoid the big-bang testing and deployment effort, depending on dependencies between subprojects.
    – Thomas Owens
    Oct 26, 2016 at 10:20
  • 1
    @Thomas Owens does anybody actually try to do that anymore? Even Royce backed off by page 5 if I recall correctly :)
    – mcottle
    Oct 26, 2016 at 10:33
  • Royce advocated that a purely sequential waterfall (although he never used the term waterfall) was a failed method: I believe in this concept, (referring to Figure 2, which shows a waterfall) but the implementation described above is risky and invites failure. His ideal development process is much closer to iterative and incremental delivery methods. I don't know if I would call them agile, but they incorporate feedback cycles and customer involvement. He recognized the flow of steps from requirements to test, but also the need for feedback loops and customer/user involvement.
    – Thomas Owens
    Oct 26, 2016 at 10:36
  • 1
    Yep, that's the way I read it too. The big IT in-joke; a thirty year dead-end because a decent (for the era) paper wasn't read and understood. Oh the irony...
    – mcottle
    Oct 26, 2016 at 10:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.