Who is doing Waterfall projects these days? From my recent experience, it seems Waterfall has a bit of a stigma attached to it – almost everyone wants to go Agile. So, just in case, the image below might be a nice refresher of how Agile is different from Waterfall:
It came directly from this page: http://www.agilenutshell.com/agile_vs_waterfall
Problem is, what we often call Agile, is, sometimes, not quite as Agile.. I think Leon Tranter has really nailed it here: https://www.extremeuncertainty.com/most-common-reason-agile-fails/
We may call it Scrum, we may call it Agile.. But, in reality, it is, often, some sort of waterfall where we are trying to use Agile terminology to make it look like Agile, even though it’s really not.
And, I think, there are reasons for that because not every project can be delivered through a set of bi-weekly iterations. For example, I am just coming off a project that took me a few months to deliver, and, even though we started to share our builds with the users in the UAT environment long ago, it’s only now when that project is being released to production, and it’s only now when the real testing is happening.
Because it just would not make sense to have it in production before the product has reached certain level of maturity.
For example, consider these types of projects:
– An XRM implementation where an existing .NET application is to be replaced by a Dynamics solution
– An existing CRM system which needs to be replaced by Dynamics
In many cases, those projects are not, necessarily, “all or nothing” in terms of the feature set delivery, but they can come very close to it. How would you replace an existing CRM system with Dynamics unless you have migrated the data and unless you have covered all of the basic business processes in Dynamics? How would you move your users from a .NET application to Dynamics unless, again, they can do most of what they used to be able to do in Dynamics?
We need to do the data migration, we need to cover all of the basic functionality, we need to provide reporting.. Until that is done, all we can do is keep delivering incomplete versions of that new Dynamics solution to the UAT environment, but it’s not going to be easy to convince the users that they should actually spend any significant amount of time testing those versions since they will have to keep in mind all the limitations while running those tests.
Once the project is in production, though, it can, finally, become really “Agile”. First time it goes live, it will be missing some less important features, but that’s something we can work with in the Agile manner, finally. That’s when we can start doing iterations or sprints, and that’s when we can start deploying the updates in production in the end of each sprint.
On the other hand, consider a project where there used to be no CRM in the organization. It’s only natural, then, to start delivering CRM functionality through the iterative approach, which likely means Agile should work just fine on that type of project.
So, realistically, I think the answer to the question of which methodology we should choose on the Dynamics projects depends on a number of things, but, most importantly, it does not have to be a “one methodology fits all projects” type of answer. It does not even have to be the same methodology for the complete duration of the project. It can be Agile, it can be Waterfall, or it can be some mix/combination of those two.
What do you think?
The decision to go Agile, Waterfall or hybrid is dependent upon the degree of uncertainty at the start of the project . The Agile approach was crafted to deal with high uncertainty at the start of the project. The waterfall approach came out of manufacturing where where uncertainty was minimal. Projects that have a high degree of upfront uncertainty can go more towards the Agile approach. Projects that have a low degree of upfront uncertainty can go more towards the waterfall side. IT hardware projects are often projects where there are low upfront uncertainties. Therefore you would choose more of a waterfall approach. ERP projects should focus on people and their needs. People being people, they change their minds and do not always know upfront all their requirements. Therefore an ERP project is often better suited to an Agile approach. It is just that simple.
I think my main problem/concern/question with agile is that there is a lot of emphasis on the continuous delivery which, from my experience, is usually just impossible in the early stages of the project. At least not until the project (can be CRM/ERP implementation) reaches some level of maturity. Best that approach can do is keep the team focused on the small achievable tasks, but, at the same time, it can have negative impact on the foundation work.