What is Agile Development?
Agile Development is one of the most recognized and widely-used software development approaches globally. It is credited with changing the world of software development and practically laid the foundation for programming as we know it today. Agile’s impact on development was so profound that in 2007, just six years after the concept was formally enunciated in the Agile Manifesto, IBM said of Agile Development: “Learn about it … If you are a manager of technology at any level, this is your responsibility as well as a survival necessity.”
Over two decades after its introduction, Agile has grown in significance. As reported in the 15th Annual State of Agile survey, Agile is the preferred software development approach for 95% of respondents, and those who do not already practice the approach see it as a top priority.
Despite its popularity, Agile can be an elusive concept for beginners. This blog explains all you should know about Agile software development, including its history, principles, and processes.
What is Agile Development?
The first step towards unpicking Agile is understanding that it’s not a methodology – it’s a mindset.
The Agile Alliance, established by the authors of the Agile Manifesto, describes Agile simply as “the ability to create and respond to change.” It is a work mentality, or mindset that prioritizes action and flexibility in the face of uncertainty.
The name Agile itself represents “the adaptiveness and response to change” that underlines the mindset. Therefore, instead of waiting for perfect conditions to progress, Agile says work with what you know, do what you can with what you have, and be nimble enough to change quickly where necessary.
While this idea seems simple, it has created a revolution in how software development teams, and even organizations in other industries, work.
The Agile mindset supports fast learning, short iterations, and rapid releases. Teams are encouraged to “fail forward” and learn from each iteration in an environment of open communication, trust, and close collaboration.
But why did Agile become necessary, and what did it set out to change?
History of Agile Development
Agile emerged in response to the dissatisfaction about traditional software development and project management practices. Before the formal introduction of Agile, organizations laid emphasis on procedure and documentation within their work processes. Everyone worked in a tidy line and projects only progressed when each stakeholder in that line completed their work.
Although this method was organized and effective (many organizations still use it today), it was slow and ultimately bad for business. Working in this way encouraged siloes in internal departments and left projects vulnerable to project overruns and delays.
The move towards Agile started from the mid-nineties when certain practitioners in various organizations began to question traditional programming methods. They began to experiment with new ways of working, often by intermingling old and new ideas, all targeted towards finding faster and smarter models that delivered greater end-project value.
Frameworks such as Extreme Programming, Scrum, Dynamic Systems Development Method, and Feature-Driven Development all started to appear during this period. Because these frameworks developed in an organic manner, they included different practices that might have ended up confusing the new and flexible approach to software development that was emerging. Hence, the Snowbird, Utah summit of 2001.
A group of 17 practitioners came together at the summit to determine if they could find a common ground between the different developing approaches and a consistent way of describing them. While they didn’t agree on everything, they came to a basic understanding that forms what is today called the Manifesto for Agile Software Development.
The Agile Manifesto
Comprising just 68 words, the Agile Manifesto, and the 12 Principles that followed, encapsulate the core of Agile Software Development.
To be clear, Agile does not prescribe a “silver-bullet” for the challenges of traditional software programming. That was not the intention of its inventors. In fact, the Agile Manifesto was purposely kept short because it doesn’t claim to have all the answers.
Rather, Agile provides a philosophy on which teams can build with methodologies that help them unlock real value in their projects without the limitations of traditional methods. To underscore this, there are four key values that uphold the Agile mindset as outlined within the Manifesto:
Individuals and interactions over processes and tools
No matter how you see it, it’s people who create software, not lengthy procedures or computer programs. Therefore, an open, honest, involved, dynamic, and cross-functional team will build better software than a dysfunctional one.
Further, without the restriction of pointless processes and paper pushing, the team can be unleashed to create real value driven by their collaboration and innate abilities.
Working software over comprehensive documentation
Documentation, otherwise called bureaucracy, may be good for compliance and oversight. The problem, however, is it can often stifle innovation. Instead, with Agile, teams do as little documentation as possible, choosing to focus instead on the project.
Also, rather than take projects as a whole, Agile emphasizes functionality. For example, while a house that is 70% completed likely isn’t livable, an Agile project that is 70% done is operable. It is a finished product that can be shipped and enjoyed by end users.
Customer collaboration over contract negotiation
Per traditional models, the customer was rarely involved unless during contract negotiations and at the end of the project during shipment and adoption. Agile emphasizes ongoing customer collaboration instead. It understands that changing requirements are a fact of software projects.
So, rather than spend all that time bickering over what changes are acceptable or not, Agile welcomes collaboration that ensures a happier customer and a better product.
Responding to change over following a plan
Finally, the Agile Manifesto expressly incorporates the importance of nimbleness and adaptation to change. As anyone who has ever participated in shipping software knows, requirements change often in unexpected ways.
While such frequent changes might cripple a traditional project or inflate budgets, or obliterate due dates, Agile provides a mindset that appreciates and is primed to respond to uncertainty.
Agile’s 12 Principles
While the 12 Principles were not a part of the initial Agile Manifesto, they build on and better explain the philosophy behind Agile. The principles are as follows:
- Satisfying customers through early and ongoing delivery of valuable software
- Welcoming changing requirements, even late in development, because Agile channels change for the customer’s competitive advantage
- Delivering functional software often, within the shortest possible timeframe
- Assembling teams of business people and developers who collaborate daily
- Building projects around motivated individuals, and giving them the support and environment they need to work
- Conveying information in an efficient and effective manner through face-to-face discourse
- Measuring progress by functional software releases
- Promoting sustainable development so teams and users can maintain pace indefinitely
- Prioritizing technical excellence and good design
- Maximizing the amount of work not done
- Acknowledging that the best work comes from self-organized teams
- Allowing space for reflection at regular intervals where the team tunes and adjusts to become more effective
These principles, along with the Manifesto, create a clear picture of what Agile is and how it aids teams to work better. As you would observe, while Agile was created by software developers, its principles are inter-disciplinary. Applied properly, these principles can help most teams function more effectively and create greater value.
That said, we now have a solid foundation to proceed to the next section that describes Agile software development, its approach, and processes.
What is Agile Software Development?
Agile software development is an iterative approach to programming that utilizes cross-functional teams to rapidly deliver ongoing value to customers. As the Agile Alliance explains, it is an umbrella term that covers the frameworks and practices based on the values expressed in the Agile Manifesto and 12 Principles.
Consequently, Agile software development isn’t a programming framework or methodology in the sense of Scrum, Lean, Kanban, or other methods. Instead, it is the core philosophy that guides software development under those frameworks, giving teams the structure and tools to proceed as they see fit.
Agile coaching company Atlassian explains it best when they say, “Agile isn’t defined by a set of ceremonies or specific development techniques.” Instead, “it is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement.”
Agile doesn’t specify month-long sprints or standup meetings. Rather, it lays out a set of core values that emphasize flexibility and collaboration. How each team chooses to implement those values – whether with Scrum, XP, or some other method – is entirely their decision.
In this sense, Agile software development is not just about creating computer programs that provide real value. It’s also a project management philosophy that helps break large tasks down into manageable chunks so work can be completed in functional increments.
That’s why Agile has found such acceptance in fields outside software and computer programming. Today, the Agile Alliance has ongoing collaborations with the Project Management Institute and the International Institute of Business Analysis to formally incorporate Agile philosophies into these practice areas.
Agile versus Traditional Project Management
Before Agile methods took center stage, traditional project management techniques were the go-to in software development. Also called the “Waterfall” approach, these techniques favored a fire-line model. Teams worked on projects in stages, with each stakeholder completing their task before “tossing over the wall” to the next team and so on until the project reaches the customer.
Agile incorporates an entirely different approach to this. Understanding the core differences between Agile and the Waterfall approach will help clarify what Agile does differently.
Agile builds in increments versus as a whole
By traditional programming methods, software development proceeds in a linear fashion. It’s usually requirements > documentation > planning > design > development > testing > debugging > release > support. The project is built from the ground up and is only complete when the last stage concludes.
Compared to this, Agile supports incremental builds. Teams do not have to plan and wireframe the entire project from the start, mostly because trying to do this will often delay and complicate planning. Instead, teams start small and work to deliver the most functionality within the shortest time possible.
Then, they reflect on their work, learn from it, and start working towards shipping the next improved iteration within the shortest timeframe. And on it goes. The value of this method is it allows teams to work fast but smart, drawing on active feedback from the customer so each release is better than the last.
Agile does planning throughout versus done all at once
Planning is performed continuously during Agile projects, mostly because teams recognize that change is constant and disruptive during programming. Rather than try to plan all at once, teams plan some, then launch into action. Since the planning is not comprehensive or absolute, there is room to course-correct as needed.
Most Agile frameworks incorporate some element of continuous planning into their method. For instance, Scrum has daily standups and a pre-sprint planning meeting that comes at the start of every iteration.
Comparably, traditional programming tries to set the tone from the start so everyone is dancing the same tune from start to finish. The obvious disadvantage here is that every change sets the plan back a little. So, by the end, the plan might be unrecognizable or it could end up delivering something the client doesn’t want.
Agile delivers products over time versus all at once
Agile encourages small releases, compared to the traditional model that looks to deliver projects in one big shipment. The reasoning here is while so-called big bang shipments can be great for PR, they are ultimately costly in time and money terms.
As a result, planning takes longer with traditional programming and so does development. Big releases also make it harder to catch bugs – by the time you notice something is off, you are already plugging in the final release and hoping it runs smoothly.
With small releases, it’s easier to spot problems and resolve them quickly without costing the client time and money. Likewise, by the time the final release occurs, the product will have been scrutinized tens of times and the team can be satisfied it has delivered the highest quality.
Customer sees value quickly versus waiting until the end
Agile can begin to deliver value in as little as two weeks or a month, depending on how long each iteration takes. More significantly, each iteration is a fully functional feature that can support immediate use from end-users.
In contrast, traditional methods only show the customer what their money buys at the end of the process. The risk is that the customer’s needs, expectations, or priorities may have shifted by this point.
Perhaps Agile’s biggest advantage is it actively involves the customer throughout the process. He or she essentially builds the product with you and knows exactly what they’re going to get by the end of the process.
Agile wants changes versus discouraging changes
We’ve mentioned how Agile treats change above, but it bears additional emphasis here. Traditional software development models do not easily accept change. These models find change difficult because there is usually an overarching plan with which the whole team works.
The Agile Manifesto’s authors were most perplexed by this because change is such a common phenomenon in software projects. Compared to the traditional approach, Agile accommodates uncertainty and change in its philosophy. There’s a recognition that teams do not know it all, hence the need for flexibility and optimism in the face of change.
Agile changes the traditional project management triangle
With traditional project management, the scope of each project is fixed while time and cost are estimated. Clearly, that’s not a balance that favors the client. They won’t be too pleased to hear that their project could overrun budget and planning but won’t accommodate revisions without a change order.
With Agile, however, time and cost are fixed while it is the scope that is estimated, or variable. In this sense, Agile is a promise to the client that they will receive a quality product on time and within budget, regardless of the changes that development may necessitate.
However, it’s necessary to point out that this is not an invitation for clients to substitute one project for an entirely different one under the guise of a revision.
The Agile Approach
Overall, Agile works to equip teams with an environment that encourages value-driven development in a collaborative, change-ready process. Here’s a summary of Agile’s approach to software development:
- Welcoming change
- Working in small value increments
- Using build and feedback loops
- Learning through discovery
- Value-driven development
- Failing fast with learning
- Continuous delivery
- Continuous improvement
The Agile process
With all the fundamentals sorted, it’s time to consider what the Agile process looks like. Basically, how do teams do Agile?
The straight answer is it depends on what method you choose to adopt. As we’ve mentioned earlier, Agile software development does not dictate any specific programming methods or procedures. There are, however, several methods incorporating the Agile philosophy that your team may adopt. These include:
- Extreme Programming (XP)
- Lean Programming
- Dynamic Systems Development Method (DSDM)
- Feature-Driven Development (FDD)
While some of these methods include specific instructions on how teams should operate and be structured, it’s worth noting that these methods are prescriptive at their root.
The goal of Agile is to help your team work faster and more efficiently while delivering high quality products in manageable releases. Whether this means implementing your own variant of Scrum or a hybrid of these methods, Agile leaves that to you.
Ultimately, Agile doesn’t want to box your team into an immutable methodology. Rather, its aim is to unleash your team, giving them the tools and structure to find better ways of software programming.
That said, certain concepts are central to how Agile works. They include:
- Team: The team is at the core of the Agile process, consisting of not only developers but also the customer or their representative and a leader or coach. It is typically small, cross-functional, and self-organizing. Team members may have full and part-time roles, although the majority will be full-time.
- User Stories: User stories are functional increments of work written by the team in conjunction with the customer. Each story describes a feature or features that contribute to the value of the final product.
- Personas: On some projects it may be necessary to create detailed user personalities, such as where user experience is key to project outcomes. These personas help the team deeply understand who the end user is and how they might interact with the product.
- Daily Meeting: Agile emphasizes continuous planning, and the daily meeting furthers this approach. The team meets at the same time every day to briefly discuss the project and bring everyone on the same page in terms of achievements and obstacles.
- Incremental Programming: Agile favors an incremental development strategy combined with small releases. Working this way, each successive version the team delivers is usable and builds on the previous version by adding greater functionality.
- Iterative Development: The Agile process intentionally makes space for repeating software development activities or revisiting the same work product with a view to continuously increase the quality of the final product.
- Milestone Retrospective: Team members periodically review their work over a time-boxed period to analyze progress, identify shortcomings, and learn from their actions so they can improve over the next iteration.
Benefits of Agile Development for teams and organizations
- Faster time-to-market: According to the 9th State of Agile Survey, the most reported benefit of Agile was its encouragement of “accelerated product delivery.” Since it gets teams working as quickly as possible using short iteration cycles, Agile helps focus effort on their real work and deliver value faster.
- High quality product: When programming is divided into consumable bits, it becomes easier for teams to test and review each release. With Agile, teams can rapidly find and fix bugs, leading to a better final delivery.
- Fully collaborative process: Customer feedback and satisfaction are central to the Agile process. Using tight feedback loops, teams actively involve the customer during development, letting them quickly determine what features are satisfactory.
- Change-ready development: Agile accepts change and allows for it during development, thereby ensuring that projects will not be frustrated or setback due to evolving requirements.
- Risk mitigated delivery: Because Agile emphasizes continuous development and delivery, customers can rest assured that the final solution is complete and fit for purpose.
Despite its benefits, Agile is not a “Goldilocks” strategy. Some of the potential disadvantages of the philosophy are as follows:
- Agile ignores the cost of change: How much change is too much? That’s often the controversy with Agile. Every changed requirement affects the project in some way, creating cost and resource overruns.
- Might not work for large organizations: These organizations typically have extensive compliance and documentation processes that might make Agile unsuitable for them.
- Will often require training: One of the most common reasons why Agile projects fails is due to a “lack of experience with Agile methods,” says the State of Agile report.
Let us help you maximize your potential using Agile
Agile methodology has transformed IT. With its ability to improve quality, flexibility and productivity, as well as its ability to enhance overall customer service, Agile has certainly proven its worth. Widely used in software development, it is now permeating every other function in every type of organization. For 25 years, i3solutions has been adapting our Agile methodologies to deliver the highest possible business value to our customers. Contact us today if you need guidance on Agile or are looking for a solution using these proven Agile methodologies.
Leave a Comment