Error getting theme layout

Balancing Waterfall with Agile Methodology – Or Adapt the Tool to the Job…

Posted @ 10:32 am by Robert Balmaseda | Category: Strategy, Web Development Process | 0 Comments

As Alex wrote in “Website Development Methodology – Part 1,” a codified project methodology serves to set expectations for the client and the team on what is happening when and in what order. However, a project methodology is not meant to be a rigid “one size fits all” set of tasks. Rather, it should be a framework for creating success in a project, and should be adapted to the solution, team and client. Bringing in new techniques or refining existing processes enables the team to deliver the right solution to the client in a timely and budget-conscious manner.

Methodology Benefits

A formal codified Methodology provides many benefits to both client and Agency, including:

For the Client:

For the Project Team:

Methodology in Action

That being said, teams need to recognize that a project methodology is not meant to a rigorous, finite set of steps that are set in stone. Instead, it is meant to be a framework that teams use and scale to fit the client problem, solution and need. At its best, the project methodology offers a safety net to the Project Manager (PM) and team providing the framework for the types of questions that need to be asked and answered.

The 4 Phases (Define, Design, Develop and Deploy) and the various sub-phases and tasks outline the steps that need to be taken. This framework is just that: a structure in which to construct ones thinking and to set expectations. Each project has to be mapped to this framework and scaled accordingly. Some project may go through every step in minute detail, while others may skip them. Some steps may take hours while others days or weeks. However, by going through the process of thinking about each step and delivery, the team makes conscious decisions and takes action without neglecting steps along the way. Teams need to learn to scale both up and down according to the project. When too focused on the process, teams can forget how to be nimble, which is almost as bad as teams working in a chaotic vacuum. In smaller projects with rapid turn-around and few resources, the team must adapt the methodology to the problem and focus on the end-result. This can take the form of omitting a deliverable, or delivering it less formally, or spending less time. Regardless, as long as the revised process is communicated to both client and team and expectations are set the project can be delivered successfully.

In contrast, Agile teaches us to focus less on the process and more on the collaborative and iterative approach to developing the final solution. Working in short sprints allows the team and the client to see the solution as it is being built rather than in iterative steps. Agile Methodology has its proper place, but its philosophy can inform and influence a more formal iterative (waterfall) methodology. Teams can use Agile to develop functionality during the Development Phase in iterative steps, allowing for the team to surface issues along the way.

Regardless of the project, teams need to know the rules so that they know when to follow them and when to deviate. Knowing how and when to use the tools in the tool box is the hallmark of a solid team which will deliver value to the client and their customers. And this is the reason we are here in the first place…

Leave a reply

Error getting theme layout