7/23/2019 Evaluating Agile and Scrum With Other Software Methodologies http://slidepdf.com/reader/full/evaluating-agile-and-scrum-with-other-software-methodologies 1/41 11/5/2015 Evaluating Agile and Scrum with Other Software Methodologies http://www.infoq.com/articles/evaluating-agile-software-methodologies BT Contribute About Us About You Purpose Index Exclusive updates on: Facilitating the spread of knowledge and innovation in professional software development Search Danny Welcome, Danny ! My Reading List Preferences Personalize Your Main Interests Development Architecture & Design Process & Practices Operations & Infrastructure Enterprise Architecture This affects what content you see on the homepage & your RSS feed. Click preferences to access more fine- grained personalization. Sign out En | 中文 | 日本 | Fr | Br
Transcript
7/23/2019 Evaluating Agile and Scrum With Other Software Methodologies
Posted by Capers Jones on Mar 20, 2013 | Lire ce contenu en français | 19 Discuss
Share
|
"Read later"
"My Reading List"
In general selecting a software development methodology has more in common with joining a cult than it does
with making a technical decision. Many companies do not even attempt to evaluate methods, but merely adopt
the most popular, which today constitute the many faces of agile. This article uses several standard metricsincluding function points, defect removal efficiency (DRE), Cost of Quality (COQ), and Total Cost of Ownership
(TCO) to compare a sample of contemporary software development methods.
There are about 55 named software development methods in use, and an even larger number of hybrids. Some
of the development methods include the traditional waterfall approach, various flavors of agile, the Rational
Unified Process (RUP), the Team Software Process (TSP), V-Model development, Microsoft Solutions
Framework, the Structured Analysis and Design Technique (SADT), Evolutionary Development (EVO),
Extreme Programming (XP), PRINCE2, Merise, model-based development, and many more.
The data itself comes from studies with a number of clients who collectively use a wide variety of softwaremethods. The predictions use the author’s proprietary Software Risk Master™ tool which can model all 55
software development methodologies.
Related Vendor Content
The Role of the Test Professional in Today’s DevOps World
Size plateau of application (small, medium, large) 3
Application complexity (low, average, high) 3
Combinations of factors 5,568,750
Since the number of combinations is far too large to consider every one, this article will make simplifyingassumptions in order to focus primarily on the methodologies, and not on all of the other factors.
In this article the basic assumptions will be these:
Application size 1000 function points
Programming languages C and C++
Logical code statements 75,000
Requirements creep Omitted
Deferred features Omitted
Reusable features Omitted
Team experience Average
Complexity Average
Cost per staff month $7,500
7/23/2019 Evaluating Agile and Scrum With Other Software Methodologies
a special case. Quality of the final software is a major goal of the XP method.
Object-oriented development (OO): The OO method is one of the oldest in this article and has had many
successes. It has also led to the creation of special languages such as Objective C. In this article OO analysis and
design with use cases are used. The C++ language is also an OO language. OO analysis and design are
somewhat different from conventional methods so a learning curve is needed.
Pair programming: The concept of pair programming is often part of the agile approach, but is not limited to it.
In this paper pair programming is used with iterative development. The basic idea of pair programming is that
two people take turns coding. While one is coding the other is watching and making suggestions. Sometimes the
pair use only one computer or work station between them.
Proofs of correctness: The concept behind proofs of correctness is that of applying formal mathematical proofs
to the algorithms that will be included in a software application. It is obvious that the algorithms need to be
expressed in a formal manner so that they can be proved. It is also obvious that the person who performs the
proof has enough mathematical skills to handle rather complex equations and algorithms.
Rational Unified Process (RUP): The RUP methodology was originated by the Rational Corporation which
was acquired by IBM in 2003 so it is now an IBM methodology. The RUP method includes aspects of both
iterative and object-oriented development. Since RUP is now owned by IBM there are numerous tools that
support the method. Use Cases and visual representations are standard for RUP applications, but the author’s
clients usually include other methods as well such as decision tables.
Team Software Process (TSP): The TSP method was developed by the late Watts Humphrey, who was
IBM’s director of programming and later created the assessment method used by the Software Engineering
Institute (SEI) capability maturity model. TSP is very focused on software quality. All bugs are recorded;
inspections are used, and high quality is the main goal on the grounds that bugs slow down development. The
TSP method has some unusual aspects such as self-governing tools and a coach that serves the role of manager.TSP is now endorsed and supported by the SEI.
Three Kinds of Methodology Evaluation and 10 Metrics
Even with the number of methods limited to 10 there are still a great many results that need to be evaluated.
However from working with hundreds of clients, the topics that have the greatest importance to development
managers and higher executives are these:
Speed-related metrics
1. Development schedules
2. Development staffing
3. Development effort
4. Development costs
Quality-related metrics
1. Defect potentials
2. Defect removal efficiency (DRE)
7/23/2019 Evaluating Agile and Scrum With Other Software Methodologies
Even with only 10 methodologies and 10 topics to display, that is still quite a significant amount of information.
This article will attempt to compare methodologies in three major categories:
1. Speed: Development schedules, effort, and costs
1. Quality: Software quality in terms of delivered defects
1. Economics: Total Cost of Ownership (TCO) and Cost of Quality (COQ)
Note that the technique used in this article of holding application size constant at 1000 function points means thatthe data cannot be safely used to determine the best methods for large systems of 10,000 function points or
massive systems of 100,000 function points. However applications in the 1000 function point size range are very
common, and are large enough to show comparative results in a fairly useful way.
Some of the data in this article was prepared using the author’s Software Risk Master ™ (SRM) tool, which is
designed to perform side-by-side comparisons of any development methodology, any CMMI level, any
complexity level, and any level of team experience. Some of the tables are based on SRM outputs, although
derived from earlier measured applications.
Speed: Comparing Methodologies for Development Schedules and Costs
The first comparison of methodologies concerns initial development speeds, costs, and short-term issues. Among
the author’s clients the most frequent request when estimating software projects is to predict the development
schedule. Because schedules are viewed as critical to a majority of software managers and executives, table 1 is
In the sample used in this article for 1000 function points there were about 690 specific requirements that need to
be proved. This is why even small applications that use proofs take a long time, because proofs are time
consuming.
It would be essentially impossible to use proofs of correctness on an application of 10,000 function points
because there would be 7,407 specific algorithms to be proved and that might take several years, during which
the requirements would have changed so many that the earlier proofs might no longer apply.
Matching Software Methodologies with Projects
Since no method is top-ranked in every category, readers may well ask how to select methods that match the
needs of their projects.
For smaller applications of 1000 function points or less where speed of delivery is the most critical parameter,
then XP, Agile, and TSP are all very good choices.
For complex applications that might need FDA approval, operate weapons systems, or control sensitive financia
data, high quality levels are mandatory. In this class TSP, CMMI 5, and RUP are the top choices, with XP asanother possible method. Agile has been used for such applications but needs to be bent and twisted so much
that it no longer is very agile. Agile is not strong on quality.
For applications that might last for more than 10 years or which require very frequent enhancements and
therefore need well designed interior structures, TSP would be the top choice, with CMMI 5, RUP, and XP also
possibilities. Agile has not shown much success with long-term maintenance and enhancements.
Summary and Conclusions
As this article is written the software industry has about 55 different development methodologies. This is too
large a number to compare in a short article.
For the 10 methods compared here, most have had some successes and most have had a few failures too.
Overall the Agile family and the methods that emphasize speed have achieved their goal, and they are fairly
quick.
The methods that emphasize quality such as TSP, RUP, and CMMI 5 have also achieved their goals, and deliver
very few defects.
No single method appears to be a universal panacea that can be successful on every size and kind of software
application.
This article attempts to show the methods that give the best fit to three important factors:
1. speed;
2. quality;
3. long-rang economic value.
7/23/2019 Evaluating Agile and Scrum With Other Software Methodologies
Capers Jones is currently vice president and chief technology officer of Namcook Analytics
LLC. This company designs leading-edge risk, cost, and quality estimation and measurement
tools. He was the president of Capers Jones & Associates LLC until 2012, a software
researcher and manager at IBM for 12 years and Assistant Director of Programming at the ITT
Corporation where he started their software measurement program. Capers is a well-known
author and international public speaker. Some of his books are The Economics of SoftwareQuality (with Olivier Bonsignour), Software Engineering Best Practices, Applied Software Measurement and
Estimating Software Costs. He is currently working on his 15th book entitled The Technical and Social History
of Software Engineering, to be published in the autumn of 2013.
Capers and his colleagues have collected historical data that is used for judging the effectiveness of software
process improvement methods and also for calibrating software estimation accuracy, in cited in software litigation
in cases where quality, productivity, and schedules are part of the proceedings. He has also worked as an expert
witness in 15 lawsuits involving breach of contract and software taxation issues.
Sections
Enterprise Architecture
Process & Practices
Topics
Agile in the Enterprise
Waterfall
Scrum
Methodologies
Project Management
IBM RationalALM
Architecture
Scaling Agile
Agile Architecture
RUP
Value & Metrics
Agile
UP
IBM
Related Editorial
Supporting Practices Beyond Scrum to Become Agile at Organizational Level
Re: XP without pair programming is not XP. by James Michelsen Posted Mar 22, 2013 05:20
Unknown data fed through a proprietary tool... by David Allsopp Posted Mar 23, 2013 06:48
Beyond bizarre by Tim Ottinger Posted Mar 27, 2013 06:10
Re: Beyond bizarre by Capers Jones Posted Mar 28, 2013 11:35
Re: Beyond bizarre by Anthony DaSilva Jr Posted Mar 30, 2013 07:24
surprised to see such bad content at infoQ by Pedro Pimentel Posted Mar 27, 2013 10:28
Re: surprised to see such bad content at infoQ by Capers Jones Posted Mar 28, 2013 11:25
Lean-Agile misunderstood by Johnny FromCanada Posted Mar 31, 2013 05:35Seems to be biased... by Vinod Vijay Posted Apr 02, 2013 02:04
Nice work but flawed by Eric Weimer Posted Jan 09, 2014 11:30
TSP promo Mar 20, 2013 09:06 by "James Michelsen"
Have never heard about this methodology.
Sounds as promotion of TSP, doesn't it?
ReplyBack to top
Pair Programming . . . Mar 20, 2013 11:38 by "eswar vandanapu"
When reading about the pair programming topic in this article it gives me an impression that pair programming is
too bad. There are several reasons why pair programming in software development can't be combined with other
professions. For a difficult surgery there are often 2 doctors in the OR, and we don't see artists pairing up to
create an paired art.
Pair programming has some key ideas that are good in practice, even though pairing 100% of the time is for surewaste of time and money. While working and large projects with more than 300 people I have employed what I
call as selective pairing where you pair people for a purpose. Mostly I let engineers decide when they want to
pair up and it mostly worked out very well. And sometimes I pair up people to work together for a few hours on
building up systems, or when doing a critical piece of functionality and it indeed reduced the amount of possible
bugs in that area.
In short I believe selective pairing with a purpose is a very good practice.
Reply
Back to top
Agile misunderstanding Mar 20, 2013 01:27 by "Carlos Granitto"
"Minimizing paperwork and accelerating development speeds are top goals of agile."
This statement is completely inexact. A state of this kind shows lack of knowledge about this matter. If I were
new about Agile, I could believe this but, after a couple of months of working with agile would be enough to
P.S: Nowadays; we have companies with Co-CEO models.
Am not advocating that we need double the number of people; but we need to have leeway for experts to
interact for the project delivery on an adhoc basis.
3. In the book on TSP, Watts Humphrey talks about a confined set of priorities for each set of individuals
involved in software teams.
He has also later emerged with another strategy of PSP(People Software Process)In both of these; there are implicit interactions between team members and the project delviery is taken as a team
deliverable.
Am neither advocating Agile is the panacea for all issues in software development nor that all other methodolgies
are crap.
But the teams should be deligent enough to tailor the processes as per their requirements.
The article gives a strong feel that you have some real bad experiences with Agile or Non -TSP processes.
Reply
Back to top
Re: TSP promo Apr 08, 2013 10:23 by "Girish Seshagiri"
Here is a real TSP promo. My company is among the earliest adapters of the TSP. For the past 10 years, we
have been delivering substantially defect-free software within 10% of committed schedule, and 4% of committed
cost. We offer performance guarantees including the least time spent by customers in acceptance testing and
lifetime warranty against defects found in production use. We recently modernized one of the largest databases in
government. We delivered more than 600,000 line of code four weeks ahead of schedule. Customer found zerocybersecurity vulnerabilities in the code in two independent penetration tests. We had zero voluntary staff
turnover during the project that lasted more than two years.
Reply
Back to top
Nice work but flawed Jan 09, 2014 11:30 by "Eric Weimer"
For example, the sentence "The existence of more than 55 software development methods, each with loyal
adherents, is a strong message that none of the 55 is capable of handling all sizes and kinds of softwareapplications."
There are many reasons why 55 methods may have existed in your study. For example, every programmer has
preferences, and they often prefer what he/she last used.
And selection of a method is often the result of many factors. It is hard to see this conclusion.
Other issues:
7/23/2019 Evaluating Agile and Scrum With Other Software Methodologies
Learn how Apache Spark - an open source engine built specifically for data science - can help simplifyalgorithm development and accelerate analytics results.
![EXIN Agile Scrum Foundation - Scrum Training | Agile ... Agile Scrum Foundation Sample... · Sample Exam EXIN Agile Scrum Foundation [ASF.EN] 4 Introduction This set of sample questions](https://static.documents.pub/doc/80x56/5b0a48397f8b9adc138bd947/exin-agile-scrum-foundation-scrum-training-agile-agile-scrum-foundation.jpg)
