Adopting and embedding Agile, what are the challenges?

Currently, there is a tremendous appetite from industry to adopt and embed the Agile way of delivering products and services. Agile has a very strong focus on product delivery. Agile also works well in both project environment as well as business as usual (BAU). When chosen project methodology and Agile are combined, project direction, project management and project delivery are optimized to create a complete project management solution.

Organizations thinking of adopting and embedding Agile in their business units as a way of product and services delivery, need to understand that embedding Agile is the ‘adoption’ of Agile across the organization, whereas “adoption” may require buy-in from senior executives to support and agree the Agile way of working.

It is important that organizations and particularly project managers become more and more aware of the side effects likely to be encountered when adopting the Agile frameworks. Common Agile frameworks available are SCRUM and KANBAN and a combination of the two known as SCRUMBAN. There are also other existing Agile frameworks commonly used in software development.

Most Agile flavours have some common behaviours, techniques, concepts and frameworks and the question is how much of each can be used or how little of each can be used in projects. It is therefore important to have some mechanism to determine some level of Agile maturity or optimum usage. It will also be helpful for Project Managers to know when and how to measure how much Agile is being used or will be used. This measurement can form part of the risk assessment of teams using Agile.

The best time to assess or measure the suitability of Agile in the team or organization, is when you are determining the project approach. The project approach is part of the section of the project charter or project brief. Under project approach, the project manager determines or decides, in consultation with the team and key stakeholders, whether work will be sub-contracted or built by the project team (Make or Buy Analysis and decision). The Project Manager also develops the project strategy or methodology to be used to deliver the project’s objectives and meet customer expectations.

Agile has risk areas of its own, which need to be addressed and assessed during the project charter phase and at subsequent milestones or end stages. Generally, there is relatively less prominence given to the area of risk in Agile however Agile concepts mitigate many risks associated with other approaches (e.g. Waterfall). The level of formality should be appropriate and risks should be addressed during stand-up meetings.

In this discussion we will focus on risks associated with the adoption and embedding of the Agile way of working for the delivery teams. The areas of risks may be scaled, for example, from 1 to 5, where five is the optimum ideal situation. The exercise of assessing risks may be done collectively as a team facilitated by the project manager.

Here are the risk areas, indicating the optimum scale of 5 respectively:

1. Flexibility on what is delivered
Flexibility on what is delivered LEVEL 5: Stakeholders are very comfortable that change is inevitable and needs to happen in order to converge on an accurate product. They are also very comfortable in the role they need to play in prioritising work, and they understand that the scope of the product and the quality criteria are being flexed to protect the level of quality and deadline for what is being delivered.

2. Level of collaboration
There is a very high level of collaboration amongst all parties involved at Level 5. This is typified by a one-team culture and excellent working relationships both internally and externally. High levels of trust exist and a desire to be helpful is prevalent

3. Ease of Communication
Communication is very easy amongst all parties involved at Level 5. The environment is “communication rich” with face-to-face interactions and visual information readily available in the form of prototypes and models. Retrieval of information is also easy to reference knowledge, information or data that is either historical or current.

4. Ability to work iteratively and deliver incrementally
LEVEL 5: It is very easy to deliver benefit to customers by regular partial deliveries of the final product. It is also very easy to work iteratively in the sense that products and understanding can be refined interactively by the frequent delivery of formal and informal deliverables. There is a desire to learn, experiment and explore (and fail) as well as an overarching feeling of “Think big and start small”.

5. Advantageous environmental conditions
The overall working environment is very skilled at Level 5; it is a very efficient platform to work from (e.g. tooling, support of working in an Agile way and personnel are assigned full-time to their work; there are appropriate communications). Contractual frameworks and compliance considerations are not seen as restrictive.

6. Acceptance of Agile
Level 5: all stakeholders that are closely involved are fully aware of the behaviours, concepts and techniques of working in an Agile way. They have been trained and have experience. They are not only happy to work in this way, but they prefer it and understand the advantages that it brings. Peripheral stakeholders are also aware of the need to carry out their roles in an “Agile friendly way”.
Level 5 is considered here as the highest optimum level and levels 1 to 4 can be determined on a scale basis by the team. This approach is known as Agilometer and is pronounced as Agile-O-meter, used as a risk assessment tool specifically to address the risks of using Agile. It is not advisable to average the scales across the risk areas but to rather consider them in isolation.

The above six agile risk areas can be managed or mitigated by the agile team by practicing or using the following five behavioural areas:

1. Transparency: The more information that is in the open, the better this is for the Agile way of working. It enables speed, clarity and engagement, even if the news is not so good.
2. Collaboration: A motivated and respectful team is greater than the sum of its parts if people work together and provide cover for one another. More can be achieved in this way of working than in silos.
3. Rich communication: People should always use the most effective channel to communicate. Using face-to-face and/or visualization are faster and more effective than words on their own.
4. Self-organization: People closest to the work will usually know how best to get the job done.
5. Exploration: Projects are difficult and in order to create the right thing, you need to first work out what the right thing is. Frequent iteration and rapid feedback provide an opportunity to learn.

It is also important for the team, as well as the Project Manager, to monitor that these behaviours are happening in the team and update respective risk dashboards for enhanced visual reporting. The format of the reporting dashboard can take the traffic light format to highlight any behavioural area that needs attention, as shown below:

In conclusion

Analogously, just like when we embark on a long journey by car, we normally check and assess the car and road detours, terrain and weather and mitigate by having mist lights, spare wheels or winter tyres. We also need to take the same precaution with projects, as the project is considered a journey from start to finish, especially when determining the project approach during project chartering or assembling the project brief. The project approach on methodology could be Waterfall, Agile or a hybrid, depending on whether the project is simple or complicated, or whether there is an enormous amount of sub-contracted work or inter-connected components, or where output is evolving and difficult to predict with certainty. Agile would be recommended in both complicated and complex project environments. Nevertheless, it is also a good idea to assess the use of Agile at critical points during the life of the project in order to provide assurance that the project is on course to deliver the right product, right.

Author

Dr Laban Mwansa

---

This article was written by Dr Laban Mwansa, PMP®, PRINCE2® Practitioner, P2Agile®, COBIT®, and ITIL®. Laban is trainer/coach in Agile, PMP®, PRINCE2® Practitioner, P2Agile® in South Africa, Zambia and Europe for many years. Laban is a part-time facilitator for Faculty Training Institute in their Project Management portfolio.

Take a look at our Project Management on our website to find out more about the courses that we offer.