Agile can be a very effective project delivery methodology but when is it right to use?
Agile can be a very effective project delivery methodology when it is executed correctly.
However, the first challenge is not how to deliver a project successfully in an Agile way but to assess when the use of Agile is most appropriate.
Agile can drive significant rewards by increasing the speed of delivery and benefit realisation by consistently targeting those requirements within a project that will deliver the greatest benefits, however it is not a one-size-fits-all approach.
An Agile approach attempts to reduce inherent project risk by embedding the business in the team and breaking a project into smaller segments, providing more ease-of-change during the development process. A key emphasis is on fulfilling the business need via speedy delivery and low cost, whilst technological or engineering excellence is generally of lesser importance.
The aim is to produce high-quality systems quickly, primarily through the use of iterative prototyping, active user involvement, and computerised development tools.
When is Agile most successful?
In Quay’s experience for Agile techniques to be successful there needs to be a certain set of circumstances present within the organisation as well as a thorough understanding of the type of project being embarked upon.
To help make this assessment Quay has developed the following checklists to help organisations when they are considering the use of Agile. These checklists can be played back against an organisation’s business case, risk profile, current delivery capability and the nature of the project to assess if Agile is the optimal approach.
The first checklist concentrates on Agile’s key strengths and weaknesses in comparison to the more traditional Waterfall or Iterative approaches to project delivery:
- The operational version of an application is available much earlier
- Produces more business focused outcomes at a lower cost
- Greater level of commitment and ownership from business and technical stakeholders
- Produces a tighter fit between user requirements and system specifications
- Concentrates on essential system elements from user viewpoint and provides the ability to rapidly change system design as demanded by users
- May lead to lower overall system quality and scalability issues due to inconsistent designs within and across systems
- High cost of commitment required on the part of key user personnel, especially the business ‘A’ team
- Project may end up with more requirements than needed due to ‘gold-plating’
- Risk of difficult problems to be pushed to the future to demonstrate early success to management
- Potential for violation of programming standards, inconsistent naming conventions, inconsistent documentation and lack of attention to later system administration needs
Once it is determined Agile would fit within an organisation the next step is to assess if Agile is suitable for delivering the specific project. The below checklist identifies the key characteristics a project needs to lend itself to an Agile approach:
Where most appropriate to use Agile for a project
- Project is of small-to-medium scale and of short duration and application not infrastructure based
- Project scope is focused, such that the business objectives are well defined and narrow
- Users possess detailed knowledge of the application area and Senior management commitment exists to ensure end-user involvement
- It is not possible to define requirements accurately ahead of time because the situation is new or the system being employed is highly innovative
- Team composition is stable; continuity of core development team can be maintained
- Technical architecture is clearly defined and key technical components are in place and tested
- Development team is empowered to make design decisions on a day-to-day basis without the need for consultation with their superiors, and decisions can be made by a small number of people who are available and preferably co-located
Where least appropriate to use Agile for a project
- Large infrastructure projects, such as corporate-wide databases or real-time or safety-critical systems
- Systems where complex and voluminous data must be analysed, designed, and created
- Project scope is broad and the business objectives are obscure
- Applications where the functional requirements have to be fully specified before any programming
- Many people must be involved in the decisions on the project, and the decision makers are not available on a timely basis or they are geographically dispersed or disengaged
- Large project team or multiple teams whose work needs to be coordinated
- Many new technologies are to be introduced within the scope of the project, or the technical architecture is unclear and much of the technology will be used for the first time within the project
The above checklists are not exhaustive and will not guarantee a successful Agile delivery. However, they will assist in ensuring the project delivery approach selected, be it Agile or not, has been given due consideration, is fit for purpose and the project is set up for success as best as possible before it commences.
We believe that quality thought leadership is worth sharing and encourage you to share with your colleagues. If you’re interested in republishing our content, here’s what’s okay and what’s not okay.
To speak to our team about how we can help your business deliver better projects, please contact us.