To understand how agile came about, we need to discuss earlier software development processes. The waterfall model, is one of the earliest software development approaches. When talking about waterfall, people think about a process where project starts with definition of requirements, a solid design based on the requirements, then implementation or development of the designed software, testing and finally maintaining it. The main goal of this approach is based on a robust requirement analysis upfront before starting the project to accomplish a comfortable level of predictability in terms od cost and project timeline.
Why using waterfall?
1. Breaking down project in sequential phases helps with project estimation.
2. There is a solid approval process at the end of each sequence, making sure transition to next phase carries necessary quality assurance.
1. The biggest defined problem is requirements might not be discovered until final testing which in return starts a child waterfall process to fix it.
2. There should be a cut of point in requirement analysis because without it, technically it is impossible to estimate project budget or timeline using waterfall model. In everchanging demands nowadays, it is very difficult, if not impossible, to fully grasp user requirements and needs before project starts.
in my opinion the biggest limitation of waterfall is cutting of users from the process till the end of implementation. I have experienced this as recent as 2017 where I was working on a waterfall project. In my new role, as frontend developer, I was put together with couple of other developers (and may I say extremely talented developers) in a six months long project. Joining a waterfall development team, I realized that in many cases the final user didn’t even know what the software was going to look like right before user acceptance test. This meant we have got many feedback in a month before delivery and obviously the project manager could only approve a limited number of changes. Even though the final developed feature is still working successfully, neither final users, nor developers where completely satisfied with the final results. To put it in proper terms, even though we met development deadline and project goals, we failed to deliver the required business value.
having encountered above issues, development teams moved toward more iterative approach, such as Agile/scrum, that prioritizes functionalities based on delivering them quickly and in small increments rather than delivering the whole project at once. The development work is broken down in 2 weeks increment called “sprints”, and at the end of each sprint a feature is being delivered and accepted by the product owner and other stakeholders. This approach provides a frequent feedback on project to keep it in the right track and according to business values.
Why using Agile?
1. Testing and user feedback are integrated with development and developers own responsibility for quality of under development feature which enhances quality of the final product.
2. Changes can be incorporated quickly which prevents them from pilling up at the end of the project.
3. In my opinion the key point is that Agile is based on close partnership between development team and the business users to maximize the business values rather than contractual relationship.
People seem to use Agile and expect it to fit all projects, and that to be honest just doesn’t work well in all situations. Being a front-end developer, I realized that many companies are going through transition from back-end to fully front-end applications which in most cases it means requirements are pre-defined based on existing software and new requirements needed to improve it. Using Agile, stakeholders hope to accelerate time-to-market of the new front-end application. This means they will be dictating requirements and project timeline planning using traditional waterfall approach but running the project based on Agile. That causes wrong estimation which in return causes compromising quality to improve time-to-market which consequently results in lower quality product. We should note that some of the good features of Agile namely increase in collaboration and incorporating newly discovered requirements would eventually increase development time and by accepting Agile as the main development approach we need to find a balance otherwise projects start with good level of quality assurance.
Dealing with incomplete implementation of Agile in almost every project I’ve worked on, I think it is necessary to use a hybrid approach that benefits from Agile’s iterative model and includes a defined process for managing scope, costs and project delivery timeline. Agile’s process control makes it easy to deal with changes in sprints and plan and mange them but lacks project-level planning process.
A solution for that could be defining a sub-set of major features which are the core competency of the product using predefined and a rigid upfront plan and introduce other features, one after another, by initial estimation based on lessons from development team and sprint level planning. Then adjust initial estimations after each feature delivery. Most Scrum projects will have at least project-level planning where at least the high-level goals and objectives of the project are defined. However, project-level planning can be as thick or thin as necessary, depending on the nature of the project. The project-level planning forms an envelope around the team and sprint level planning process defined by Scrum. However, the project-level planning would typically be at least somewhat dynamic. Rather than defining a rigid up-front plan that might not change for the entire duration of the project, it would be expected that lessons from the team and sprint level planning process would be fed back into the project-level planning process to make adjustments to the project-level plan as necessary as the project progresses.
I will be exploring my proposed solution in details, in my next post. Stay tuned!