Agile Software Development

Dean Brown • October 2, 2021

In software development, agile (sometimes written Agile) is a set of practices intended to improve the effectiveness of software development professionals, teams, and organizations. It involves discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).


It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to changes in requirements, resource availability, and understanding of the problems to be solved.


It was popularized by the 2001 Manifesto for Agile Software Development. The values and principles exposed in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.


While there is much anecdotal evidence that adopting agile practices and values improves the effectiveness of software professionals, teams and organizations, the empirical evidence is mixed and hard to find.


History of Agile Software Development

Iterative and incremental software development methods can be traced back as early as 1957,[10] with evolutionary project management[11] and adaptive software development emerging in the early 1970s.


During the 1990s, a number of lightweight software development methods evolved in reaction to the prevailing heavyweight methods (often referred to collectively as waterfall) that critics described as overly regulated, planned, and micromanaged. These included: rapid application development (RAD), from 1991;[15][16] the unified process (UP) and dynamic systems development method (DSDM), both from 1994; Scrum, from 1995; Crystal Clear and extreme programming (XP), both from 1996; and feature-driven development, from 1997. Although these all originated before the publication of the Agile Manifesto, they are now collectively referred to as agile software development methods. At the same time, similar changes were underway in manufacturing and management thinking.


In 2001, these seventeen software developers met at a resort in Snowbird, Utah to discuss these lightweight development methods: Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, Robert C. Martin, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, and Steve Mellor. Together they published the Manifesto for Agile Software Development.


In 2005, a group headed by Cockburn and Highsmith wrote an addendum of project management principles, the PM Declaration of Interdependence,[19] to guide software project management according to agile software development methods.


In 2009, a group working with Martin wrote an extension of software development principles, the Software Craftsmanship Manifesto, to guide agile software development according to professional conduct and mastery.


In 2011, the Agile Alliance created the Guide to Agile Practices (renamed the Agile Glossary in 2016), an evolving open-source compendium of the working definitions of agile practices, terms, and elements, along with interpretations and experience guidelines from the worldwide community of agile practitioners.


Agile software development values

Based on their combined experience of developing software and helping others do that, the seventeen signatories to the manifesto proclaimed that they value:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation

Responding to change over following a plan
That is to say, the items on the left are valued more than the items on the right. It is not to say that the items on the right should be excluded in favor of the items on the left. Both sides have value, but from an Agile Development point of view the authors of the manifesto tip the balance in favor of the items on the left.

As Scott Ambler elucidated:

Tools and processes are important, but it is more important to have competent people working together effectively.

Good documentation is useful in helping people to understand how the software is built and how to use it, but the main point of development is to create software, not documentation.

A contract is important but is no substitute for working closely with customers to discover what they need.

A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholders' priorities, and people's understanding of the problem and its solution.

Some of the authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto's values and principles. Introducing the manifesto on behalf of the Agile Alliance, Jim Highsmith said,

The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.

— Jim Highsmith, History: The Agile Manifesto

Agile software development principles

The Manifesto for Agile Software Development is based on twelve principles:

1. Customer satisfaction by early and continuous delivery of valuable software.

2. Welcome changing requirements, even in late development.

3. Deliver working software frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

7. Working software is the primary measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

10. Simplicity—the art of maximizing the amount of work not done—is essential

11. Best architectures, requirements, and designs emerge from self-organizing teams

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Overview

Iterative, incremental, and evolutionary

Most agile development methods break product development work into small increments that minimize the amount of up-front planning and design. Iterations, or sprints, are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration a working product is demonstrated to stakeholders. This minimizes overall risk and allows the product to adapt to changes quickly.[24] An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Through incremental development products have room to "fail often and early" throughout each iterative phase instead of drastically on a final release date. Multiple iterations might be required to release a product or new features. Working software is the primary measure of progress.


A key advantage of Agile methodology is speed to market and risk mitigation. Smaller increments are typically released to market reducing the time and cost risks of engineering a product that doesn't meet user requirements.


Efficient and face-to-face communication

The principle of co-location is that co-workers on the same team should be situated together to better establish the identity as a team and to improve communication.[27] This enables face-to-face interaction, ideally in front of a whiteboard, that reduces the cycle time typically taken when questions and answers are mediated through phone, persistent chat, wiki, or email.


No matter which development method is followed, every team should include a customer representative ("Product Owner" in Scrum). This person is agreed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer questions throughout the iteration. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment (ROI) and ensuring alignment with customer needs and company goals. The importance of stakeholder satisfaction, detailed by frequent interaction and review at the end of each phase, is why the methodology is often denoted as a "Customer Centered Methodology".


In agile software development, an information radiator is a (normally large) physical display located prominently near the development team, where passers-by can see it. It presents an up-to-date summary of the product development status. A build light indicator may also be used to inform a team about the current status of their product development.


Very short feedback loop and adaptation cycle

A common characteristic in agile software development is the daily stand-up (a daily scrum in Scrum framework). In a brief session, team members report to each other what they did the previous day toward their team's iteration goal, what they intend to do today toward the goal, and any roadblocks or impediments they can see to the goal. Sprints are typically kept to a minimum agenda as normally the full team is present. This means important items can be raised and resolved while low level discussions are picked up outside the stand-up. 


Quality focus

Specific tools and techniques, such as continuous integration, automated unit testing, pair programming, test-driven development, design patterns, behavior-driven development, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance product development agility. This is predicated on designing and building quality in from the beginning and being able to demonstrate software for customers at any point, or at least at the end of every iteration.


Philosophy

Compared to traditional software engineering, agile software development mainly targets complex systems and product development with dynamic, non-deterministic and non-linear characteristics. Accurate estimates, stable plans, and predictions are often hard to get in early stages, and confidence in them is likely to be low. Agile practitioners will seek to reduce the leap-of-faith that is needed before any evidence of value can be obtained.[35] Requirements and design are held to be emergent. Big up-front specifications would probably cause a lot of waste in such cases, i.e., are not economically sound. These basic arguments and previous industry experiences, learned from years of successes and failures, have helped shape agile development's favor of adaptive, iterative and evolutionary development.


Adaptive vs. predictive[edit]

Development methods exist on a continuum from adaptive to predictive.[37] Agile software development methods lie on the adaptive side of this continuum. One key of adaptive development methods is a rolling wave approach to schedule planning, which identifies milestones but leaves flexibility in the path to reach them, and also allows for the milestones themselves to change.


Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team has difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method is about what will happen on that date. An adaptive team cannot report exactly what tasks they will do next week, but only which features they plan for next month. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.


Predictive methods, in contrast, focus on analyzing and planning the future in detail and cater for known risks. In the extremes, a predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive methods rely on effective early phase analysis and if this goes very wrong, the project may have difficulty changing direction. Predictive teams often institute a change control board to ensure they consider only the most valuable changes.


Risk analysis can be used to choose between adaptive (agile or value-driven) and predictive (plan-driven) methods. Barry Boehm and Richard Turner suggest that each side of the continuum has its own home ground.


Agile vs. waterfall

One of the differences between agile software development methods and waterfall is the approach to quality and testing. In the waterfall model, work moves through Software Development Lifecycle (SDLC) phases—with one phase being completed before another can start—hence the testing phase is separate and follows a build phase. In agile software development, however, testing is completed in the same iteration as programming. Another way of looking at it is “Agile: make it up as you go along. Waterfall: make it up before you start, live with the consequences”. 


Because testing is done in every iteration—which develops a small piece of the software—users can frequently use those new pieces of software and validate the value. After the users know the real value of the updated piece of software, they can make better decisions about the software's future. Having a value retrospective and software re-planning session in each iteration—Scrum typically has iterations of just two weeks—helps the team continuously adapt its plans so as to maximize the value it delivers. This follows a pattern similar to the Plan-Do-Check-Act (PDCA) cycle, as the work is planned, done, checked (in the review and retrospective), and any changes agreed are acted upon.


This iterative approach supports a product rather than a project mindset. This provides greater flexibility throughout the development process; whereas on projects the requirements are defined and locked down from the very beginning, making it difficult to change them later. Iterative product development allows the software to evolve in response to changes in business environment or market requirements.


Code vs. documentation

In a letter to IEEE Computer, Steven Rakitin expressed cynicism about agile software development, calling it "yet another attempt to undermine the discipline of software engineering" and translating "working software over comprehensive documentation" as "we want to spend all our time coding. Remember, real programmers don't write documentation."


This is disputed by proponents of agile software development, who state that developers should write documentation if that is the best way to achieve the relevant goals, but that there are often better ways to achieve those goals than writing static documentation. Scott Ambler states that documentation should be "just barely good enough" (JBGE),[44] that too much or comprehensive documentation would usually cause waste, and developers rarely trust detailed documentation because it's usually out of sync with code, while too little documentation may also cause problems for maintenance, communication, learning and knowledge sharing. Alistair Cockburn wrote of the Crystal Clear method:

Crystal considers development a series of co-operative games, and intends that the documentation is enough to help the next win at the next game. The work products for Crystal include use cases, risk list, iteration plan, core domain models, and design notes to inform on choices...however there are no templates for these documents and descriptions are necessarily vague, but the objective is clear, just enough documentation for the next game. I always tend to characterize this to my team as: what would you want to know if you joined the team tomorrow.
—  Alistair Cockburn.

Source: Wikipedia


Agile software development methods

Agile software development methods support a broad range of the software development life cycle.[46] Some methods focus on the practices (e.g., XP, pragmatic programming, agile modeling), while some focus on managing the flow of work (e.g., Scrum, Kanban). Some support activities for requirements specification and development (e.g., FDD), while some seek to cover the full development life cycle (e.g., DSDM, RUP).


Notable agile software development frameworks include:



As part of your digital transformation with voolama, we evoke the Agile style you choose, along with our expert information on the pros and cons of each. Fill in the form below to find out more.

Want More Information?

Get in touch, we would love to spend some time talking about your needs and showing how voolama can provide value.

Contact Us

someone typing on keyboard

A Framework for Digital Transformation

By Dean Brown • October 11, 2021
Most businesses today have already made the digital transformation journey, If you are ready to take the next step towards digitization, contact us.
People at a computer being shown how something works

Change Management and Digital Transformation

By voolama • October 10, 2021
Are you looking for change management solutions? Read on to find out how the Aprimo tool may be able to help you out today.
person looking at an ipad

Digital Transformation is changing. Here's what comes next!

By Dean Brown • October 3, 2021
IT leaders are in a strong position after digital initiatives saved many businesses. But now, what businesses are asking for is evolving again. Digital Transformation has helped companies become more flexible and resilient in the face of worldwide recession, leaving the more digitally mature among them better placed to prosper in the post-pandemic era . After years of being promoted, piloted and implemented with varying degrees of urgency and success in organizations, digital transformation enabled a rapid pivot to remote working and put the digitization of business processes, including customer and employee experience ( CX and EX ), to a serious stress test. In its IT Spending & Staffing Benchmarks 2021/22 report, market research firm Computer Economics described technology's role in the rapid recovery from the pandemic as "nothing short of a miracle". Digital transformation passed the test, it seems. Going forward, Computer Economics suggested that the "low-hanging fruit" in cloud migration is now picked and that "We are now in the stage of digital transformation where we are not just replacing existing tools -- we are now enhancing them." In this article we'll examine where digital transformation is likely to go next. What the analysts say ... Towards the end of 2020, in the grip of the pandemic and with vaccine deployment still to come, IDC published its predictions for digital transformation (DX) for 2021 and beyond.  The headline prediction was that direct DX investment will total over $6.8 trillion between 2020 and 2023 -- a compound annual growth rate (CAGR) of 15.5%. IDC says that that translates into nearly two-thirds (65%) of global GDP being digitalized by 2022. By 'digitalized', the analyst firm means "the inherent value that digital brings to existing products and additional digital services that companies might offer," explained Bob Parker, senior vice president at IDC, in an accompanying webcast . "This is why digital transformation is really a CEO priority -- more so than a CIO priority," Parker added.
sign on wall stating: this is the sign you have been waiting for

Why Digital Transformation Should Be Your Number One Priority

By Dean Brown • August 11, 2021
The trend towards fully digitally-enabled businesses has only been accelerated by this global pandemic and it’s never been more important to make sure that you’re on the cutting-edge. Regardless of what industry you’re in, or what size your business is – your digital capabilities are going to make or break your operations.
marketer happy with changes to their tools

Digital Transformation in Marketing Operations

By Dean Brown • August 10, 2021
Digital transformation has been influencing every single industry on Earth for the past several years. The digital transformation industry is on track to become a $1,009 billion industry by 2025. That's double what it was worth at the end of 2020.
Share by: