B.1 Reduction of risk
Many of the risks seen in traditional projects are reduced in Agile as the approach itself mitigates them. These risks are described below.
B.1.1 Time or budget overruns
Agile approaches expect delivery regularly and frequently. This will provide early signs of potential time or budget issues. In addition, low-level timeboxes, or sprints, are normally two to four weeks long. We therefore have a regular indication of progress; the periods are short enough to be able to resolve any time or budget issues before they become major.
B.1.2 Delivering the wrong solution
All key stakeholders are continually and actively involved, feeding back early and often. They also benefit from regular deliveries, and can provide feedback on these to improve future ones. This ensures that the correct solution is created.
B.1.3 ‘Us and them’ culture between stakeholders
Stakeholders are brought together to form collaborative teams. This creates trust and openness, and consequently helps to eliminate contention or misunderstanding.
B.1.4 Poor communication
Cross-functional teams naturally communicate with each other and among themselves. This does not, however, remove the need to communicate with other stakeholders.
B.2 Considerations of risk in Agile approaches
The following areas of Agile can add risk to the initiative if they are not working properly. I will now explore these in more detail.
B.2.1 Customer involvement
One of the key reasons Agile initiatives go wrong is that, for whatever reason, the required business resource is not adequately engaged and involved. This can lead to requirements being specified by the wrong people, which potentially jeopardizes the quality and usefulness of the delivered solution. There can be many reasons for lack of engagement, but it is important that it is detected early and that steps are put in place to correct the situation.
A true measure of success of Agile initiatives is customer satisfaction. If this is not the case, it could point to other problems, such as lack of customer involvement, or communication problems within the team.
B.2.3 Frequent delivery
Agile initiatives should be delivering regularly. If this is not happening, it could point to various issues in the initiative.
B.2.4 Iterative feedback from real end-users
Iterative feedback is central to the Agile approach. It ensures that the delivered capabilities will satisfy the business needs of the organization. However, there are some situations which will need managing as they may result in loss of control in the iterative development. Early recognition of these signs can help to prevent an Agile initiative going wrong.
Agile in practice
I once had to rescue a failing Agile project. The project was to produce a new solution for the management of patient information leaflets. The product owner (from our company) was a perfectionist and also was trying to cater for every situation that could occur, however remote. Every time she saw the emerging solution, she made many changes and comments. At the same time, the developers, who were external, would not argue or contradict her. I introduced a business analyst from our company who was able to mediate between the two and help each side to see the real importance, and therefore the priority, of each request. This was also helped by a reminder of the deadlines and budget on the project.
B.2.5 Proxy users
The point of iterative feedback is to involve those who will eventually use the capability in its development, feeding back on early versions and hence ensuring the final capability meets requirements. It is desirable to have these end-users as team members, and every effort should be made to do this. For this reason, using proxy users to represent the needs of user populations should not be common practice.
This may not always be possible, however, and roles such as business analysts may adopt the position of proxy user. This has introduced risk into the final solution, and it is imperative that the solution reaches the final population as soon as possible so that assumptions can be validated and assurance gained that the solution really does meet requirements.
An example of using proxy users is in development of websites where the end-user is the general public, and it would be difficult to incorporate them directly into the team. In this case, ‘personas’ can be used. This technique is where the population is divided into types of people who need to use the website for different reasons. Proxy users can then represent these personas.
However, many assumptions are made using these methods and it is advisable to release versions of the website early and often to gain real feedback.
B.2.6 The helpful developer and the perfectionist user
Developers are creative people and want to please. As a result, sometimes they can be over-helpful or want to add unnecessary details. If the user is over-demanding, or a perfectionist, the iterative development may never finish; the developer is always honing the feature and the user is never satisfied. The Agile demand for ‘delivery on time’ and the team’s focus on its objectives help to avoid this situation, but it is a potential risk that needs to be managed.
The situation can worsen when the developers and customers are from different organizations, as this behaviour can soon incur high costs.
Although both the developer and the user are empowered, if this situation is known to exist is it good practice to involve another person from the team in discussions. Being slightly objective, they can act as a counterbalance, telling either side when it is acting unreasonably. Business analysts are often good candidates to do this as they can normally see both perspectives as well as the bigger picture.
B.2.7 So what is the ultimate solution?
All parties need to understand the final state of the iterative development. Sometimes iterative development is fast-moving, and the pace of change can cause confusion over exactly what the final state is. Good configuration management and documented review discussions will assist this.
Configuration management will ensure that the final state is captured, and provide an easy way to revert to previous versions should changes prove not to be viable or required.
Documented review discussions will ensure that everyone understands the decisions made and will avoid future confusion when people cannot remember having made decisions. This, together with good requirements management, will ensure that the solution is maintainable, supportable and testable into the future.
B.2.8 Iterative feedback and ‘good enough’
The concept of ‘good enough’ is key to many Agile approaches. It means doing enough to ensure a workable solution that is of acceptable quality. However, there are three challenges that need to be considered.
The first challenge is that the customer must understand when a solution is good enough and when further work would not add value. This is complicated if customers are perfectionists. All parties need to understand that it is good enough to provide the required capability in the organization that meets the required, predefined, quality criteria.
In fact, this applies not only to the customer, but also to those providing the capability, as sometimes they will want to add features that are not necessary. The question to ask is, ‘What will happen if the change is not made?’ If the answer is ‘Nothing’, or ‘No real impact’, then the change is probably not required. Like prioritization, this is not easy but necessary for Agile to work. It works best if time and cost are fixed, as the team becomes focused on deadlines, and inconsequential changes are then probably disregarded as a matter of course. Of course, the time and cost have to be realistic – Agile will still require good estimators, even if timescales become clearer as the initiative progresses.
The second challenge is managing expectations. As part of the iterative feedback cycle, customers will be shown parts of the solution that may appear to be complete and ready to use. In fact, the purpose of the demonstration is to get feedback and there may be a lot of work still required before the solution is usable. It is therefore always important to state clearly the status of the solution, particularly for customers new to the approach.
The third challenge is remaining aligned with the team goals. For many reasons, extra features may be considered during the development of the solution. If these do not align with the goals, however, they need to be disregarded, even if they potentially add value.
B.3 Other areas for managing risk
In addition, the following areas are important:
- Getting acceptance of the Agile process in your organization
- Clear ownership of initiatives by senior business leaders
- A business vision that is clearly stated and understood by all
- An acceptance in the organization that change is inevitable
- Collaborative working of all stakeholders
- Appropriate empowerment of Agile teams
- All stakeholders understanding their roles
- Teams maintaining a consistent and sustainable level of effort on the initiative
- Reviews and testing being integrated throughout the process, ensuring solutions will meet requirements
- Demonstrable incremental delivery of business value
- Constant referral to and review of the business case.
More guidance on these areas can be found in The Agile PMO Pocketbook (2012) and The Agile Project Framework (2014) from the DSDM Consortium.