The article will provide a (very) short overview of Agile software development and Agile project management. It will then look at where an Agile approach to project management makes little or no sense and, some of the possible issues.
Agile takes an iterative approach to implementation. It requires collaboration between cross-functional teams. These do not start with a fully complete or final project plan, but adapt their planning to the environment and circumstances with the aim to achieve evolutionary development and close alignment with changing business needs. Continual improvement and rapid reaction to change are two features of an Agile process. Generally Agile looks at a small number of requirements only.
Software development is a good fit, in most cases, for an Agile approach, where the Agile method allows to quickly adapt to fluid requirements and changes and to only develop what is useful. For project management the combination of Agile with Scrum has the potential to increase the quality of the deliverables, cope better with change and being able to stay better in control of the project schedule and state, even when there are changes.
A variety of projects can benefit from an Agile approach, e.g.
However, while the “waterfall” method may be seen as old-fashioned and unfashionable, there is considerable value in choosing this approach in projects. The waterfall model breaks downs activities into linear sequential phases, where each phase depends on the deliverables of the previous phase.
The waterfall method is suited for all projects – or sub-projects – where there is a clearly defined goal and outcome.
Examples include
These types of engagement have – in most cases – a clearly defined outcome and path to the outcome.
Another risk with a – supposedly – Agile project management approach is to end up with an unworkable and unsuccessful hybrid of both approaches (Agifail or Scrumfall, Water-Scrum-fall is slightly different). This can include:
1. Excessive rules for the daily (Agile) stand-up meeting:
An initial kick-off meeting for the stand-up resulted in excess of 20 rules that people were meant to comply with
2. Jargon without meaning
User stories can be a valuable tool as can be other components of Agile project management but, they must be used in a meaningful way and must be understood by all of the project team
3. Not working as a team
Where several groups have to work together to achieve an outcome, they should:
-
i. Work together as one team: it does not make sense to have several different project meetings for the same project that people should be working on jointly. This especially should include third parties, if they are part of the project.
-
ii. Use the same approach: be consistent with Agile or Waterfall for the entire project team. Things will clash, if one group has a 3-month Gantt chart with hundreds of items, while another has a multitude of user stories.
4. Emphasis on the approach and not the outcome:
It does not bode well, if a fraction of the required people attend the daily stand-up meeting, tasks or user stories are rarely completed and there is an insistence on the rules (“we cannot sit down – this is a stand-up meeting”, “we have run out of time – this meeting must not exceed 15 minutes”). This point carries the highest risk, as it can endanger the whole project. To provide an example:
Realising at some point during vendor negotiation that amongst the 30 user stories that have been worked on, the Legal team has never been involved to review the contractual documents and the contract has to be signed at the end of the week.
Both approaches – Agile and Waterfall have their unique strengths and weaknesses. Care should be taken, when choosing the approach for a particular project. Some flexibility can be quite beneficial with a Waterfall approach, i.e. the initial project plan should not be taken as unchangeable; likewise some rigid structure can be required with Agile. Diaxion has used both approaches with good results.
