The various agile Scrum methodologies share much of the same philosophy, as well as many of the same characteristics and practices. But from an implementation standpoint, each has its own recipe of practices, terminology, and tactics. Here we have summarized a few of the main agile software development methodology contenders:
Scrum is a lightweight agile project management framework with broad applicability for
managing and controlling iterative and incremental projects of all types. Ken Schwaber,
Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade.
Scrum has garnered increasing popularity in the agile software development community due to its simplicity, proven productivity,
and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.
With Scrum methodology, the “Product Owner” works closely with the team to identify and prioritize system functionality in form of a “Product Backlog”. The Product Backlog consists of features, bug fixes, non-functional requirements, etc. – whatever needs to be done in order to successfully deliver a working software system. With priorities driven by the Product Owner, cross-functional teams estimate and sign-up to deliver “potentially shippable increments” of software during successive Sprints, typically lasting 30 days. Once a Sprint’s Product Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of functionality is selected for the next Sprint. Scrum methodology has been proven to scale to multiple teams across very large organizations with 800+ people.
Lean Software Development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement, and the practices of companies like Toyota. Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” the mechanisms that deliver that Value. The main principles of Lean methodology include:
Seeing the Whole Lean methodology eliminates waste through such practices as selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers. Lean uses the idea of work product being “pulled” via customer request. It focuses decision-making authority and ability on individuals and small teams, since research shows this to be faster and more efficient than hierarchical flow of control. Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.
The Kanban Method is used by organizations to manage the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.
Kanban promotes continuous collaboration and encourages active, ongoing learning and improving by defining the best possible team workflow.
XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks. The original XP recipe is based on four simple values simplicity, communication, feedback, and courage and twelve supporting practices:
Don Wells has depicted the XP process in a popular diagram
In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as “User Stories”. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration-by-iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.
The Crystal methodology is one of the most lightweight, adaptable approaches to software development.
Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow,
Crystal Orange and others, whose unique characteristics are driven by several factors such as team size,
system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices,
and processes in order to meet the project ‘s unique characteristics.
Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile process methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.Alistair Cockburn , the originator of Crystal, has released a book, Crystal Clear: A Human-Powered Methodology for Small Teams.
DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time.
While RAD was extremely popular in the early 1990 ‘s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result,
the DSDM Consortium was created and convened in 1994 with the goal of devising and promoting a common industry framework for rapid software delivery.
Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing,
executing, and scaling agile process and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing,
and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system,
focusing on the useful 80% of the system that can be deployed in 20% of the time.
Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:
M – Must have requirements
S – Should have if at all possible
C – Could have but not critical
W – Won ‘t have this time, but potentially later
All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical.
Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.
The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.
The FDD variant of agile methodology was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. The features are small, “useful in the eyes of the client” results. FDD designs the rest of the development process around feature delivery using the following eight practices:
FDD recommends specific programmer practices such as “Regular Builds” and “Component/Class Ownership”. FDD’s proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other agile methods, FDD describes specific, very short phases of work, which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.
Agile methods grew out of the real-life project experiences of leading software professionals who had experienced the challenges and limitations of traditional waterfall development on project after project.
The approach promoted by agile development is in direct response to the issue associated with traditional software development both in terms of overall philosophy as well as specific processes.
Agile development, in its simplest form, offers a lightweight framework for helping teams, given a constantly evolving functional and technical landscape, maintain a focus on the rapid delivery of business value (i.e., bang for the buck). As a result of this focus, the benefits of agile software development are that organizations are capable of significantly reducing the overall risk associated with software development.
In particular, agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process. As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process. By measuring and evaluating status based on the undeniable truth of working, testing software, much more accurate visibility into the actual progress of projects is available. Finally, as a result of following an agile process, at the conclusion of a project is a software system that much better addresses the business and customer needs.
The diagram below displays the differences between agile and waterfall development processes. By delivering working, tested, deployable software on an incremental basis, agile development delivers increased value, visibility, and adaptability much earlier in the life cycle, significantly reducing project risk.
According to theStandish Group’s famous CHAOS Report of 2000, 25% of all projects still fail outright through eventual cancellation, with no useful software deployed.
Sadly, this represents a big improvement over CHAOS reports from past years. And now there is more evidence of the same kind.
In Agile and Iterative Development: a Managers Guide,
renowned consultant and author Craig Larman does a thorough job of debunking the traditional waterfall model once and for all.
The numbers are overwhelming. A study in the United Kingdom shows that of 1,027 projects, only 13% did not fail, and waterfall-style scope management was the “single largest contributing factor for failure, being cited in 82% of the projects as the number one problem.” A 1995 study of over $37 billion USD worth of US Defense Department projects concluded that “46% of the systems so egregiously did not meet the real needs (although they met the specifications) that they were never successfully used, and another 20% required extensive rework” to be usable.
Larman also points that in “another study of 6,700 projects, it was found that four out of the five key factors contributing to project failure were associated with and aggravated by the waterfall model, including inability to deal with changing requirements, and problems with late integration.” Another study of over 400 waterfall projects reported that only 10% of the developed code was actually deployed, and of that, only 20% was actually used.
These numbers reinforce what many of us have experienced personally: the waterfall approach is a risky and expensive way to build software systems. This is the real reason why the much of industry is investigating and/or implementing agile alternatives.
Copyright © 2017 Pearlsoft Technology. All Rights Reserved.