Nearly all modern technology businesses practice some form of the agile methodology for software development—or they intend to. Today, the agile methodology broadly influences software development, and this is true even for developers who entered the field using the waterfall software development methodology decades ago, and who are new to agile application development.
But the success of agile development methodology and its omnipresence leads to a number of important questions. For example:
Particularly for larger companies, there are a number of challenges inherent to implementing agile methodology. How do you make agile work in a larger organization? Agile development requires small teams, and many larger businesses start with huge projects spread across massive teams.
Can agile methodologies work within the organization's existing accountability systems and management processes? If so, how? And along these lines, how do you make agile work remotely, with a geographically dispersed team? Can agile work within regulatory requirements?
Almost any organization values the idea of including user experience as a core business outcome, but it's often challenging to implement at the enterprise level. The inherent flexibility and responsiveness of agile methodologies may be appealing to the C-suite, but it's not always clear that they hold practical relevance for a specific business or product.
To successfully employ agile development methods, it is critical to learn how it really works; understand when it is appropriate to use; practice agile throughout the culture; starting at the top; allow and encourage teams that have mastered the process to modify and customize their own practices; and remove any remaining corporate barriers to agile methodologies.
You are in the right place if these concerns are top of mind for your business. Read this guide to understand:
An agile methodology or approach emphasizes the ability to successfully respond to change within a dynamic, uncertain environment. This kind of quick, responsive adaptation is a constant focus on identifying points of uncertainty to better manage them as problems arise.
Agile software development methodology focuses on iterative development, where cross-functional, self-organizing agile software development teams collaborate to evolve responses, requirements, and solutions. Agile helps teams deliver business value in agile more rapidly with fewer problems. By working in small increments rather than focusing everything on one massive launch, an agile team is better able to naturally evaluate and respond to issues with plans, requirements, and results quickly.
The agile software development process ultimately delivers enhanced predictability, higher quality, and improved ability to respond to changes—and all of that value comes more rapidly using an agile approach. Agile processes and an agile methodology in mobile application development foster several themes: a project management strategy that is disciplined and motivates adaptation and ongoing inspection; a philosophy of leadership that stimulates self-organization, teamwork, and accountability; a business approach that aligns user needs and business goals; and a collection of best practices of software engineering that ensure the team can deliver high-quality software rapidly.
Any development process that follows the concepts and 12 principles set forth in the Agile Manifesto, a 2001 manifesto for agile software development we will cover in the next section, can be considered an agile approach to software development. 14 leaders in the software industry created the Manifesto, which reflects their experience concerning which approaches to software development work, and which do not.A major distinction between agile software development and other approaches is the focus on people and how they collaborate using cross-functional, self-organizing teams. There are still managers within an agile approach, but their focus is on ensuring the team has the right skill sets to succeed. Managers in an agile software development company might also step in to assist when teams cannot resolve problems.
Ultimately, an agile team shares a mindset that the Agile Manifesto principles and values inform and guide. These notions provide a strategy for dealing with uncertainty more generally, and creating and responding to change specifically.
When a team faces uncertainty as part of an agile product development process, they try something they believe could work. This allows them to get feedback, and adapt their approach to meet the moment.
Who developed agile methodology? Incremental, iterative approaches to software development can be linked to evolutionary project management in the 1950s, and later adaptive software development in the early 1970s. By the 1990s, the prevailing methodologies for software development were often referred to collectively as waterfall, and were, overall, heavyweight, and highly planned, regulated, and micro-managed.
This tendency towards heavy, unwieldy methodologies led to a trend toward lightweight software development methods in the 1990s. Rapid application development (RAD), dynamic systems development method (DSDM), the unified process (UP), Scrum, extreme programming (XP), Crystal Clear, and feature-driven development all arose between 1991 and 1997. Although each of these methods for agile system development arose before the Agile Manifesto was published, they are now collectively considered agile software development methods.
In 2001, 17 software developers met in Snowbird, Utah to discuss these lightweight development methods and together they published the Manifesto for Agile Software Development. The engineers from 2001 were: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.
In 2001, the Agile Alliance was formed officially as a space for software developers to share experiences and ideas.
In 2005, Cockburn and Highsmith led a group who wrote the PM Declaration of Interdependence, an addendum of project management principles. The aim of the PM guide is to detail agile software development methods to guide agile project management for software development.
Martin and a team completed the Software Craftsmanship Manifesto, an extension of software development principles, in 2009. This guide offers professional conduct and mastery for agile software development.
The Agile Alliance created the Guide to Agile Practices—an open-source, evolving compendium of working definitions of agile terms, practices, and elements, along with experience guidelines and interpretations from the international community of agile practitioners—in 2011. In 2016, the guide was renamed the Agile Glossary.
In other words, while each half of the statement may be important, the first half in every case is going to take precedence for an agile approach. In practice, this is how that emphasis breaks down.
Individuals and interactions over processes and tools. Although the processes and tools teams use are important, bringing the right people with the appropriate competencies together is more important for an effective team. This first value emphasizes communication and collaborative team working. The best teams will deploy the right tools as needed, and the quality of their interaction is what will determine their outcomes. Software development is a human activity that relies on team working.
Working software over comprehensive documentation. Creating software that works, not documentation, is the end goal of development—although good documentation is an excellent resource in understanding how to use the software and how it was built. The ultimate goal of software development will remain creating software that delivers business benefits.
Customer collaboration over contract negotiation. Teams will understand the actual needs and desires of all stakeholders by seeking out and listening to feedback. This is why development teams must frequently communicate and collaborate closely with their customers. A contract, while critical, is no substitute for this kind of customer input and collaboration.
Responding to change over following a plan. Frequent changes are a reality of software development, making a flexible project plan important. The software process and the plan must reflect reality, and it cannot be too rigid to manage changes in how stakeholders see the problem, potential solutions, or project priorities, not to mention changes in the environment or relevant technologies. At the heart of the approaches are a very short adaptation cycle and feedback loop—for example, the daily stand-up or daily scrum in which team members report progress toward the team's iteration goal from the previous day, what they will do today to help reach the goal, and any challenges or roadblocks they have identified.
There are 12 principles, according to the Agile Manifesto. These principles Orange practices set forth the guidance for organizations and teams to adopt an individualized approach that works for their team's skill set and project.
The agile software development 12 principles are:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
People develop software for others to bring value to them or their business. Waiting too long to deliver the working, valuable software is unsatisfying, and this becomes truer each year. Customers expect fast delivery, and early, frequent, continuous feedback makes that possible.
Users are accustomed to frequent updates, and every new delivery should add value for the user. For example, people don't care about changes in code; they do care that those changes make logging into a site easier, faster, or more secure. When demand changes, they need and expect to see them rapidly.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
It is difficult or impossible to predict software requirements in a dynamic environment. No one loves big changes, but burning money on an inadequate, outdated product is worse. Welcoming change enables product owners to satisfy user needs faster rather than focusing on outdated demands. A more rapid response to user needs translates into a competitive advantage.
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
This principle goes beyond delivering valuable software early on and frequently in the process, as the first principle instructs, clarifying what it really means to deliver continuously. An agile approach aims to deliver new, smaller release versions of software within a shorter timescale to allow more client feedback and fewer bugs to get through. Accommodating feedback rapidly enables weekly and sometimes daily releases that add tangible value to users.
“Business people and developers must work together daily throughout the project.”
This principle seeks to eliminate information silos that prevent business people and developers from working together more effectively. Extra steps in communication lead to lost information and time. By ensuring the developers and business team collaborate closely, you reduce these risks.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
An agile team has the right experience, responsibility level, and skill set to produce quality software. Trust the right team once they are in place and give them the right environment, coaching, and tools to complete their work to a high professional standard. Projects built around unmotivated or demotivated people aren’t as likely to succeed.
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Despite the many ways we can now communicate thanks to technology, face-to-face talking remains the most effective for the human brain. Our minds interpret language and the sound waves of voices, but also body language, timing, and facial expressions as well as other kinds of signals. Asynchronous and remote communication often leads to misunderstandings.However, today more and more teams do work remotely, for a variety of reasons. Technologies like business communication platforms, chat apps, and issue trackers are better means for communicating and collaborating asynchronously, and there are numerous tools for remote face-to-face conversations.
“Working software is the primary measure of progress.”
Bringing software projects to completion can be a lengthy process, which makes a means for measuring progress important. Working software, the final step that actually adds value for users, is the primary way of measuring progress for an agile approach. Some take the view that the software must be working as well as released or delivered.
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Anyone who has felt crushed by a traditional waterfall project management workflow understands the appeal of working at a sustainable pace. As implementation date approaches, the whiplash effect of a traditional project management schedule forces the team into overdrive, causing a feeling of helplessness and stress. No one feels the crunch more than testing or quality assurance teams, who receive the product last in the stream of a waterfall project.Each team member has a role in maintaining a more sustainable pace. Product owners should not make commitments to the business team that the development team does not fully support, nor should they demand that the development team commit to goals beyond the next sprint.The development team should create sprint estimates based on breaking down stories into actionable tasks, not on initial estimates; sprint planning should be the lengthiest timebox among meeting events. The development team should also avoid hurting the potential for creative collaboration or product quality by taking on too many backlog items into the sprint backlog. It is better to underestimate and then bring the next priorities in.Scrum masters should monitor the team for external pressures to prevent overextension. They should also investigate and remove any roadblocks to team health that frequent or habitual overtime might signal.
“Continuous attention to technical excellence and good design enhances agility.”
Eventually, poor or inferior technical design impedes speed and time-to-market. So although the end-user doesn’t care about technical excellence and unreleased software is a cost, attention to technical excellence is critical to the ability to respond to a changing market.
“Simplicity—the art of maximizing the amount of work not done—is essential.”
There are several ways to maximize the amount of work the team doesn't personally do. For example: you can automate manual work, remove irrelevant procedures, or use existing libraries rather than writing your own. This allows more focus on delivering value while saving money and time.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
Teams should master self-organizing each piece of software development: communicating with the business team to gather requirements; organizing their work; and writing high-quality software, for example. This fosters ownership in the product and product operations—resulting in better softwareSeeing developers as factory-line recipients of coding requirements is an error, as is a development team that merely sees itself writing code. Developing software demands more, including the development team taking on more responsibility, communicating effectively with the business team, and producing working software without extensive top-down supervision.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
No team is perfect, so every team should reflect on its performance at regular intervals, and adjust and tune its behavior accordingly. A mature agile software development team can respectfully and thoroughly identify issues and take corrective action.
There are a variety of agile web development and agile mobile application development methodologies, each sharing the overall goal of adapting to change and delivering working software as rapidly as possible. However, each agile methodology varies slightly in how it defines the phases of software development. Furthermore, although they may share the same broader agile application development goal, depending on the specific situation or project, the process flow of each team may vary.
Most processes and methods minimize up-front product design and development by breaking the work of product development into short increments. Iterations, also called sprints in many methodologies, are short time frames or timeboxes that generally span one to four weeks.
A cross-functional team is part of each iteration, and team members will be engaged in each part of the iteration: planning, design, analysis, coding, and testing. The team demonstrates the working product to stakeholders at the end of the iteration. This allows the team to quickly adapt to changes and minimize overall risk.
The goal for the end of each iteration is an available release with minimal bugs, although an iteration might not add enough functionality to merit a market release. The idea is for products to fail early and often by undergoing rough incremental development rather than failing massively on a final release date. To release new features or a product, it might take multiple iterations.
Every agile development model shares the same overall goal: delivering working software as rapidly as possible by adapting readily to change. However, there are slight variations that distinguish each methodology in how they define the phases of the cycle. As well, despite this common goal, the process flow of any given team may vary depending on the particular situation or project.
For this reason, the details for each agile plan may differ. However, despite some granular differences, the full life cycle typically includes: scoping out the concept or objective; inception and identifying requirements; construction or iteration; release into production; production and ongoing support; and retirement phases.
The Agile software development life cycle is shaped by iterations, and a typical iteration process flow looks like this:
Requirements. First the team defines the requirements for the iteration based on the sprint backlog, product backlog, and feedback from the customer and other stakeholders.
Development. The team designs and develops the next version of the software based on the requirements defined in the first step.
Testing. Also called quality assurance (QA) more broadly, this part of the iteration process includes the development of the documentation, internal and external training, and QA testing.
Delivery. The team integrates and delivers the working version of the software into production.
Feedback. The team elicits, analyzes, and uses feedback from the customer and other stakeholders and uses it to shape the next iteration's requirements.There are several important roles in agile methodology and each agile software development process begins with defining the roles and users. The next step involves creating a vision statement that documents the scope of opportunities, problems, and values that the process must address.
User. The user or customer is at the heart of agile processes and is sometimes defined with user personas. These illustrate various customer behaviors and needs as well as different roles in a workflow the software supports.
Product owner. The agile development process starts with a customer voice, distilled into a product vision. This vision creates a view of who the user is, what they want and need from the product, and how the product will meet those wants and needs. The product owner defines this vision and collaborates with the development team to bring it to fruition by breaking the product vision down into multiple user stories. Each user story expresses a simple user need or problem and how to meet that need.
Software development team. In contrast to traditional software development teams, agile software development teams are diverse and multidisciplinary, capable of completing end-to-end functioning applications thanks to a broad-based yet deep skill set. The agile team may include not just software developers, but also analysts, designers, quality assurance (QA) engineers, and other engineers such as for back-end systems and databases, depending on the project.
The traditional waterfall method for software development starts with a detailed design plan that includes strict phases and original requirements. This plan is created at the start of the project, typically by a project manager, who negotiates the project's milestones, features, and resources. A full-scale project plan clarifies how the team will move the work across each stage from inception to completion.
Customers finalize requirements before development ever begins. The project manager tracks every movement of the project once the lengthy, involved development process starts, including every handoff through delivery. If everything goes according to plan, this process results in an on-time, on-budget release.
However, the main drawbacks to the conventional waterfall approach are well-understood, and mostly stem from its lack of speed and responsiveness. The inflexible requirements and typical release cycle for a waterfall approach, which is six months or longer, are not as readily able to meet business needs in a change-driven technology setting.
The rise of agile software development was nurtured by growing frustration with conventional waterfall methodology. The approach emphasizes feature selection, hours, meetings, prioritization, rather than milestones.
In contrast to the waterfall method, an agile team decides what can be accomplished in the available time frame at the start of an iteration or sprint and, based on that, builds that series of features. The goal is to deliver working software at the end of the sprint that can be installed in a production environment, adjusting the method as the project's needs demand it.
An approach informed by agile vs traditional waterfall approaches highlights a major difference in how team members collaborate on a project. In a classic waterfall strategy, one contributor adds their skill set or discipline to the project in relative isolation, and then places the product back into the stream for the next contributor.
In contrast, the heart of an agile approach is the collaborative, cross-functional team that values trust, communication, and adaptation. The team itself takes the lead in self-organizing around granular assignments and tasks as they decide how work will be completed, although the product owner or team lead typically does prioritize deliverables. The project leader usually eliminates bottlenecks, facilitates the development team's work, and helps keep the team focused on delivering iterations of the software regularly.
Agile is a series of methodologies in service to a commitment to continual improvement and tight feedback cycles. It is not defined by a specific list of development techniques or ceremonies.
DevOps is a culture that values and promotes collaboration between teams of developers (the “Dev”) and the IT operations team (the “Ops”). DevOps is a method for software development which enables rapid deployment of products, services, and applications with a focus on integration, communication, and collaboration among IT professionals.
Similarities between agile and DevOps include:
Differences between agile and DevOps:
Although software developers created the Agile Manifesto and its 12 Principles to address problems facing software developers, agile development principles can be applied to other activities. Agile project management is focused on dealing with uncertainty and creating and responding to change while performing effective project management.
Agile project management delivers a project in several iterations or incremental steps throughout its life cycle by taking an iterative approach.
By breaking project requirements into smaller tasks and deliverables, the team can prioritize them based on importance, releasing benefits throughout the process instead of just once when the project is over. Agile project management promotes collaboration, particularly with the customer, to ensure benefits from the product are maximized.
Agile project management methods create a working mindset by integrating planning and execution, allowing more ability to respond effectively to changing requirements. This iterative approach reflects central agile behaviors and values such as collaboration, empowerment, flexibility, and trust.
Agile project management goes further than agile software development, adapting teams to an agile approach in designing and executing projects that include high levels of uncertainty, and implementing agile approaches geared toward both team members and project managers at the project level. Agile project management can be used in any vertical, particularly as high uncertainty projects span more industries.
Agile product management creates an agile environment for developing product roadmaps and setting product strategy. So organizations can respond to feedback quickly and build more useful products that satisfy customers more, agile product development encourages an adaptive approach to implementation and product planning. In large part, agile product management is a response to the widespread use of agile software development methodologies that emphasize early delivery, evolutionary development, and continual improvement, such as kanban or scrum.
The benefits of agile product management include redefining the way product managers consider how to build and plan for products. Traditionally, a step-by-step approach to planning, designing, implementing, and testing new customer experiences has delivered new functionality sequentially. But under this classic approach, it was difficult to make any changes once requirements were defined and provided to the development team, driving an unacceptable failure rate for lengthier and larger-scale software development projects. This in turn highlighted a need for a more flexible, dynamic approach for adapting to learnings such as customer feedback.
Compared to a traditional process for software planning and development, agile offers a more flexible approach. The team builds products in short increments, allowing product managers to adapt the plan as issues crop up.
Some of the important benefits of agile product management include:
Agile product development teams guide their products through multiple iterations while the scope of the project may vary, even as the resources remain the same. Agile product management is a more fluid, flexible approach than traditional methods, keeping the bigger picture goals in mind while adjusting to individual issues that arise during each iteration.
Agile methods exist as sets of conventions that follow agile values and principles and help teams achieve an agile environment or culture. This means that every team will have its own agile software development model and methodology.
Agile frameworks or methodologies support a broad swath of the software development life cycle. Some agile methods such as pragmatic agile development, XP, and agile modeling focus on the practices, while others like scrum and kanban focus on managing workflow. Some methods such as FDD support requirements specification activities, while others such as DSDM and RUP support the full development life cycle.
Some of the most common agile development models include:
Agile software development with scrum methodology, created by Ken Schwaber and Jeff Sutherland, offers a simple framework for complex projects. Scrum is the most widely-used subset of Agile, and a process framework that is considered “lightweight.”
“Lightweight” indicates that scrum maximizes the amount of available productive time for useful work by keeping process overhead as small as possible. Calling scrum a “process framework” means that by following a particular set of practices for scrum, a team will create a process that is consistent with the framework.
In Scrum, projects are typically divided into 2 or 3 week cycles called sprints. Sprints are timeboxes for developing sets of features. Multiple sprints may comprise a release—the formal product delivery of the software to market or the customer.
The product owner breaks down the overall product functionality into smaller features as part of the scrum process, and these are typically described as user stories, epics, or just stories. The team prioritizes and tackles stories in each iteration or sprint with the goal of demonstrating a working portion of the product at the end of each sprint to the product owner.
The overall effect of the scrum method is to ensure the product is working well, and break down the long waterfall process delivery into more manageable cycles. This better allows the end-user and product teams alike to review working software frequently and ensure that it meets business needs.
Scrum Sprints and Artifacts
The sprint is the basic unit of work in scrum. This short development cycle is usually between 1 and 4 weeks long, and is the target timeboxed period for producing a shippable product increment. Longer iterations lack the flexibility and predictability of the scrum sprint. All of a project's sprints should have a set length, since there is no standard duration for sprints, to keep it easier to track progress and plan.
Three main artifacts are essential to managing scrum requirements and tracking progress:
Product backlog. This is a single, ordered list of feature items and requirements that could be needed for the final product. The team updates the product backlog as they change or add new details, features, fixes, and requirements.
Sprint backlog. The sprint backlog lists each of the tasks the team must complete within a given sprint to deliver an increment of functional software. It represents an agreement on which items to deliver and how to do it.
Sprint burndown chart. The sprint burndown chart illustrates the remaining work in a sprint showing day-to-day progress and helping the scrum master and the team to predict whether they will reach the goal on schedule.
Specific ceremonies such as the daily standup meeting or daily scrum, the sprint review meeting, the product owner demo, and the sprint retrospective meeting characterize the scrum method. All of these meetings offer the team opportunities for agile retrospective questions to review, collaborate and ensure that any issues are resolved quickly and development is progressing as planned.
The work for each sprint is planned at the sprint planning meeting, and all stakeholders in the sprint participate. This means a scrum master, product owner, and development team all work to decide which work to do and how to do it for the particular sprint. Planning for a one-month sprint should take eight hours or less, with shorter sprints taking less time.
The daily scrum is a timeboxed, 15 minute meeting. During the daily scrum, which should be held at the same time and place every day, the development team sets a plan and coordinates its work for the next 24 hours.
As each sprint closes, the product owner and team meet for the sprint review. There they will reveal completed work and discuss coming product increments and next steps for increasing the product’s value. For typical one-month sprints, the sprint review is a four-hour timeboxed meeting.
After the Review and before the next Sprint Planning The whole team attends the retrospective meeting to reflect on the work of the sprint, ways to improve, what went right and wrong, and how to implement changes. For one-month sprints, the retrospective meeting should last three hours.
Scrum User Story
As in XP or extreme programming, most scrum projects describe a feature request as a user story in narrative form, although a smaller group of organizations still call it a use case. The product owner typically writes user stories.
There is no standardized format for scrum user stories, but typically they have a name; a description that includes some descriptive text along with screenshots or other references to external documents; and testing information for the implementation. For example, a user story might work like this:
Name: As a user, I want to enter new contact details into my address book so I can click on the contact later to communicate with the person.
Description: User enters contact information such as first and last name, mailing address, telephone number, email address, and other messaging details into a contact-entry screen. User either clicks “Save” to retain the data and save the contact, or “Cancel” to delete the data and contact and return to the last screen.
How to test: Tester enters contact details; saves the data and contact; locates the new contact in the address book; click on the new contact; sees an accurate, read-only contact-entry screen; and uses contact details to communicate with contact.
The name is a descriptive sentence or phrase. In the example, you see the common Mike Cohn style, which follows this template: [As a <user>, I want <goal> so that <reason>.” You could also express the user story in the example with a basic “role-action-reason” organization: “The user enters contact details to communicate with the person later.”
The description should provide a low-detail, high-level explanation of the unmet need. Whether in narrative form for user-facing, functional requirements, or in some other easy-to-understand format for non-functional requirements, the key to a good description is a modest level of detail. This is because the stakeholders work out the finer details during the implementation phase, allowing for better ability to manage changes.
Any external documents the team will require to implement the story should be listed. The story should also include or link to a prototype of any user-interface changes, particularly those that are non-trivial.
Testing is critical because story implementation is complete only if it passes every acceptance test the team develops for it. As in other sections, this brief testing description should leave the details for the implementation phase. However, story testing information is important to guide test case development, and to help the team estimate implementation time, work, and costs.
Requirements for new development that do not represent user-facing features but will demand significant work that must be done are non-functional requirements called technical stories. Technical stories and user stories share the same elements, but there is no need to cast technical stories in narrative form unless there is a specific benefit.
Typically, team members write technical stories and add them to the product backlog. To rank or sequence all stories for implementation, the product owner must be conversant with technical stories, and understand the dependencies between them and user stories.
A defect, also called a bug report, describes any product failure to behave as expected. A bug tracking system stores defects. If this system is physically distinct from the location of the product backlog, the product owner must enter each defect into the product backlog for sequencing and scheduling.
Scrum is home to three defined roles: the scrum master, the product owner, and the team. All roles work together closely to deliver the product.
The scrum master manages the process, removing obstacles that impact productivity and ensuring that it runs smoothly, and facilitating and organizing critical meetings. The responsibilities of the scrum master include:
The product owner is the single source of truth and the holder of the project requirements and their implementation plan. The responsibilities of the product owner include:
The team is a cross-functional, self-organizing group who does hands-on developing work and product testing. The ideal team size is five to nine people; fewer can lead to fragility and low productivity, while more can make communication difficult. Some of the responsibilities of the team include:
The phrase “scrum team” usually includes not only the team, but also the product owner and the scrum master.
When to Use Scrum
Scrum is most effective for complex, long-term projects that demand feedback from stakeholders which could potentially affect project requirements in significant ways. In other words, when there is no fixed release date and the exact amount of work can’t be estimated, scrum may be the best choice. An agile scrum process assists businesses in:
Kanban is another common project management framework. Forty three percent of companies have stated that they use Kanban as one of the project management frameworks. Translated as “visual signal” from the Japanese, Kanban originated as a visual card system used as a production control method in “just-in-time” (JIT) Toyota manufacturing.
Kanban is a simple approach that focuses on visualizing the workflow, allowing the team to prioritize work in progress (WIP). This in turn allows the team to limit the scope of WIP to effectively match the team’s capacity.
The team can take the next item in the flow as soon as a task is completed. This development process therefore offers clear objectives, faster turnaround, more flexibility in planning, and transparency. The goal of Kanban's visualization is to help teams identify and fix potential bottlenecks in the process, so they can achieve an optimal speed for the work.
There are no standard required procedures or tools for the Kanban process, in contrast to Scrum. The workflow visualization itself, as expressed through a Kanban board, is the basis for the project management.
Kanban boards are usually created with whiteboards and sticky notes or online tools like Trello that digitize and automate Kanban. Each Kanban card should include succinct information about its work item, who is responsible for it, what each team member's task is, when each task should be finished, and other details. Team members can also attach screenshots, documents, or links, and leave comments to share information.
There are three basic principles that govern Kanban:
Kanban defines the optimal team workflow to encourage ongoing, active improvement and learning, and promote continuous collaboration.
When to Use Kanban
Teams can use Kanban to adapt to shifting priorities and complete small releases. There are no predefined goals or sprints, unlike in scrum, and Kanban is more focused on immediately completing small tasks as they arise. Kanban, for example, works well after a main product release since developers immediately work to fix errors found by testers. Some organizations combine Kanban and scrum techniques, using a hybrid Scrumban version.
This discussion centers on two different agile strategies: one more fluid and continuous, the other based in structured, timed sprints.
Kanban teams focus on reducing the time a project or user story takes to proceed from start to finish by visualizing the workflow, limiting work in progress, and maximizing flow or efficiency.
Scrum teams create special artifacts, adopt specific roles, and hold regular ceremonies to keep the process in motion and keep their commitments to deliver working software within set intervals. The goal is to quickly collect and integrate feedback, creating learning loops that enable a fast response.
The scrum vs kanban difference breaks down as follows in several areas:
The Crystal family of methodologies, sometimes called the Crystal family, was developed in the mid-1990s by Alistair Cockburn. Crystal methods are focused on:
A crystal method approach features traits that are generally centered around the team:
There are two core beliefs that form the foundation of the crystal agile framework:
The Dynamic Systems Development Method (DSDM), sometimes called the dynamic software development method, is an agile framework composed of a lifecycle, roles and responsibilities, products, eight principles, four different types of requirements, and several best practice techniques.
The aim of DSDM is to maximize return on investment (ROI) by delivering strategically aligned business benefits more rapidly.
There are eight underlying principles of the DSDM approach that direct team culture:
The DSDM methodology breaks a project down into four different types of requirements:
DSDM is a useful approach for many software projects characterized by tight schedules and budgets. Its development is incremental and iterative, and its focus is on frequent delivery of product cycles.
Jim Highsmith and Sam Bayer developed Adaptive Software Development (ASD) in the early 1990s. It incorporates the idea of continuous adaptation, employing a dynamic development cycle: Speculate, Collaborate, and Learn. The aim of this cycle is to adapt to the constant change in the business environment by fostering intense collaboration between customers and developers, and nurturing constant learning.
In contrast to the classic, static Plan-Design-Build software development life cycle, the non-linear, iterative ASD life cycle has three main characteristics:
Feature Driven Development (FDD) is primarily oriented toward teams that are too large for methods such as scrum. Developed in 1997 by Jeff De Luca and Peter Coad, FDD focuses on short two week iterations, followed by tangible product deliveries.
Because larger teams and the projects they handle may be challenged by uneven levels of discipline and skill, FDD includes specific activities that help coordinate larger projects and solve communication challenges.
Specifically, there are five stages in the FDD process. The first two FDD stages are sequential, and the last three are shorter, iterative activities:
Each project produces a unique model and feature list. A feature can be built within two weeks. Anything that takes more time than that gets broken down into multiple smaller features.
And while FDD resembles other agile methodologies in many ways, it stands apart in its appeal to larger development teams working on complex software. FDD provides solutions, for example, on how to program the code and how to organize the team, which can assist a larger team in scaling an agile approach. This scalability is the result of the “just enough design initially” or JEDI concept.
Dan North created Behavior Driven Development (BDD) in 2003 as a behavior-oriented version of the TDD agile development methodology. The problem that had come to light was that failing to include business concepts in software development can hamper functionality, resulting in recurring bugs that are potentially serious. The idea was to include non-technical people in the process of creating and updating the technical functionality of the system.
To do that, BDD encourages collaboration between people with and without technical knowledge with universal language concepts. Writing test scenarios and features that contain the requirements and acceptance criteria for system behavior are the foundation of the BDD development process. The plain language of the BDD process explains what requirements the functionality has to begin with, what it will do next, and what will happen after execution.
The advantage of BDD is that it can help diverse teams identify defects more quickly, communicate requirements more accurately, and build more sustainable software.
Like Kanban, Lean began with the manufacture of physical goods in the Toyota Production System, or TPS. And while Lean is still popular in manufacturing, it has also found many knowledge work applications. Lean remains one of the five most-used Agile frameworks.
Software development, much like manufacturing, is a natural locus for Lean methodology. Software development more or less follows a process that is broadly defined, has also defined conditions of acceptance, and produces tangible results that have value.
The Pillars of Lean are important concepts that guide all Lean methodology practice. There are at least two of these concepts:
and some include a third pillar here:
Mary and Tom Poppendieck first applied Lean principles to software development in their book Lean Software Development: An Agile Toolkit. In that book, they detail seven Lean principles for software development:
Eliminating waste. From a project perspective, “waste” is anything that does not add value to the project, such as defects, features that are unnecessary, or idle time.
Amplify learning and create knowledge. Lean software development is an ongoing learning process for the whole team. Developers may need several iterations before they detect errors, fix them, and ensure the final version of their code is clear. By producing code variations and solving problems during development, engineers gain knowledge. This means that enhancing learning for the whole team is the best way to upgrade the environment itself.
Decide as late as possible. Late decisions are based on more facts, and are more informed. Delaying a design decision that is irreversible is judicious, given the speed at which technologies become obsolete. By intentionally making commitments late strategically, an organization reserves capacity for change in the system.
Deliver as fast as possible. Faster, shorter software development cycles allow for more feedback and more developer learning. They also enable better customer decisions based on more facts. Fast delivery helps reduce waste.
Empower the team. Developers understand the details of their work like no one else and should have the right to make technical decisions. They can and will create and follow a roadmap.
Build in integrity/quality. How the user perceives the software must coincide with its actual characteristics. If a user thinks the software is easy to use and has the necessary features, that user perceives integrity in that system. However, conceptual integrity depends on the software scoring high on fitness of purpose and usability, and having a coherent architecture. It can be adapted, maintained, and extended.
See the whole. Engineers should see the big picture of the system's overall efficiency and take charge of it, rather than focusing only on their part of the work.These ideas describe Lean philosophy, and like other agile approaches, Lean software development is an iterative and incremental framework. This means that feedback from the product owner is critical to progress. One difference between the Lean approach and other frameworks is that a team using Lean does not have to follow any formal processes, such as task prioritization or recurring meetings.
When to Use Lean
Lean enables a minimum viable product (MVP) development technique. The MVP technique includes quickly deploying a product with a minimum set of features that are enough to satisfy early adopters. This allows the team to collect and analyze user feedback to determine whether the product might be viable and create roadmaps for future development.
Lean works best for short-term, smaller projects that have naturally short life cycles. And because Lean requires ongoing feedback, this approach is also appropriate when the customer can participate. Finally, a Lean approach relies on close, frequent team communication, so it is not always ideal for remote teams.
Extreme Programming (XP) is different from the other frameworks we discussed above, principally based on its focus on the technical aspects of software development. XP gets its name because it requires developers to perform a small number of engineering practices at the highest level possible—at an almost extreme level.
Kent Beck, one of the Agile Manifesto signatories, invented XP in the 1990s while working on a Chrysler Comprehensive Compensation System project. His goal was to discover ways of completing even very sophisticated tasks as rapidly as possible.
Four simple values formed the basis for the original XP method: simplicity, communication, feedback, and courage.
There are also twelve supporting practices for XP (the first four are, by far, the most common):
XP has emerged among the most popular Agile methodologies, but also among the most controversial. Pair programming in particular is a source of controversy.
XP is a disciplined strategy for continuously and quickly delivering high-quality software. Its aim is to improve responsiveness and therefore software quality despite changing customer requirements. It achieves this by promoting continuous planning, continuous testing, simpler design, high customer involvement, rapid feedback loops, task prioritization, and close teamwork. The result is the very frequent delivery of working software, typically every week.
When to Use XP
XP practices are designed for small teams—no larger than 12 people. The XP framework functions only if sure developers, customers, and managers can freely communicate and collaborate and will do so.
XP suggests unit testing. It can be used if programmers can create functional tests. Especially when developers must write code within strict timeframes, XP provides tools to decrease risks while developing a new system.
XP is an independent framework, but some of its technical practices can also be used with other Agile approaches. For example, a Scrum/XP hybrid framework that blends Scrum management approaches and XP engineering practices has become popular.
Some combination of Agile approaches and the traditional Waterfall project management approach is called Hybrid.
For example, an organization can use Agile philosophies and practices to modify some of their traditional Waterfall work processes. They might complete project planning in sprints, incorporate feedback or testing in development, and collect feedback on an ongoing basis. Or a team might organize a retrospective or use a Kanban board for a traditional Waterfall model project. There are many ways to inject a Waterfall process with Agile practices.
When to use Hybrid
When product delivery relies on both software and hardware operations, hybrid may be an effective choice. Hybrid is also useful when the customer cannot accept the uncertainty that is typical for Agile or is not satisfied with an unspecified budget or timeframe. In this situation, the team can accomplish planning, specification of requirements, and create an application design in Waterfall, and move on to Agile for development and testing of software.
Gartner introduced the Bimodal approach in 2014. The Bimodal model focuses on managing two separate yet consistent work styles: one based on predictability and the other based on agility.
Mode 1. This is based on predictability and is traditional; it works best in well-understood areas. According to Gartner, Mode 1 focuses on the exploit of what is known and the gradual transformation of the legacy environment for a digital future.
Mode 2. This is based on agility and is nonlinear, exploratory, and optimized for problem solving. According to Gartner, Mode 2 involves rapid application development and is especially useful for completing projects as quickly as possible.
Because each mode demands different techniques, skills, and tools, this approach requires two separate work groups or teams. Teams have two clear goals: adopting innovations while ensuring stability.
The Mode 1 team supports long-term business needs by developing and maintaining core systems and applications. This team's work directly supports the organization's technological capabilities.
The Mode 2 team delivers innovative applications frequently to meet short-term business needs and engage new customers. After analyzing the market and receiving feedback, this team may change the product’s functionality.
The teams must share results and communicate, although they report through different organizational structures and use different delivery mechanisms. Mode 1 relies on Mode 2 for testing new development methods and product ideas, and Mode 2 relies on the services and information infrastructure Mode 1 provides.
When to use Bimodal
Bimodal might be the right option for organizations that specialize in both short- and long-term projects that demand different management and development approaches. This framework balances driving innovations and maintaining IT system infrastructure. Successfully implemented Bimodal approaches helps organizations deliver solutions rapidly and remain competitive.
There are a number of best practices for an Agile team that can help you implement Agile approaches successfully:
Communicate often, in person if possible. Efficient face-to-face communication is behind the co-location principle. That principle states that to improve communication and better establish team identity, team members should be situated together. Co-location enables face-to-face interaction, ideally in a working space, that can reduce the cycle time from fielding questions via persistent chat, wiki, phone, or email.
Customer representative/Product owner. Regardless of the Agile methodology, every team should include a customer representative—in Scrum, the product owner. The stakeholders agree that this person can act on their behalf, and the representative is personally committed to staying available to the team throughout the iteration to answer questions and offer feedback.
Set priorities. A representative or product owner should create and maintain a product backlog or list of prioritized tasks. This should be accessible and visible to the entire team.
Start small, even if you're large. Although large businesses typically launch large change initiatives, the most successful agile introductions typically start small, often with software developers in IT. High levels of success with agile approaches are more likely to succeed across functions with the original practitioners acting as passionate evangelists and coaches for their co-workers.
Maintain short, fast release cycles. Release your product in increments, every 2 to 4 weeks at most, with analysis of feedback from stakeholders before proceeding each time.
Improvise with purpose. If you're new to agile, start with proven methods. Later, allow experienced developers to customize agile practices over time. Let this key principle guide this kind of improvisation: as a team modifies specific practices, it must track the results to ensure that the changes are having a positive impact on team morale, work velocity, and customer satisfaction.
Use pair programming—if it works for your team. In pair programming, two programmers work side-by-side at a single programming station, swapping roles frequently; as one codes, the other reviews the code. Advocates say that pair programming results in higher quality and identical productivity, but critics say it is inefficient and confusing.
Refactor. Reworking code regularly improves results and design without hurting functionality or efficiency.
Use test-driven development (TDD). When you have a set of inputs and outputs that are clearly defined, you can code the unit test first to ensure the project stays on task.
Top-down agile. Although many C-suite activities are not appropriate for agile methodologies, many are well-suited for agile methods. And when senior level executives adopt agile methodologies, there are far-reaching benefits that make agile easier to achieve overall. Leadership is better able to communicate with teams using agile frameworks, and they understand common challenges teams experience and learn how to overcome them. When agile is adopted in a top-down manner in an organization, leaders are more likely to recognize and systematically eliminate behaviors that impede agile teams and stand as barriers to their success.
Metrics an Agile software developer might collect to determine how effective the team is include:
Burn Down Chart. A burn-down chart simply plots outstanding work against time. Time units can be days, sprints, or iterations. Outstanding work can be measured in features, story points, and functions. The ideal line on a burn down chart is plotted straight from the beginning of the project or iteration to the end.
Drag Factor. The drag factor is the number of hours of effort that do not contribute to the sprint goal. The team can improve the drag factor by reducing the amount of non-contributing work, and reducing the amount of shared resources.
Velocity. Velocity compares the units of work from the backlog the team completes during a sprint with the estimate of how many work units it would take to deliver the sprint. In other words, is the team about as fast as expected?
Running Tested Features (RTF). Running tested features (RTF) measures how many customer-defined software features are functioning according to what software tests can verify. Using this metric makes teams more agile by: verifying each feature as working, ensuring software is ready-to-go at each iteration, and focusing on features rather than infrastructure or design. Measuring a project's RTF growth allows teams to analyze whether problems lie within tests themselves or within coding.
Defect Cycle Time. Agile teams aim to fix bugs as quickly as possible and release their software sooner. This is only possible when good tests exist and testers communicate with developers effectively about defects. Defect cycle time conveys how effectively the Agile team works at fixing defects.
Cumulative Flow. A cumulative flow diagram maps the entire workflow of the project, including incomplete tasks, revealing areas that end up being bottlenecks. Unproductive WIP appears as vertical bands that get wider as the project continues, and this visualization assists the team in addressing problem areas.
Defect Spillover. Defect spillover measures the defects that remain after a given sprint or iteration by simply counting them. Left unaddressed, such defects accumulate over time, leading to decreased productivity caused by technical debt.Teams often use specific Agile development tools and techniques, such as automated unit testing, behavior-driven development, code refactoring, continuous integration, design patterns, domain-driven design, pair programming, test-driven development, and other techniques to enhance product development strategy and improve quality. This is based on baking quality into the design from the start, and the need to be able to demonstrate the function and value of software for customers at any time—or certainly at the end of each sprint.
Teams often use specific tools and techniques, such as automated unit testing, behavior-driven development, code refactoring, continuous integration, design patterns, domain-driven design, pair programming, test-driven development, and other techniques to enhance product development strategy and improve quality. This is based on baking quality into the design from the start, and the need to be able to demonstrate the function and value of software for customers at any time—or certainly at the end of each sprint.
What are some of the benefits of the agile development methodology? Agile offers a number of major benefits compared with traditional management approaches:
Teams use agile methodologies to respond to customer feedback or marketplace changes rapidly without derailing extensive plans. Planning and shipping just enough—in small, frequent chunks—allows the team to process and integrate new information at minimal cost.
More importantly, agile methodologies value authentic human interactions over strict processes. Collaboration between teammates and customers takes precedence over existing documentation and arrangements.
To reap the advantages of agile, it is critical to understand the characteristics of agile software development and which conditions are right for agile. The agile approach is simplest to implement and most effective under the kinds of circumstances frequently presented by software development, but it's certainly not limited to that vertical. Agile methodology is applicable where: there is a complex problem to solve; product requirements are likely to change and solutions are unknown, at least at first; it is feasible to expect close collaboration with and rapid feedback from end users; potentially modular work exists; and creative teams can compete with or outperform typical command-and-control working groups.
Many marketing projects, product development functions, resource allocation decisions, supply-chain challenges, and strategic-planning activities create these conditions. However, these ideal conditions may present less frequently during routine operations such as accounting, maintenance, sales calls, and purchasing. Leadership must determine whether the expected rewards justify the expense and effort of a transition since agile demands behavioral change, training, and sometimes new technologies.