Introduction to Agile Development
Agile software development (Agile) is a collection of software development methodologies that promote adaptive planning, evolutionary development and delivery, continuous improvement, and a time-boxed period of time to complete a body of work. Software development is dynamic by nature, and Agile encourages rapid and flexible response to change. Because adaptability is central to its conceptual framework, teams using this approach are well-equipped to respond to changes throughout the development cycle.
In addition to being a collection of methodologies, Agile software development also promotes a different way of thinking or mindset about how to build things and evolve processes to deliver continuous improvement. Agile facilitates information-sharing amongst teammates, where everyone has a say on processes and practices and decisions are made together as a team.
Concepts of incremental and adaptive software development processes date back as early as the 1950s, with growth and progress from a small vocal minority through the 1980s. It was not until the 1990s, when an assortment of similar lightweight software development methods emerged in reaction to waterfall-oriented methods, that Agile started to gain some traction. The real watershed moment for the Agile movement was the publication of The Manifesto for Agile Software Development in 2001 by a group of 17 software developers, who met to discuss the collection of lightweight development methods, which is now referred to as Agile methods.
Emerging from the Agile Manifesto were the following set of core values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The authors of the Agile Manifesto also agreed upon the following 12 principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within the development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The most popular Agile methodologies used by practitioners today consists of the following: Scrum, XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), ASD (Adaptive Software Development), Crystal, and LSD (Lean Software Development). Also, while Kanban is not considered an Agile development method, it is commonly used in conjunction with Agile methods as a means for increasing efficiency.
When it comes to comparing and choosing which method is best for a team, the idiom "different horses for different courses" comes to mind. The Agile PrepCast has compiled a helpful methods comparison table based on the following characteristics: project size, team size, iteration length, roles and responsibilities, virtual team support, risk mitigation level, customer interaction, pros, and cons.
The most popular Agile methods are Scrum and XP, and they are very much aligned in their practices. The notable differences between the two are as follows:
- Scrum team iterations, which are called sprints, tend to be two weeks to one month in duration. XP teams work in iterations that are one to two weeks long.
- Scrum teams do not allow changes into their sprints, whereas XP teams are much more open to making changes within their iterations.
- XP teams work in a strict priority order as determined by who is serving in the 'customer' role, whereas a product owner prioritizes the backlog items for a sprint. However, the team has the freedom to determine the sequence in which they are developed.
- Scrum is much more focused on management practices and less defined when it comes to engineering practices. XP incorporates common technical practices such as test-driven development, automated testing, pair programming, and more. Scrum teams have more freedom to define the engineering practices they wish to follow, but they often use many of the same practices defined as part of XP.
In the end, many teams ultimately settle into a hybrid Agile methodology that is a combination of Scrum and XP.
Lean software development (LSD), more commonly referred to as "Lean," is based on the principles of lean manufacturing which originated from the Toyota Production System. Lean is based on a set of principles aimed at achieving quality, speed, and customer alignment. This method is commonly adopted by startups.
A key tenet of Lean is to work only on those things that absolutely must be done and to eliminate waste in the form of unnecessary meetings, tasks, and documentation. There are different camps as to whether Lean should be considered an Agile method in and of itself, or viewed as a complementary mindset that helps with the achievement of Agile goals.
Kanban is a model for introducing change through incremental improvements and is complementary to Agile methods. Work is organized on a Kanban board, where work is tracked through various workflow states flowing from left to right. The only management or process criteria introduced by Kanban is "Work in Progress (WIP)," which defines WIP limits for the various workflow states.
If a certain state or status hits the limit, the whole team needs to help clear the filled-up state first before beginning any other work. The Kanban board is ultimately intended to help teams identify bottlenecks and work toward eliminating them in the future.
Agile Tools and Terminology
The following are common tools used by Agile practitioners as identified by Chris Sims and Hillary Louis Johnson, authors of "The Elements of Scrum." The tools are most often associated with Scrum, the most popular of the Agile methods, but are commonly used for other methods as well.
The product backlog is a list of desired deliverables, or to-dos, for the product. This encompasses features, documentation requirements, bugs and anything else of value that must be done as part of delivering a new product or product updates. A best practice for backlog items, commonly referred to as user stories, is to focus on the product capability or the "what" that is required instead of the "how," and to sort backlog items in their order of prioritization.
The sprint, or iteration backlog, represents the team's work tasks for a planned sprint or iteration. A sprint has a finite timeframe usually spanning two weeks to a month, and represents a commitment as to what the team can deliver during that time. Work tasks are commonly broken down into user stories representing the "what" that is being delivered and tasks representing the work required to deliver the user stories.
Burn charts represent the relationship between time and scope. They are a common method for tracking progress on an individual sprint or iteration or across an Agile project that is planned to take a number of iterations. Some teams use burn-up charts to show how much work has been completed over a period of time.
The more common use is the burn-down chart, which shows work that remains. When work or scope is added or removed, the vertical line on the chart moves up or down accordingly to reflect the amount of work added or removed. Aside from scope changes, the burn-down chart will show work being completed and work that remains.
Example burn-down chart:
Agile teams will use some form of task board to represent work that is to be done during an iteration. The visual board is used to facilitate Agile planning meetings, reflects the prioritization of tasks, and aids with brainstorming how tasks will best be executed. The board clarifies the work that needs done as part of the iteration backlog, helps with managing team capacity and assignments, and prevents tasks that must be completed from being lost or overlooked. This is where Agile teams often opt to use a Kanban board: to manage tasks through the different workflow states.
Agile teams often have different roles with different names, depending on the methodology used. The common Agile roles include the following:
- Team lead, scrum master (Scrum), team coach or project lead
Acts as the coach responsible for facilitating and guiding the team, obtaining resources when required, and removing impediments that keep the team from doing their work.
This role often encompasses the soft skills of project management more than planning and technical skills, which are often left to the team as a whole. It is important to note that this person is not necessarily the manager of the team; rather, this role should reflect knowledge and responsibilities over rank.
- Team member
Responsible for the creation and delivery of the project. The team members will normally be comprised of developers, QA, and documentation. They are responsible for planning, design, development, testing, and project delivery.
- Product owner (Scrum), on-site customer (XP), active stakeholder
Represents the voice of the customer and is responsible for the prioritized backlog and maximizing the return on investment (ROI). Part of the responsibility of this role includes documenting user stories or requirements for the project.
Represents a broad category of people who can be users, managers of users, operations, support, portfolio managers, other Agile teams with dependencies, executive team, investors, and more.
In addition to these common roles, Agile teams will sometimes have extended cast members, who are called upon to provide technical or domain expertise for certain specialized skills that may not be present amongst the team members.
Likewise, it is not always reasonable or fair to expect product owners to be so-called experts on every facet of a product or domain. This is when they call in domain experts to assist the team with certain requirements.
Improving how teams innovate is a continuous journey, and new methodologies will certainly emerge over time, as well as best practices for software development. Teams will find that different approaches are available and work better for them. But the impact of Agile on product development cannot be understated, with its focus on the customer and the art of collaboration.