In the first part of this series, we covered a short history of Agile and had a brief look at its four underpinning values. Considering the many misconceptions out there, it is important to stress that these values are not to be considered opposites, but preferences. The comparison reflects an internal consensus that all items are valuable, but those on the left are favoured over (not instead) those on the right.
| 1 | Individuals and interactions | over | Processes and tools |
| 2 | Working software | over | Comprehensive documentation |
| 3 | Customer collaboration | over | Contract negotiation |
| 4 | Responding to change | over | Following a plan |
A recent study by McKinsey shows that IT projects with budgets of over $15 million still cost 45% more than planned, are completed late (by 7%) and deliver significantly less benefits than anticipated in the business case (56% less). While some organisations have successfully implemented Agile to address these key issues, some important questions still remain:
- Will Agile work for your organisation?
- Does Agile work outside of software development?
- Can Agile be used for any of your projects?
These questions have been the subject of much debate and plenty of studies are available to support both sides of the argument but overall one thing is clear – the effort required for a successful implementation cannot be underestimated and such an undertaking of Agile practices can be significantly disruptive to business-as-usual.
At Nine Feet Tall we think that four key factors must be considered when looking at a change/adaptation in the way you deliver projects – People, Processes, Technology and Governance.
Agile vs. Traditional\Waterfall
At Nine Feet Tall we think that four key dimensions must be considered when looking at a change/adaptation in the way you deliver projects – People, Processes, Technology and Governance. These dimensions will help you understand whether Agile (or elements of Agile) could be adopted by your organisation, or whether the traditional, waterfall approach is more suitable.
| Agile traits | Traditional/ Waterfall traits | |
| People |
An adaptable/flexible culture is present or could be achieved Small dedicated teams are desired rather than cross departments with a high degree of coordination and synchronisation Individuals take ownership and responsibility of tasks Buy in from all stakeholders is available, especially those affected by the change |
The organisational culture is less open to sudden changes and slightly more bureaucratic
Departmental set up exists where individuals are not likely to work full time on one specific project Team coordination/ synchronisation is limited to hand-off points |
| Process | Flexibility exists within requirements/scope to change at any point
There is availability of a customer or a tester in some form throughout the project A prioritisation process is desired, allows for partial success. |
Fully scoped requirements are available and there is limits to scope change.
Testing is only required at milestones or stage gates. Delivery is predictable and sequential |
| Technology | Strong visibility of progress
Collaborative approach in all forms of technology Integrated processes and systems |
Visibility is only available to elements of the team that require it.
Segregated processes and systems exists |
| Governance | Collaborative leadership approach
Shared responsibility for success is present or desired A governance structure exists that can be adapted and flexed up or down depending on the project requirements. |
Forceful, Autocratic or managerial leadership is present.
Responsibility sits at the top of the project team with project sponsor and manager Top down concrete governance processes are preferred. |
It should be noted that delivery can be achieved in many ways not just by implementing an Agile methodology. Efficiencies can be achieved through improving processes, improved management information and better stakeholder engagement, to name a few!
To summarise it is evident that Agile and the Traditional Waterfall approach both offer very different approaches to project management and careful consideration of the above four dimensions is required to understand the fit and feasibility of the approach to your project and organisation.
If the decision to implement Agile or an element of Agile is made caution should be taken with the method in changing the project approach. Individuals should be mindful that the transition is not an overnight one, and that instead incremental steps are required in order to harness the benefits and effectively operate Agile project management.
