Though it’s false to say that there’s no wrong way to develop a software project, there are still many right ways to choose from. Let’s take a closer looks at the Waterfall, Agile and Lean methodologies, focusing on what they add to project structure, team composition, the effectiveness of collaboration, and pricing models.
The Waterfall approach (also known as the stage-gate or phase-gate process) has been popular within large organizations, as its strict timeline and budget allow for more predictable development costs. It involves deciding on the full scope of the project and implementing it within an established timeframe. This approach doesn’t invite dynamic change, but it can accommodate some shifts in needs and expectations. Additionally, some hidden costs or issues with the development team might arise while the project is underway, requiring renegotiation of terms, or even derailing the project.
Agile project development, on the other hand, is all about change. It prioritizes delivering small chunks of the project scope within sprints (in Scrum terminology) of a set length (often one or two weeks). Each chunk (or iteration) is a complete functionality usable for end users, which means you can quickly and easily test your business ideas and start building your user base. The iterative approach allows the Project Manager and team to plan their work in such a way that no one ever needs to wait on others before they can begin work. Because work isn’t planned too far ahead, changes to project scope are rarely disruptive.
The Lean methodology’s focus is optimization of resources (including people) and effort. The goal is creating value for the customer by exploiting your organization’s unique strengths. Lean’s main tenets are continuous improvement and respect for people. It can look like a fairly minimalistic approach, exemplified by the Kanban board (used for planning, prioritising and keeping track of tasks).
Project structure
For Waterfall projects, the first phase involves establishing clear project requirements and specifications, including all materials to be provided by both the client and the contractor. Next, the team designs the system they will build based on the requirements. Once that’s done, they can begin implementing their design by building units (parts of the whole system), then integrate and test them. The two final stages are deployment, where the app is launched, and maintenance, during which any necessary changes to adjust the app’s performance are made.
As the name Waterfall suggests, each of these stages “cascades” down into the next one, creating a smooth flow. A new phase cannot be started before the goals defined for the previous one are completed. Market testing with real users begins only after the whole process is done and all the phases have been closed.
Agile projects can also be divided into stages. The first one is already very different from the Waterfall approach, as an Agile project begins with concept work: envisioning the work to be done and prioritizing certain aspects of it over others. Next, a team appropriate for the tasks is composed and given time to discuss the project’s scope and needs with the client. The process of writing code is divided into iterations, each of which ends with the creation of a working functionality. Core functionalities can be market tested as they are developed. Agile is an MVP-oriented approach, allowing you to determine how each major element of your app performs.
Eventually, the project is mature enough for full release - but not before thorough QA testing, training the client’s team to use the product, and making sure the project’s documentation is complete. Once the app is launched, the project team continues to support it, providing optimizations and solving problems should they arise.
The Lean model isn’t too dissimilar, though it’s less specific to software development and can be used in other industries. First, a problem is defined, then measured (regarding how widespread it is and how it impacts the client’s business). A thorough analysis reveals the cause of the problem. This leads to the improvement phase, when the root causes of the issue are addressed, and the newly implemented solutions are verified as effective. The results of the project are observed carefully to make sure the advantages brought by them are maintained and the entire business continues to pursue improvement. The app is introduced to the market after the first solution is implemented, to test its viability and give further development efforts more direction.
The project team
The main division between the Waterfall approach and both the Agile and Lean methodologies relates to cross-functionality. Waterfall teams work in specialized silos. Maintaining effective communication between these silos can be challenging, but the cumulation of talent and experience can be a fertile ground for truly brilliant solutions.
Agile and Lean teams work on specific tasks (the business implications of which are understood by the team), and thus need to be cross-functional to deliver complete solutions. In some cases, e.g. in Scrum, the team structure is defined fairly strictly, with specific roles. Such an approach elevates the leadership role of the Project Manager (also known as a Scrum Master in the case of Scrum, and process facilitator in the case of Lean) - an individual responsible for helping the team plan, prioritize tasks, procure necessary information and tools, and so on. In the Waterfall approach, on the other hand, the Project Manager’s decision-making power is more direct, and they often assume sole responsibility for project planning.
Everyday collaboration in a Waterfall team is limited to the silos. Whenever two or more silos need something from each other, there’s a risk that one will need to wait for the other to provide them with what they need. For Agile and Lean, this is almost never a problem, as teams organize together around obstacles that might affect project schedule. Scrum teams in particular participate in a number of established ceremonies: daily meetings, retrospectives, and more. This framework allows team members to inform each other about the state of their work, ask for help when needed, as well as share successes and responsibility for the project.
The process of cooperation
Regardless of development technology, teams need to communicate with the client to report on progress, ask questions, verify their assumptions and make sure they haven’t veered off the client’s vision. Waterfall assumes that such meetings occur rarely, before and/or after significant phases of the project. This can be great news for busy executives whose time is quite literally money. The Agile approach, on the other hand, assumes more frequent meetings with the client, usually after every iteration. Finally, Lean prefers continuous contact to never lose sight of the client’s goal.
These differences in communication strategies are linked to who is responsible for facilitating the flow of information. In Waterfall projects, it’s more likely that stakeholders will communicate with a Project Manager, who is responsible for gathering project requirements and delivering reports. Agile puts emphasis on direct contact between individual team members and clients, headed by the Product Owner and Scrum Master. In striving to leverage the skills and knowledge of employees, Lean also gives each one a voice and the ability to bring positive change to the whole company (and project).
None of the three methodologies under consideration discourage the use of reports and documentation. The main distinction is that Agile and Lean do away with unnecessary paper trails of things that are unimportant, shifting more focus to direct communication (through in-person meetings or conference calls). This often leads to the creation of more personal relationships between the client and the project team, which in turn facilitates better understanding and cooperation.
Feedback has an impact on this, as well. Both Agile and Lean are focused on improvement and change. For example, there are specific Scrum meetings (retrospectives) which offer the client a chance to offer their insight on the team’s work, along with suggestions for improvement. These suggestions will usually be applied immediately, starting with the following sprint, or as soon as possible. The same is true for the Lean approach, which puts even more focus on process optimization. The Waterfall methodology, on the other hand, offers fewer opportunities for the client to truly impact the project once it’s underway.
Project delivery and deployment differ between the three methodologies, as well. In the Waterfall scheme, the client usually sees the product at the end of development, when it’s ready to be deployed or is already live. With Agile and Lean, the client would have already had access to the unfinished project as work progressed. Additionally, many Agile projects include a period of post-launch support. This can be extremely useful, as unexpected user behavior may necessitate change, while high traffic may require adjustments to the code and/or infrastructure.
Pricing models
The three main ways to plan the budget for developing an app are: time & material, fixed price, and per milestone. Time & material is undoubtedly the most flexible of them, and often the least expensive for the client, as it means paying for the amount of work done, no more and no less. The model takes into account the time spent in the project by each team member, distinguishing between them based on job description and experience (e.g. a Junior Developer’s hour will cost less than a Senior Developer’s hour). The client can make dynamic decisions on team composition throughout the project, adjusting to changing requirements and budget. The time & materials model usually goes hand in hand with the Agile approach.
The fixed price model is fairly self-explanatory: the client and the outsourced team agree on a project scope and a price for delivering it within a set amount of time. While this might feel like the safest approach, it often can’t accomodate shifting market realities. As such, any sudden change to requirements can generate unnecessary costs, and whenever project scope needs to be exceeded, the price of the team’s work may need to be renegotiated. This model is the most applicable for the Waterfall approach.
The per milestone model also involves paying for a particular scope of work completed within a set amount of time. Once this milestone is achieved, the client is billed for it. This means paying for actually delivered functionality (i.e. value), and the milestone needs to meet the client’s criteria, giving them more control over the team’s work. Trouble starts when the price of a complex milestone needs to be negotiated, as each milestone is different and the pricing cannot be based on previously delivered work. As such, this model introduces some extra effort.
Using the right methodology for your business
It would be disingenuous to claim that any one methodology is always superior to the others. When deciding whether to use the Waterfall, Agile or Lean approach, consider the unique needs of your project, as well as the advantage each methodology can offer to your business. If you aren’t sure, you can always consult your technological partner.
Run you project with the approach and toolset that will benefit your business the most.
iRonin.IT’s experts have commercial experience with multiple methodologies, and will be happy to offer advice.
