Are you a longtime Waterfall business analyst or project team member an environment moving to Agile Development for managing projects and performing software development activities on those projects? Then this article may be a decent intro for you. Think of it as sort of a Waterfall ==> Agile Development 101 involving and discussing just a few of the key high-level differences between these two differing project delivery and software development methodologies. From there, it’s more about getting your feet wet on a real Agile project and learning the ropes along the way. Fake it till you make it, but you still need to perform productively and plan to improve with each project… even with each deliverable and “sprint.”
Now… let’s start by defining a “sprint” since I just used that term. In product agile development or a software development process, a sprint is a set period of time during which specific work has to be completed and made ready for review. Certain functionality – agreed to in advance – is created and finalized during each sprint. Where as Waterfall looks at a project as a series of phases… which brings us to our first discussion of key transitional understandings for the business analyst and project team members…
In Waterfall, the software development process is divided into phases that happen once – in Agile Development they can happen over and over again. On the Waterfall project, the software development process is divided into different key phases. In an Agile methodology the software process is basically broken up into a series of sprints – each creating and finalizing a new or set of new functionalities. The end of the project isn’t the only rollout of working functionality… rather that happens at the end of each sprint. Waterfall looks at the software development process as one big single project divided into many phases and deliverables, but each appears only once during the development lifecycle. With Agile, the same phases may actually appear in each sprint. For example, design, development and testing will appear repeatedly rather than only once. The Agile software development project can actually be viewed as a collection of many different projects and can… and often will… grow with the customer’s needs, changing and evolving requirements, as well as their expanding funding and budget availability.
In Waterfall – the requirements need to be right the first time. In the Waterfall model for software development, complex and detailed project requirements must be fleshed out from the beginning. Each change in requirements brings change orders and likely re-work, schedule changes, budget changes and time frame or levels of effort changes. You have to be clear with all the development requirements beforehand as there is no scope of changing the requirements once the project development starts – except through formal change orders which usually aren’t met with great enthusiasm by the project client… they like the one price fits all project funding mentality.
Agile development methodology, on the other hand, is much more flexible. Agile allows for changes to be made in the project development requirements even after the initial planning has been completed. Waterfall model is best suited for projects which have clearly defined requirements and in which change is not expected much or at all – though change is almost always (always actually as I have found). With Agile, the development process supports a methodology in which the requirements are expected to change and evolve. Therefore, if you are planning to develop a software solution or product with changing or evolving customer requirements, Agile is likely the best approach to follow. The end cost in that type of project will likely be less with Agile. Or at least there is a greater chance for end user and customer satisfaction as the final, final result will more closely match – or exactly match – what that custom and end user really truly need and want. How many times does your project client really know what they want at the beginning of the project? Ever? Hence, change orders… and frustrating re-work… in the Waterfall methodology.
Designing, development, testing, happen once in Waterfall, many times in Agile. As mentioned above, on a software project, design, development and testing and other key phases and activities are completed once in the Waterfall model. In the Agile development model the team is following an iterative development approach. As a result, planning, design, development, and testing and other key related activities and other software development phases can appear more than once during the entire software development life cycle (SDLC). It is actually a highly collaborative software development process, thereby leading to better team input and faster problem solving and usually a more accurate final solution that is more on time and on budget if everything goes as planned.
Waterfall doesn’t require heavy customer participation. Waterfall methodology is an internal process and does not require the participation of customers – though it is helpful in most cases involving status review and decision making. In the Agile software development scenario, the approach focuses on customer satisfaction and thus, involves the participation of customers throughout the development phase and throughout much of the project as a whole.
Waterfall is always focusing on the final big picture rollout. The Waterfall model exhibits a project mindset and lays its focus strictly on the completion of project development, while Agile introduces a product mindset that focuses on ensuring that the developed product satisfies its end customers, and changes itself as the requisites of customers change.
Summary / call for input
There are differences, no doubt. Big differences, but the change isn’t impossible to navigate and the benefits can be huge. With Waterfall, if everything is right from the beginning, with the perfect scenario… you can come out far ahead. However, in the Agile scenario it is understood that requirements evolve over time and that functionality is often needed along the way, not all at once at the end of the project. Therefore the real solution is allowed to evolve and scale throughout the engagement.
Readers – what key elements can you add? I’m sure I’ve simplified things a lot here and key differences can be noted by those more experienced in Agile methods than myself. I welcome your input and discussion.