Agile Adoption: A Case Study

Case Studies | By Adam Alami | Read time minutes

Time to market and remaining competitive are amongst the drivers of Agile adoption. New breeds of project execution processes have been proposed recently as lightweight alternatives to the traditional phased approach. These so-called lightweight processes fall under the umbrella of Agile methodology. Agile advocates recommend executing projects based on the philosophy of iterations, incremental development, collaboration and adaptation.

1. Case Study

As one of my assignments, I was asked by a client to evaluate a project adoption of Agile. I'm sharing this experience with the project management community. Note that permissions to use all data anonymously were granted by the company and all individuals who were subjects of this study.

This case study was conducted to evaluate Agile adoption on a project that has to update an obsolete enterprise data warehouse. The team members have never collaborated with each other, and the project was their first Agile experience.

The project used the Scrum process to implement Agile. The data gathered on this case study originates from three focus groups, each of whose conversations were recorded, scribed and analysed. Though there were various conclusions, the main findings indicate that the Agile method requires meticulous and thorough planning prior to the transition.

2. Findings

There was a mixed evaluation of the experience. Participants mainly raised issues regarding the lack of planning in the implementation of the Scrum process. They praised the collaborative and dynamic aspects of the process.

2.1 Negative Feedback

1. The big picture: The majority of participants felt that the big picture was missing. Even though the project had a business case, project scope document and a project plan, the project team seemingly couldn't visualise the final destination and the final product. The Scrum process didn't advocate the business vision behind the project and how the project fit within the enterprise strategy. The big picture was not defined upfront. It was assumed that it was known, and it would be constructed and polished as the process progressed.
2. Even though the product backlog was built, socialised with the team and stakeholders, and approved, the team claimed that the itemised nature of the deliverable was too detailed and too soon in the process. Participants preferred to invest time in defining goals and requirements before diving into an itemised level of deliverables. One participant stated, You can easily get caught up in the details and miss the big picture.
2. Lack of documentation: Participants stated the issue of insufficient documentation as they felt they were missing crucial knowledge. In an Agile process, due to continuous collaboration between team members, requirements can crop up at any time during the process. Examining samples of the project's user story shows that the style of the user story was not adaptable to business intelligence requirements. To overcome that limitation, team members exchanged information verbally and via email.
3. Lack of planning: Not enough planning was a consensus amongst the project team. The team referred to the adoption of Agile as not planned and not thoroughly thought out. The team felt they were not prepared for Agile. During the focus group, participants occasionally referred to their previous phased approach as a reference point.

2.2 Positive Feedback

Some aspects of the experience were praised and appreciated by the team.

1. Team spirit: Participants found that using the Scrum process brought them closer, made them aware of each other's thinking processes and helped build team spirit. They felt the method facilitated knowledge sharing.
2. Dynamic: Most of the participants also found the process to be very vibrant and dynamic. The process energised the team, and all team members felt they had a voice.

2.3 Lessons Learned

What can be gauged from this case study is that in order for the Agile process to be effective, the following is required:

1. The transition to Agile must be planned thoroughly
2. Agility must be introduced iteratively - a single-jump transition to Agile is a recipe for failure
3. A plan for change and education must be put in place to prepare the team for Agile
4. A warm introduction of Agile through a change management plan is necessary
5. Continuous feedback and improvement of the Agile implementation are needed

Agile Adoption

Engagement and collaboration are the foundation of the Agile platform. However, Agile is a generic framework. Its adaptation is not an easy process. Additionally, projects and organisations frequently fail to define Agile adoption benefits prior to the transition.

In contrast to the simplistic and partial views undertaken by organisations, Agile adoption is influenced by a number of factors. Most of these factors arise as a direct result of the nature of the organisation. Thus, self-knowledge is critical when making an organisational process change.

A pre-evaluation of Agile suitability must be conducted to ensure it is a right choice prior to implementation. In such an evaluation, various parameters must also be considered and acknowledged prior to the transition to Agile:

1. Cultural fit: Much depends upon whether Agile can be implemented successfully in a given organisational culture. Agile is certainly not a cure-all remedy, and organisations with compatible cultures can achieve benefits to a sizeable degree. However, when Agile is a miss-match, it becomes a cultural shift rather than a simple process adoption.
2. Project execution maturity: How good are your team at delivering? Delivery is a culture and a process. Changing the process won't necessarily make you good at delivering. Process maturity is a state of robustly defined, inter-related processes that lead to consistent results and output with the least deviation. Understanding the maturity level facilitates project execution as the project implementation strategy can then be adapted to a particular level of maturity.
3. Expectations: The framework lays out a set of principals but does not define benefits. It's an organisation's responsibility to define what it is expecting from Agile.
4. People: Stakeholders across all concerned divisions need to participate in the decision to adopt Agile. Educational enhancement activities can allow for better organisation-wide comprehension of this process.
5. Distributed environment: If the team is geographically distributed, Agile could be a challenge since the Agile concept is built around a team being co-located. Thus, distributed Agile implementation is challenging, and the constraint of being distributed may impact the process.

Agility is not a one-dimensional concept. Organisations tend to have deep-rooted methods of project execution, and the present degree of agility needs to be accounted for before switching to Agile.

The management of the transition from the current style of project execution to Agile affects the large-scale realisation of Agile benefits. This transition needs to be gradual and well-managed rather than abrupt and sudden. A warm introduction to Agile through a change of management plan can facilitate the overall transition.

Ultimately, Agile is a difficult-to-master concept. Rolling out a process does not necessarily mean the end of the journey. The process maturity level is enhanced by the implementation of a process improvement capability that supports projects and promotes the key concepts and practices of the methodology - helping to ensure Agile adoption is a success.

About the Author

Adam Alami is a seasoned, versatile IT consultant with over 18 years of experience revolving around major business transformation projects. Business analysis and project management are his passion. He has a wealth of cross-industry experience with tier 1 businesses in major projects in the areas of enterprise transformation, integration, migration and systems modernisation.

He has a track record of academic achievement. He holds a Bachelors degree in Software Engineering from the Université du Québec à Montréal (UQÀM) and a Master degree in Computing from the University of Technology, Sydney (UTS).

Adam is passionate about research. His research interests are IT offshoring, banking technology, business analysis, global project management, information technology and culture, enterprise innovation, and business solutions. To find out more, contact Adam by email.