It is this social aspect that must be addressed early on if a new Agile process is to have any chance of actually ‘delivering’.
The need for buy-in
The successful implementation of Agile will provide a range of benefits, from general improvements in quality, predictability and speed through to improved communication via increased human interaction, ensuring a solution that properly meets the needs of the business. But for it to be truly successful, organisational structures and processes must be capable of supporting different ways to plan, measure and report progress and success and more collaborative ways of dealing with stakeholders.
It follows therefore, that Executive buy-in is crucial. Without it, an Agile project management process will have little chance of success. The implementation of Agile will explore weaknesses in current practices and will engender resistance. It will require the examination of other areas of the business that do not work in the same way and consequently throw up barriers to effective operation. And, the inherent transparency of the process – with its public display of current tasks and burn-down rates, for example, can smack of micromanagement and cause dissatisfaction within the delivery teams. Clearly, addressing these issues effectively needs strong sponsorship and support from senior management.
In addition, it is vital that senior management understands and agrees the concept of the ‘minimum usable subset’ and also the need for stability in the project team. Agreeing a minimum usable subset of requirements is central to Agile process and involves using MOSCOW techniques to prioritise requirements in order to provide project contingency. The Executive must, therefore, accept that this may ultimately result in the delivery of less than 100% of any possible solution. Alongside this, there needs to be an acceptance that, as the process places a large emphasis on rich communication at project team level rather than communication driven primarily through documents, continuity will be an important factor in a project’s success and swapping resources in and out will represent a serious risk.
Accepting a reduced number of artefacts
Critics often use the limited documentation in Agile to showcase the weakness of Agile methodologies. However, in truth, Agile does not recommend no or low documentation but places a lot of emphasis on producing the right documentation. Therefore, for an Agile project management process to work the business must accept that there is no solid relationship between project success and writing comprehensive documentation, and that, in fact, it is more likely that the more documentation, the greater the chance of project failure. The fundamental issue is that it is communication, not documentation that is required.
Rationalising stakeholder interaction
Agile processes presuppose that resources, including stakeholder resources, will be dedicated throughout the period of the project. Also that voices will be kept to a minimum with team members being empowered to speak and make decisions on behalf of a wider group. In practice, this means keeping the stakeholder matrix as small as possible, limiting the scope of each stakeholder representative’s feedback to their area of expertise, encouraging continuous active stakeholder participation to reduce the feedback cycle, and ensuring that where there are more voices that need to be heard a single representative will act as gatekeeper to the wider group collating feedback and presenting it as one.
This is often a significant cultural change, especially given the current economic climate which has caused many businesses to become seriously risk averse. At its most extreme, this tendency can encourage those who simply don’t want to be held responsible and will thus delay and avoid attaching their name to anything that could later be used to blame them for a failure. Expectations need to be firmly and convincingly established for each project at the outset, either through a general face to face stakeholder briefing (involving the senior business representative assigned to the project) or through the agreement of individual Memoranda of Understanding with key stakeholder groups.
Avoiding the ‘tyranny of the sprint’
Traditionally, Agile sprints are scheduled back-to-back. However, this approach does not lead to the best results in terms of product quality or team productivity as team members often experience a feeling of ‘being on a hamster wheel’ - just as soon as they get one thing done, they are straight into the next sprint. This ‘tyranny of the sprint’ can cause significant disharmony among team members. Moreover, the inherent transparency of the process – with its public display of current tasks and burn-down rates for example – can smack of micromanagement and also cause discontent.
It is possible to address the first of these issues by providing clear breaks between the scheduling of one sprint and the next. This will allow some respite from the treadmill and allow retrospectives to be scheduled into these breaks (rather than into the sprint itself) in order that the results of the previous sprint can be properly digested by the team and any learning can be incorporated into the next sprint. This will also provide some 'slack' for team members to improve the environment or research better approaches.
The issue of micromanagement is harder to deal with. A surprising number of people view using Agile processes as an attempt to micromanage. However, if used properly, Agile will reduce micromanagement, not increase it. The key is empowerment and trust - the team makes a commitment and management must trust that the team will accomplish it. This is not to say that team members will be given complete freedom to do whatever they want, whenever they want. In reality the level of empowerment will be set within agreed boundaries of decision making. Where a decision is outside the agreed boundaries it will still need to be formally escalated, but this will be the exception rather than the norm. The acceptance of this concept is crucial to the success of any Agile project management process and the business must provide the support necessary to allow this to happen, for without this culture in place the team will rapidly begin to fall apart.
Benefits of successful adoption
Overall, provided that the above issues are properly addressed, the introduction of Agile project management processes offers a range of benefits to any business, including:
Faster time to market enabling more useful and innovative products to be delivered ensuring high levels of customer satisfaction and earlier realisation of business benefits.
A greater degree of team ownership of projects consequent on the replacement of ‘Command and Control’ with a more facilitative and empowering management style.
Improved communication through increased human interaction and active stakeholder participation, ensuring a solution that properly meets the needs of the business.
Avoidance of over-engineering (gold plating) through a pragmatic rationalisation of the stakeholder management process that focuses on reaching agreement within a specifically defined timescale.
Simplification of handover gates and a reduction in the number of artefacts produced during the project lifecycle as a result of higher levels of collaboration and rich communication
Less likelihood of late delivery as MOSCOW prioritisation allows the ‘minimum usable subset’ of requirements to be defined at an early stage.
If implemented successfully and with the full backing of the business, there is no doubt that Agile project management processes will alleviate many of the problems that cause traditional projects to founder or to fail. The collaborative nature of the processes and their considerable flexibility will ensure clarity of purpose from day one and reduce the costs of addressing any misunderstandings, resulting in more projects being brought in on time and to budget.