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.
Related: Everything You Need to Know About The Agile Software Development Life Cycle
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.
Would you use this methodology for your own app development project? Check out our resources at SF AppWorks!
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.
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.
Related - Watch: What could happen if you DON’T do rapid prototyping
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.
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.
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.
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:
Acceptance criteria
A description of each specific scenario of the narrative with the following structure:
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.
Not sure what methodology would be the most effective for your team? SF AppWorks can help.
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.
NOTE: 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.