7 Types of Agile

Iterative and incremental development methods can be traced back as far as 1957, but few have taken hold as frameworks for innovation more firmly than Agile. Agile, which advocates adaptive planning, evolutionary development, early delivery, and continual improvement, has proven itself to be quite agile in its own incremental and evolutionary adaptation. While most project managers think scrums and sprints when thinking about Agile, there are actually numerous hybrids, spinoffs, and variations. Here are our favorite 7.

Scrum

Scrum is what most people think of when they think of Agile. In Scrum, you set up a product backlog where features are broken into User Stories and then prioritized. Development usually takes place in two-week sprints, at the end of which there is a product release or demo drop. Estimation sessions, retrospectives, and daily standups round out the processes for this popular approach to Agile. A Scrum Master polices the team to make sure the process is enforced. 

Pros

• Familiarity 
• Measurable results 
• Well-suited to projects with changing business requirements 

Cons

• Process can breakdown without full buy-in from stakeholders and development team. 
• Not suitable for ‘stop and go’ teams that work when they have availability. 
• Can create unnecessary pressure when unexpected roadblocks derail estimations.

Kanban

Kanban isn’t tied to sprints like Scrum. Instead, features sit in a backlog until the product owner or designer is able to refine the story and prepare the design assets. Only then does it move into development, followed by testing and then deployment. Kanban is similar to Waterfall in its linear approach and is great when teams can’t allocate a consistent amount of resources to a project. 

Pros

• Great for teams with shifting resources 
• Easy to ramp up/down production

Cons

• Information can be lost in translation. 
• Setbacks occur when tickets need to go “backward” in the cycle and resources are not readily available to address. 

Rapid Application Development 

In RAD, the focus is on prototyping for one of two benefits - to explore product viability or to better understand the technical limitations of a system. 

In the former, rapid prototypes are designed and developed with as minimal effort as reasonably possible. The idea is to get lightweight, testable versions of features into users’ hands as quickly as possible to see how users interact with the product. If they perform well, the product is expanded. If not, it’s canned and the next prototype is developed. Often many prototypes in parallel can be built and tested. 

In the latter, prototypes are built to better understand how a system or technology works. Sometimes, teams create 2-3 prototypes on competing platforms to better understand the strengths and weaknesses of each. 

Pros

• For product development, you get more shots on goal, thus more chances to succeed. 
• Less time debating what could work, and more time seeing what does work. 
• For technological research, you learn the strengths and weaknesses of various platforms before you invest months or years developing on them. 

Cons

• By nature, you build unstable, buggy iterations with minimal feature sets. 
• Not good for well-defined products or situations where stability, security, or scalability are the top priorities. 

Extreme Programming

XP focuses on taking a few principles of Agile and implementing them to the extreme. For example, code reviews are a common practice in Agile software development. In XP, peer programming is employed so that code is reviewed constantly and in real-time. Test cases and unit tests are common in Agile. In XP, developers write unit tests on even the smallest section of code BEFORE they start coding. XP is built upon the notion that coding is the most important part of the software development process, so it should be done early, often, and as simply as possible. Changes are not only to be expected, but should be planned for and embraced. 

Pros

• Fast results, clean code, and works great when requirements are poorly defined. 
• Developers feel empowered and safe

Cons

• Strict requirements can make it untenable. For example, teams must work in the same location and the customer must be constantly available. 
• Can cause organizations to pull the trigger on software projects without carefully considering viability pre-build. 

Adaptive Software Development

ASD, like RAD, actually came about before Agile and was designed as an alternative to Waterfall. ASD is characterized as mission-focused, feature-based, iterative, timeboxed, risk-driven, and change tolerant. In ASD, cycles of Speculate, Collaborate, and Learn are repeated for continuous learning and adaptation of a project. 

Speculation comes from the idea that planning is futile and assumptions are most likely wrong. During speculation, the project is initiated and adaptive cycle planning is conducted based on project initiation information - the customer’s mission, project constraint, and basic requirements. 

Collaboration is based on work cycles that balance the predictable parts of a project (environment, team) and the uncertain factors (technology, requirements, timelines). 

The Learning cycle challenges stakeholders and developers alike to gather knowledge from the short iterations of design, build, and test. 

Pros

• Loose framework that allows teams to customize to a variety of situations. 
• Phases can be helpful for separating projects into planning, building, and testing.

Cons

• Not suitable for teams who aren’t already familiar with Agile principles and thus need more guidance. 

Dynamic Systems Development Method

DSDM was born from RAD, but sought to incorporate more guidelines while also giving it the flexibility to be used as a project management framework, rather than purely a software development framework. Like all Agile frameworks, its core principles include iterative and incremental approaches that embrace continuous user/customer involvement. Unlike many Agile frameworks, DSDM focuses on the PEOPLE rather than the software. It believes most projects fail because of people problems, not technology problems, so it uses a lot of constraints around team formation. There are as many as 12 roles that need to be filled on a DSDM team. There is also a dedicated and powerful Project team that has to be able to make important decisions independently. 

Pros

• The people-focused approach is ideal for highly organized and hierarchical organizations. 
• Strict adherence to roles makes it easier to swap out vendors or other team members as needed. 

Cons

• Requires a lot of people to fill all of the roles. 
• Not ideal for flat teams or teams that want buy-in from all around.

Test and Behavior Driven Development

You get a twofer here - TDD and BDD, which are variations of each other. In TDD, each new feature begins with writing a test. Unlike in typical agile, where unit tests might be written AFTER writing the code, in TDD the test is written before the code, making the developer focus on the requirements before they begin coding. It’s a style of coding designed to promote simplicity in features and confidence in developer abilities. 

In BDD, focus is placed on the actual language used to describe the feature or functionality. By adhering to strict domain-specific language, it forces both non-technical and technical stakeholders to agree on language and descriptions that can then become ubiquitous. Like writing tests before coding, strictly defined acceptance criteria are agreed to in advance of coding. That language clearly lays out the stakeholder, business effect, and business value, and must remain consistent throughout the project.

Title

An explicit title.

Narrative

A short introductory section with the following structure:

• As a: the person or role who will benefit from the feature;
• I want: the feature;
• so that: the benefit or value of the feature.

Acceptance criteria

A description of each specific scenario of the narrative with the following structure:

• Given: the initial context at the beginning of the scenario, in one or more clauses;
• When: the event that triggers the scenario;
• Then: the expected outcome, in one or more clauses.

Pros of TDD

• Promotes confidence and simplicity in development
• Stable, clean code is easy to build upon or modify as features evolve. 

Cons of TDD

• Requires more upfront investment, as writing tests before starting development takes additional time.
• When the spirit of TDD is abused, shortcuts in coding can pass tests without strong logic. 

Pros of BDD

• Minimizes communication breakdowns between technical and non-technical stakeholders. 

Cons of BDD 

• Requires a disciplined scrum master or PM to enforce adherence. 
• Can slow down projects where communication between technical and non-technical stakeholders isn’t fluid. 

Unified Process

The unified process is an iterative and incremental development process that focuses on risk by addressing the most critical risks early in the project lifecycle. In UP, the project is divided into four phases - Inception, Elaboration, Construction, Transition. During Inception, the shortest phase, you develop an approximate vision of the system, make the business case, and produce rough estimates for cost and schedule. During Elaboration, the team is expected to cover most of the system requirements with the primary goal of addressing known risk factors and establishing and validating the system architecture. This could result in as little as Use Case and Architectural diagrams or as much as Rapid Prototyping proofs of concept. During Construction, the largest phase, the system is built upon the foundation laid in Elaboration using short, time-boxed iterations (like sprints). Finally, during Transition, the system is deployed to target users and feedback is received. 

Pros

• Useful for large, slow-moving projects. 
• Understanding of known risks at outset can temper unrealistic expectations

Cons

• User feedback isn’t received until late in the project, making it harder to iterate or pivot.
• Projects can be slow to start 

Bonus Round: MYO

The MYO method, or Make Your Own, is entirely made up. But it’s entirely made up of proven tactics that work in various team compositions. Read through this list and pick and choose what works best for you. If your team is distributed, XP might not work well, but you can still embrace change requirements. Maybe Kanban works for your product planning process, but you switch to Scrum for development. You might borrow the Elaboration phase of UP, and the requirements language of BDD. RAD might be a great way to validate ideas before you fire up a longer-term or more complex development process. There are so many variations of Agile because there are so many variations of projects, teams, and ideas. Have some fun and experiment. Because the act of trying and tweaking is the Agile string that threads through all of these methodologies. 

Not sure what methodology would be the most effective for your team? SF AppWorks can help.