Skip to content

Agile Methodology Case Study

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,
  3. 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.
  4. 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 or visit his website Adam Alami


If you could do the same project with the same group of people, first using a waterfall methodology and next using...

an Agile methodology, what do you think the results would be? Well, though not the exact same project, two very similar projects were done with the same development teams, one using waterfall, and the other using Agile, which yielded some interesting findings.

The situation

Bill Holst, president and principal consulting software engineer for Prescient Software Engineering, managed two projects for Colorado Springs Utilities -- an electric project and a gas project. Both projects were distribution design systems very similar in scope. Holst contracted out the development work and used the same team for both projects. The electric project was a fixed price bid and was done using a traditional waterfall approach. The gas project was done next with the same development team -- a team that was new to Agile -- with T&M (Times and Materials) pricing. In both cases the customers of the project were field engineers.

The waterfall approach dictates that requirements are complete before coding begins. Typically, once the requirements phase has completed, the users don’t get involved again until the user acceptance test (UAT) phase nears the end of the project. With an Agile approach, the users remain involved throughout the lifecycle, with regular reviews and updates to the requirements.

Using waterfall yields unsatisfactory results

Holst felt that the electric project, which was done first, had many deficiencies. There was a long lag time between expected delivery and actual delivery. The software didn’t match what the customers felt they had asked for. There was a lot of churn throughout the project with disappointing results. Frustration was felt all around.

Initial transition: “We suck at Agile”

The team knew they needed to do something differently, so they decided to try an Agile approach for the gas project. They hired some Agile trainers to coach them through the transition, but there was a lot of initial team resistance. The field engineers didn’t like it, thinking the methodology was too touchy-feely. “We want to build a system and these guys are talking about commitment,” was the general sentiment. Holst joked that they team suggested getting coffee mugs that said, “We suck at Agile.”

The project suffered through many problems. The test cases didn’t match the logic, which was convoluted and confusing. Six iterations went forward, but a look at velocity and burn-down charts showed that progress was getting worse rather than better. The team made a tough decision: Stop and regroup.

The turnaround

The team decided to use the 7th iteration to re-examine the requirements. The developers took two weeks off and the field engineers who had defined the requirements using pseudo-code, recognized that their original requirements needed to be redone. They took the original 800 lines of pseudo-code and, now, with a better understanding of the system, what was working and what wasn’t, were able to rework it down to around 200 lines of pseudo-code in much more logical way. This redesign of the requirements was the turning point of the project.

This change in direction was only possible because of the Agile nature of the project. “The cost to change the system this far downstream would have been too high [using the traditional model],” says Holst. Having the more flexible pricing model, along with the ability to change requirements midstream was a major key to success.

The results

With the reworked requirements, the team was set to start practicing Agile in the manner it was meant to be practiced. Velocity increased as the backlog decreased and, even with the two-week delay to regroup, the project ended up being finished early and under budget.

In all respects, the project was a success. In comparing it to the first project, if this were a competition, the Agile project would have scored higher in every category. The quality was better, and the test cases were cleaner. “There were fewer test cases, but more coverage,” said Holst. Usability was much better, too. “Usability is a key ‘ility’ that’s hard to define in requirements,” said Holst, but joked that “like pornography, you know it when you see it.”

The bottom line was that the Agile project came in early, under budget, and the users loved it.

Keys to success

Holst attributes success to two important factors: Agile training and the regroup effort.

“We hired some consulting training to come in and ground the team in Agile methodology.” This was important because none of the project team had worked with Agile before, so getting the training and having the necessary support was key.

Regarding the regroup effort, Holst says, “We had a major shift in what the product team wanted about halfway through the project and we were able to reform the project and redo logically what we wanted the software to do mid-stream.” Holst believes that the flexibility provided with an Agile methodology that allowed for this regroup was one of the primary keys to success.

Will Agile always prevail?

Even though in this case Agile was the clear winner if this had been a competition between the Agile and Waterfall methodologies, it does not mean that every Agile project will succeed or that Agile is clearly the better methodology. Even the Agile project started out very poorly and had the team continued down that path, that project most likely would have had results just as poor as the waterfall project. However, the ability to inspect and adapt, taking time to regroup and rework requirements, allowed this team to get back on track.

How does the team feel? Let’s just say they want a new coffee mug slogan. They’re no longer saying, “We suck at Agile,” but instead, “Let’s do it again.”