5 Project Management Methodologies and Their Risks: Part 2 – Agile

#project management

As we stated in the first part about Waterfall, we are going to investigate the most popular project management methodologies with the aim to identify potential risks, share our experience from the real life and provide insights on what to keep an eye on.

Methodology 2: Agile

The Agile Manifesto originated as a response to shortcomings of the Waterfall model. The need was to address the linear sequential process in order to keep up with the ever more dynamic markets and customer demands.

Especially in industries like software development where one product release cycle in the classical Waterfall model could take around a year. The customer demands change dramatically in a year. 

How is it possible to shake a status quo and suddenly out of nowhere solve the issues of the Waterfall model?

Of course not everybody can use Agile. Agile is mostly suited for cases when you are able to deliver partial improvements to the product. This is mostly software.

However, some large product installations like elevators can undergo partial improvements over time. Car makers have new models, face lifts etc. Of course you do not go to the car owner and rebuild their car over a night. You rather release new model, model 5, 6, 7, X… Clearly even a hardware can use Agile (e.g. mobile phones).

Isn’t Scrum Agile as well? Mathematically speaking not. Scrum adopts all Agile values and principles and adds its own. From the other point of view, Agile does not have all the attributes of Scrum. While Scrum implements Agile, Agile is not Scrum neither implements nor adopts it.

Six key deliverables and the workflow

Agile is based on six key deliverables:

  1. Product vision statement: A summary that articulates the goals of the product. 
  2. Product roadmap: The high-level view of the requirements needed to achieve the product vision. What are the Epics (customer cases) to be met? 
  3. Product backlog: a full list of all user stories (features) to be implemented in order to create the product as required, ideally ordered by priority. 
  4. Release plan: An action plan (tasks in a timetable) for the release of a working product.
  5. Iteration (e.g. sprint) backlog: The user stories (requirements), goals, and tasks linked to the current iteration.
  6. Increment: The working product functionality that is presented to the stakeholders at the end of the iteration and could potentially be given to the customer.

When teams dive deep into product increment creation, there is a risk of forgetting the big picture. It is an intrinsic part of the product manager’s role to remind the big picture to the team. Especially because when solving individual tasks and their challenges, people might easily slip to solving problems that are absolutely not needed to be solved for the product and customer. 

Another important aspect is making sure that all completed tasks make sense when combined together. In other words, to make sure that the accomplished work can be combined to fully implement a feature, a customer use case or a bigger piece of the product backlog. Often, when this is forgotten, teams end up with many great partial solution that unfortunately cannot fulfil customer needs.

Agile places large emphasis on collaboration, flexibility, continuous improvement, and high quality results. What does that mean? It means that we mostly need a highly skilled team with multi-disciplinary experience. Especially in case of Scrum.

Conclusion - Who should use Agile?

Who should use Agile? Teams working on projects requiring flexibility, having a high level of complexity or uncertainty. Also, have a look at the following two flavors of Agile - Scrum and Kanban.

All projects magaed in an Agile way can be easily tracked in an online tool so that all team members have instant access to up-to-date information and project state whenever they need.

In the next part, we'll discuss the most popular Agile implementation - Scrum.