Agile : Case Study in Implementing Agile
Read, analyse, understand and summarise the following Agile case study
The summary must be authentic, your own original work, technically correct, without spelling and grammar mistakes and presented in word file format. and do not copy content from the internet.
Use Calibri font with font size 11
Plagiarised content will not be considered.
About Us Contact Advertise With Us Terms of Use Privacy Policy RSS Contribute Site Feedback Sitemap ©2011-2022 TechWell Corp.
Q&A Topics Resources Events
Tags:
A Case Study in Implementing Agile [article] By Taylor Putnam – August 6, 2014
Summary:
This case study serves as an example of how adopting agile can be extremely beneficial to an organization, as long as situational factors are considered. Adopting a new development method is a strategic, long-term investment rather than a quick fix. As this article shows, making deliberate, fully formed decisions will ultimately lead to better outcomes.
Everyone is looking for a competitive edge. It’s not surprising, then, that solutions promoting decreased time to market and increased productivity would be appealing. As more organizations begin to implement agile into their software development practices, it is logical to wonder whether agile development methodologies truly differ from traditional waterfall methods and what quantifiable advantages may be realized by adopting agile.
To tackle these questions with some objective numbers and data, software estimation company Quantitative Software Management Inc. conducted a case study for a large technical business organization (that wishes to remain anonymous). Initially a waterfall shop, this company attempted to adopt agile on a small scale in 2010. The results were less than optimal, primarily because the company lacked the necessary infrastructure and organizational mind shift necessary to truly embrace the principles of agile in its environment.
In 2011 it made a second attempt, this time using a more integrated approach. To start, it had organizational support and buy-in from senior management and key stakeholders. The process consisted of conducting an initial baseline assessment of development systems using an integrated set of tools and methods that would support agile and help manage the backlog, as well as a training component.
What QSM found from this instance (and others) was that successfully adopting agile may take upfront investment of both time and resources in order to realize optimal results.
Figure 1 shows a comparison over time between the average productivity of agile and waterfall projects. Productivity was measured in index points, a calculated proprietary QSM unit that ranges from 0.1 to 40. They allow for meaningful comparisons to be made between projects and account for variable software development factors such as management influence, development methods, tools, experience levels, and application type complexity. The projects developed using waterfall methods increased their average productivity ratings between 1.5 and 2 index points per year, which is fairly typical of this organization’s industry. As organizations improve their software development techniques and become more efficient, they also tend to improve their productivity over time.
You can see that the projects developed using agile methods did not have the highest productivity ratings when first adopted in 2010. However, by 2011, productivity not only increased dramatically—by 7.5 index points—but also surpassed the average productivity of the projects using waterfall methods.
To put some additional numbers around that finding, we modeled the software development lifecycles of typical agile and waterfall projects of the same functional size and staffing to better understand the differences between the two methodologies over time. One of the first, glaring observations was that agile methods utilize a much higher degree of overlap between high-level design and construction phases than waterfall methods: 97 percent versus 30 percent, respectively, as shown in figure 2. This makes sense, as agile methods leverage an iterative approach to release planning and delivery.
The second observation was the slope of the learning curve. When adopting agile, development teams often have to learn a whole new methodology of defining requirements, writing code, and concurrent testing. The effects of this can be seen in the schedule duration and effort expended.
In 2010, when agile methods were initially adopted, the projects using waterfall methods delivered 58 percent faster and used 74 percent less effort. This equates to about $550,000 in upfront costs for adopting agile when using a normalized labor rate of one hundred dollars per person hour.
However, 2011 saw a shift after the integrated agile adoption. This time, agile methods achieved 34 percent faster deliveries and utilized 27 percent less effort than waterfall methods, resulting in a cost savings of $160,000 per project.
From this we can see that using an integrated management approach to adopting agile yielded far more beneficial results than simply changing the technical development process by itself. However, realization of these benefits required an initial time investment in order to obtain organizational buy-in and allow adequate time for the necessary learning curve.
Knowing that adopting agile can be a lengthy process, it may be valuable to examine whether it is a worthwhile endeavor for an organization. Agile methods thrive when developing smaller, less complex systems, but now it seems that people want to push the limits of what agile can do. Can agile scale to larger organizations and more complex systems? Is there a “sweet spot” in which agile can realize the greatest benefits?
To answer these questions empirically, we compared the average trendlines of the agile and waterfall projects in a variety of areas, including duration, effort expended, staffing, and productivity. Because the projects used different sizing methods, we normalized the project sizes into a common standard called implementation units (IU) to allow us to make an apples-to-apples comparison. What we found was that there was a scaling “sweet spot” for this organization, whereby projects larger than 12,000 IU realized greater benefits from using agile methods in terms of time to market, cost, and productivity. Projects that were smaller than 12,000 IU achieved better results using waterfall.
This finding, though entirely based on one organization’s environment, demonstrates that agile has the potential to scale to larger project sizes and enterprises. While this may be counter to commonly held beliefs that agile methods should only be used for developing small software systems, we’ve seen similar findings with other large enterprise organizations as well, suggesting that this case study is not merely an outlier. That said, this finding is not generalizable to the software industry at large. We have seen other organizations achieve greater benefits from using agile methods for smaller sized projects, indicating that the “sweet spot” varies by organization.
Agile is not a silver bullet, and the decision to use agile methods should be entirely situational. Within this organization there were situations in which using agile resulted in the greatest benefits and others in which using waterfall was still the best option, as shown in figure 3, suggesting that waterfall is still a relevant development method and should not be abandoned. When deciding between adopting agile or sticking with more traditional methods, my suggestion would be to use the development method best suited for the project’s intended environment.
This case study serves as an example of how adopting agile can be extremely beneficial to an organization, as long as situational factors are considered. If adopted impulsively without the appropriate cultural modifications and organizational support, agile—or any new development methodology, for that matter—has the potential to negatively impact organizational productivity.
Adopting a new development method is a strategic, long-term investment rather than a quick fix. Before making drastic changes such as those needed to properly implement a similar change in development practices, invest time at all levels of the organization to fully understand the task at hand and assess how long it will take to reap the benefits and achieve the expected return on investment. As in this case study, making deliberate, fully formed decisions will ultimately lead to better outcomes.
agile, agile transition, analysis, business analysis, measurement, methods, process improvement, process metrics, scalability
Login or Join to add your comment
About the author
Taylor Putnam
C. Taylor Putnam is a Consulting Analyst at Quantitative Software Management Inc. (QSM) and has over 7 years of specialized data analysis, testing, and research experience. In addition to providing consulting support in software estimation and benchmarking engagements to clients from both the commercial and government
sectors, Taylor has authored numerous publications about Agile development, software estimation, and process improvement, and is a regular blog contributor for QSM. Most recently, Taylor has presented research titled Does Agile Scale? A Quantitative Look at Agile Projects at the Agile in Government conference in Washington, DC. Taylor holds a Bachelor’s degree from Dickinson College.
AgileConnection is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.
Most Popular » 7 Keys to Building Great Work Teams [article] » Using Agile Pods to Realize the Potential of Your Team [article] » What Does It Mean To Be An Agile Organization [article] » How to Implement an Agile Methodology into Tech Support [article] » 7 Qualities of High-Performing Agile Teams [article]
Follow Us
Embed View on Twitter
Tweets by @agileconn
13h
See how the new switch statement in Java 14 is simplified well.tc/5nci
An Agile approach to software development looks good on paper. However, author Rajashekar Reddy Ramasahayam argues that it may not be a fit for all projects. well.tc/5h6x
Agile Connection @agileconn
Switch Expressions in … The article discusses ho… agileconnection.com
Agile Connection @agileconn
Tweet to @agileconn
Upcoming Events
Apr 24 STAREAST Software Testing Conference in Orlando & Online
Jun 12 Agile + DevOps West The Latest in Agile and DevOps
Oct 02 STARWEST Software Testing Conference in Anaheim & Online
Nov 06 Agile + DevOps East The Conference for Agile and DevOps Professionals
Recommended Web Seminars
Jan 13 Consistently Build Quality Software with Speed, Better ROI, and Effectively Managed Codeless Test Automation
Jan 27 Beyond K8s: Introduction to Ephemeral Environments
On Demand Building Confidence in Your Automation
On Demand Leveraging Open Source Tools for DevSecOps
On Demand Five Reasons Why Agile Isn’t Working
See All
Featured Resources
» Continuous Security: Why DevSecOps is Dead | Wabbi
» Test Automation eGuide | TechWell
» ROI of Quality: Making a Business Case for Modern Testing | Perfecto
» Internet of Things eGuide | TechWell
» Five Steps to Building Strategic, Scalable Testing Teams | Tricentis
LOGIN JOIN
Member Benefits
We Use Cookies To Ensure You Get The Best Experience On Our Website. Read More Accept
https://publish.twitter.com/?url=https%3A%2F%2Ftwitter.com%2Fagileconn
http://www.addthis.com/bookmark.php?v=250
http://www.addthis.com/bookmark.php?v=250
http://www.addthis.com/bookmark.php?v=250
http://www.addthis.com/bookmark.php?v=250
http://www.addthis.com/bookmark.php?v=250
http://www.addthis.com/bookmark.php?v=250
