In the 1970s, spurred on by the changing marketplace and the rapid advancement of technologies and requirements, teams around the world started experimenting with approaches to software development that would move away from the “established” practices such as the waterfall model.
In 2001, seventeen of the most prominent developers from teams that have been experimenting with new approaches got together and decided on a number of principles that have since been used to define Agile software development, collected in the Agile Manifesto.
The basic idea of Agile is to enable more adaptable and responsive software development where people and collaboration are more important than tools and processes, where customers stay involved, where working software is more important than documentation and where the value is delivered iteratively.
Both before and after the formalization of the Agile approach, individuals and teams developed and have been developing various methods, methodologies and frameworks to best apply the principles of Agile which is why there are so many approaches to doing Agile out there. Today, we will be looking at the five most popular ones:
1. Extreme Programming
4. Feature-Driven Development (FDD)
5. Disciplined Agile Delivery (DAD)
Extreme programming (XP) is a software development methodology which was developed in the 1990s as a response to the growing popularity of object-oriented programming and the need for faster software releases. The two most important figures in the history of XP are Kent Beck and Ron Jeffries, but other people contributed to the methodology as well.
The methodology got its name from the practice of taking the essential parts of the software development process and amplifying them to the extremes while leaving out everything else. For instance, if testing the code is a good thing, then why not do it all the time?
The main goals of XP are to deliver high-quality software in the most productive way possible and to reduce the costs of changes in requirements by introducing short development cycles, starting from the point of view that changes will happen and need to be planned for.
XP recognizes four basic activities that comprise the development process – coding (no code, no product), testing (taken to the extreme), listening (to the customers), and designing (minimizing dependencies).
5 XP values perhaps best describe the advantages of this methodology, emphasizing the importance of communication (over documentation), simplicity (building from the simplest solutions), feedback (from the system, customer and team), courage (being comfortable with refactoring) and respect (ensures a quality product and high levels of motivation).
Extreme programming also entails a process with clearly defined phases, roles, and responsibilities, aimed at living up to the values and enabling meeting of goals set for this methodology.
If everything goes as planned, XP enables quick releases and enhanced collaboration with customers, delivering great business value. On the developers’ side, XP encourages a flat structure where knowledge is easily disseminated and where no one is asked to do more than they feel comfortable with.
Despite what you may have read about Scrum being a methodology, it is actually a framework within which teams and organizations can handle various complex problems that require quick adaptation. The framework was first formally presented in 1995 and since then, we saw the formation of the Scrum Alliance and the release of a public document called The Scrum Guide.
Scrum emphasizes a flexible, holistic approach to developing software, aiming for small iterations that allow for easy adaptability which reduces waste and maximizes the productivity of teams using this framework. When adopted correctly, Scum also leads to spreading of knowledge within teams (3 to 9 developers) and their incremental improvement.
This is all made possible thanks to the empiricism-oriented nature of Scrum where transparency, inspection, and adaptation lead to improving the process and the end product.
Scrum features precisely defined roles, events, and artifacts which support an also clearly defined process aimed at providing the most value possible. In practice, Scrum revolves around scrum sprints (one to four weeks in duration) during which a demonstrable, usable increment is produced by a self-organized, cross-functional team. These short iterations ensure that value is constantly being added and that potential changes in requirements can be addressed in a timely manner.
One of the main reasons why Scrum is among the most popular approaches to Agile is that it provides demonstrable value for the customer. When done correctly, it also creates teams that are tightly-knit and that improve over time. The popularity of this framework can also be seen in the abundance of scrum software that is available today and that can provide great support to scrum teams.
Kanban is a work management method whose primary goals are to balance out available capacity with demand and provide a more efficient way to deal with bottlenecks which are a part of every working system.
Kanban method actually dates back to post-WWII Japan when Toyota introduced a new way to improve the productivity of its factories. Nowadays, however, it is mostly used in software development where its visual nature and its other principles make it perfect for that use.
Kanban is based on kanban boards (the exact visualization method does not have to be aboard) where work and workflow are represented clearly. These boards are used to organize workers across the team or teams (or entire organizations), to expose operational problems as early as possible, stimulate collaboration and reduce waste that emerges from multitasking.
Kanban boards are organized in three primary columns – To Do, In Progress and Done. These three columns can be subdivided and organized in a way that will best fit the situation at hand. One of the most important characteristics of kanban boards is that each column has a Work in Progress (WIP) limit. In other words, once the limit is reached, no more items can be added to the columns. This prevents overwork, encourages focus and improves the overview of the situation.
Kanban does not require an organizational change in the same way that Scrum does which makes it less disruptive. Some teams choose to combine Scrum and Kanban, taking the best out of both these approaches. This is called Scrumban.
Feature-driven development (FDD) is a software development method which blends a number of industry best practices (object modeling, development by feature, inspections, regular builds, individual class ownership, etc.) and combines them in a cohesive whole.
The method was originally devised by Jeff de Luca (with significant input from Peter Coad) for a specific project for a Singaporean bank in the late 1990s. Other developers and experts contributed to the method since, building on the common-sense, no-nonsense approach originally employed to define FDD. The ultimate goal of this method shares this simplicity, being defined succinctly as delivering working software on time and according to customer requirements.
The FDD method entails five basic activities that are further broken down and which ensure iterative delivery of a working product, i.e. software. These five activities entail development of the overall model in cooperation with the customer, building of the feature list, planning by feature, designing by feature and building by feature.
It is important to point out that features are very clearly defined, must have a demonstrable business value for the customer and their production cannot last for more than two weeks (if it does, they are broken down in smaller units which then become features).
FDD also has clearly defined roles which ensure people understand their responsibilities, as well as milestones which provide insight into how the project is moving alone without the need for custom reports which would be a waste of time.
One of the main advantages of FDD over other methods is that it is easier to apply to larger projects and organizations. If you want to read a comprehensive article on how a company has adopted FDD, check out this great article by Martin Bauer on SitePoint.
Disciplined Agile Delivery
Disciplined agile delivery (DAD) is another agile framework and it is somewhat more recent than the ones we already covered. It is actually considered to be a second-generation agile method that takes a number of elements from Scrum, extreme programming, agile modeling, and others and combines them into a comprehensive process decision framework for delivering incremental and iterative software solutions.
DAD was developed by Scott Ambler at IBM between 2006 and 2012 and it has already garnered quite a bit of attention.
It is probably safe to say that DAD takes the Scrum framework as a starting point and builds on it, adding recommendations and guidelines that can guide the process in its entirety, starting with project inception, proceeding through construction (Scrum) and ending with the transition phase.
Among the most important concepts that DAD adds to the “older” agile methods are the following:
1. Emphasis on consumable solutions which can entail stakeholder involvement that goes beyond just adopting the product.
2. Enterprise awareness where teams are more aware of the entire enterprise, the possibilities this opens and the responsibilities it entails.
3. Adoption of explicit governance strategies which entail more oversight and involvement than other, somewhat idealistic approaches.
4. Goal-based approach to solving problems where no specific solutions for certain issues are prescribed and where specific situations should guide the decision-making process. This, ideally, makes DAD a more scalable method, one that can work for small teams, as well as entire organizations with many large teams.
The most important thing to take away from this article is that no agile software development method is the right one. There are teams that will thrive in Scrum while they might struggle with Kanban and vice-versa. There are approaches that will work better for large teams, while others will be more beneficial for small units.
This is just a brief intro to these various methods and our hope is that it will inspire you to learn more and find out why Agile is so ubiquitous in the software development industry.