The companies that are the most successful embracing agile software development understand that agile is not something that companies do; instead, agile is something that companies become. It takes a long time to become agile, but the payoff is proven. Organizations across various sectors, from healthcare to banking, from the public sector to media, are actualizing the immense value that agile software development brings: better quality products, faster time-to-market, and higher-quality decision making.
Much has been written about agile mobile app development: its tools and methodologies, the benefits of cross-functional teams and short iterations, and the culture necessary to enable success. However, it’s essential to think about the fundamental characteristics of agile development and how they apply to the execution of practical software development projects.
The following article details the ten core characteristics of agile software development.
1. Fixed-Length Sprints
Agile software development methodologies have two central delivery units: sprints and releases. A release contains several sprints, each of which is essentially a small project alone. Feature, maintenance, and enhancement requests are all organized, estimated, and prioritized as sprints before being assigned to a release.
Development projects advance on a cadence of predictable fixed-length sprints. The stable delivery of new, working, and tested features at the close of each sprint supplies the feedback that allows the product team to keep the project and system on track. By using fixed-length (or time-boxed) sprints, product teams can effectively answer crucial questions like:
- How much work did the team accomplish during the last sprint compared to the predicted amount?
- How much work did the team complete compared to the sprint before?
- How many features are feasible to complete before this sprint’s deadline?
The core benefit of fixed sprints is that the entire team remains focused on a few prioritized goals, rather than attempting to understand every single detail of the system. With highly visible results (both positive and negative) available from each previous sprint, the team can get the most out of the build-measure-learn process and identify areas to refine the process for the next sprint. Teams are more likely to prioritize features properly and less likely to fall victim to scope creep. Each team member helps each other stay focused on delivering the highest possible business value per unit of delivery.
2. Sprints Always Deliver Working Software
Delivering tested, accepted, and working product features at the end of every sprint are an agile software development team’s first measure of progress. Working features allow teams to improve collaboration, increase project visibility, and answer customer feedback strategically. Working software provides concrete evidence that the project is on track.
Throughout the first few sprints of a new project, the team may not deliver a large number of features. Still, as the project progresses, the team typically finds a predictable delivery cadence. As the system develops, the user experience (UX) design, architecture, and business objectives are continuously assessed. At every stage of the project, the team works to merge the latest input from customers, users, and other stakeholders to arrive at the most valuable business solution. Sprint by sprint, everyone involved can see whether the project is progressing to meet the most valuable business goals accurately. Repeatedly measuring progress against actual working software helps instill a level of confidence in engineers, customers, managers, and other stakeholders that can’t be matched by traditional waterfall methods.
3. Value Is A Priority
Agile software development adheres to diligently delivering business value early and consistently, as measured by tested, accepted, and working software. For this reason, product features are the central unit of planning, tracking, and delivery. From sprint to sprint, the product team measures the number of functional and tested features with each release. While other documents and artifacts are sometimes necessary, working features are of topmost importance. This approach to software development, in turn, requires that each feature is small enough to release in a single sprint. Feature prioritization is essential for reaching the goals of each sprint, as well as delivering business value.
4. Ongoing Rolling Wave Planning
It’s a misconception that agile methodologies rule out upfront planning; however, agile methods indeed dictate that any upfront planning be held accountable for depleted resources. More importantly, agile methods insist that planning be ongoing throughout the entire project. Any plan in agile software development must repeatedly demonstrate its validity.
At project kickoff, the product team does just enough planning to start the first sprint. This method of preparation is referred to as rolling wave planning (or just-in-time planning), and it is the practice of delaying product decisions until the team is in the best position to make them. Again, this doesn’t mean the team won’t plan; instead, the team makes more informed and actionable decisions as the product evolves, and more knowledge becomes available. Iteration is key to rolling wave planning. Imagine each sprint as a small-scale project that receives “just enough” of its plan. At the start of a sprint, the product team identifies a set of features to implement and estimates the technical requirements for each feature. This planning process repeats for each sprint and release cycle.
As it turns out, agile software development projects contain a lot more planning and better quality planning compared to waterfall methodologies. One of the significant pitfalls of waterfall methods is that the project reaches completion, and the product delivers on all the technical requirements, but not what the stakeholders need from a business perspective. These shortcomings happen because waterfall methodologies don’t take into account new information or user research as the project progresses. Rolling wave planning is grounded in factual, accurate, recent data. It enables agile processes to allow flexible priorities and scope changes, within reason, to accommodate the unavoidable ways in which business needs and market demands continuously evolve.
5. Multi-Level Planning
Rolling wave planning is much more effective when it occurs on two levels:
- On the release level, the team pinpoints and prioritizes the features the product must have, would like to have, and can do without by the release deadline.
- On the sprint level, the team chooses and plans for the next series of features to implement by priority. If certain features are too complex to be appropriately estimated or completed within a single, the team breaks them down further.
The number of levels of planning depends on your project and the methodology you choose. For example you can define 5 levels of planning for project with 1 year duration.
When features are prioritized and planned for a sprint, they are split into their technical tasks.
The rolling wave planning approach to software development is more manageable and accurate than any broad, upfront planning strategy because it positions the level of information available to the product team in line with the level of detail necessary at the time. It’s a waste of time trying to plan at a level of detail that the available data doesn’t support.
6. Relative Estimation
Many agile software development processes use the application of relative estimation for product features to expedite planning stages and eliminate complexity. Rather than estimating features against a range of unit lengths, the team selects a small number of relative estimation categories and estimates every feature against the terms of the categories. For example:
- 1 to 5 days
- 1, 2, or 3 story points
- 4, 8, 16, 40, or 80 hours
The notion of relative estimation prevents teams from wasting time debating the particulars of feature estimation. There is a significant amount of time and effort saved by using relative estimation, and the process often outweighs the costs of imprecise estimates. Just as with every other aspect of agile software development, product teams improve relative estimation as the project progresses and refine estimations successively.
If any feature overreaches the agreed maximum estimate, then it is separated into multiple features. Again, the features that emerge as a result of the separation also need to be completed in a single sprint. So if the product team establishes that features should not exceed 16 ideal hours, then any feature that exceeds that timeframe needs to be broken down. Using this process normalizes the granularity of product features: the ratio of feature sizes is never immeasurable.
7. Features Begin At High-Level
Rather than spending an extended period of time detailing feature requirements before development, agile software development projects often prioritize and estimate features, and refine the details on an ongoing basis. In most cases, the discovery phase of a project adheres to a design thinking framework to quickly produce a project timeline, documented product requirements, a product vision statement, user personas, and a list of marketable features. The features for a sprint become more detailed with input from customers, testers, and developers working together. No feature is described in detail until it’s prioritized for a sprint.
8. Continuous Testing
There is nothing riskier than postponing all testing until the end of a project. With continuous testing, product teams deterministically measure progress and prevent defects. This approach to testing dramatically reduces the risk of failure late in a project. Many waterfall projects collapse when they uncover, in an incessantly late project’s test-and-fix phase, that the architecture is terminally flawed, or particular components of the system can’t be integrated, or features are unusable and entirely useless. All of these defects are discovered too late to make changes. By practicing continuous testing, product teams can avoid both the risk that these problems will happen and the constant apprehension of the worst possible outcome.
9. Continuous Improvement
In agile software development, product teams continuously refine both the system and the project. By reflecting on progress with sprint retrospectives using both hard metrics like running and tested features and more subjective data, product teams can adjust feature estimates and project plans accordingly. The continuous improvement aspect of agile software delivery becomes particularly important at the close of significant milestones within a project. Sometimes problems can arise with sprint planning, or with the build and integration process, or with knowledge transfer, or any number of issues. It’s essential to keep finding ways to adapt the process and to continue delivering as much value as possible per unit of time to the customer, the team, and the organization. Agile software development methodologies always mature and evolve like a living thing.
10. Small, Cross-Functional Teams
Small agile development teams are proven to be much more productive than more substantial teams. Typically, these small teams are known as squads. Each squad has no more than eight members, is cross-functional, plans together, and sits together. The benefit of squad-based agile development is teams work together to identify how to use each other’s skillsets best and mentor each other. Teams transition away from a top-down management approach, and each member helps do whatever needs to get done to complete the sprint. Individual team members begin to derive satisfaction from being a member of a productive and efficient team.
Actualizing Success In Agile Software Development
Specific practices can vary across different agile methodologies, but there are common characteristics that mark the success of an agile software development process. Fundamentally, actualizing success from agile software development is through early and frequent iterations. From sprint to sprint, the product team uses continuous planning to define and redefine the scope of the release plan as new information presents itself and requirements change. The sprint plans become more accurate as the team learns more about velocity (the measured work accomplished per unit of time). By implementing the above characteristics into the software development lifecycle, product teams increase the likelihood of delivering successful mobile products.
