Different Agile methodologies are applied daily in all types of organizations – why? Every high-performing organization wants to move faster, innovate more, and accomplish more with less time.
But as the saying goes, there is more than one way to skin a cat. When you’re working in teams of highly talented, highly motivated people, there are bound to be some differences in opinion, perspective, and methods. Aligning around a shared way of thinking through problems and structuring work can help keep the organization moving at a good pace.
AgilePlace Free Trial: AgilePlace Online Kanban Software
Sign up for a 30-day free trial and you and your team can start building online Kanban boards today. Experience for yourself how AgilePlace supports continuous delivery initiatives, eliminates waste and improves your team’s delivery processes and speed.Jetzt kostenlos testen • AgilePlace Free Trial
Which types of Agile methodology are right for you? That depends on several factors:
- team types, which are related to the types of Agile processes you’ll want to employ
- organization size, and whether you’re wanting to scale Agile from the ground up or from the top down
- organizational culture – is your organization ready for (and interested in) a highly structured Agile approach, or would you prefer a more flexible approach
There are many different methodologies that fall under the category of Agile, or are similar enough that they’re worth mentioning as part of a larger conversation about workflow and resource management. Read on to learn about the different Agile methodologies to determine which might be right for your organization.
Agile was designed for software development teams as a time-focused, iterative way of achieving continuous value delivery. Developers were looking for a way to add flexibility, transparency, and communication to their processes.
At the time, prevailing methods were cumbersome, with long development cycles and large, complex, infrequent releases. A group of developers came together to create the Agile Manifesto, which outlines the basic principles of what is or is not Agile.
After the Agile Manifesto formalized Agile as a distinct methodology, developers began practicing Agile to improve flexibility, customer/user satisfaction, and adaptability in the marketplace.
Instead of deploying software in large, scheduled releases, teams broke work down into small, frequent iterations. Rather than spending time gold-plating new releases internally, teams got work to a deployable state, released as it was ready, and allowed users to provide feedback on what worked, what didn’t, and what could be improved.
Teams in all disciplines – marketing, sales, operations, and more – began adopting Agile practices as a way to work more efficiently, communicate more clearly with customers, deliver high-quality products, and build more sustainable businesses.
Agile maintains its hold in software development and has also spread into marketing, sales, and other departments.
Agile has been proven effective at the team level, but does not provide a framework for managing work across cross-functional teams, or scaling planning and prioritization at the team, project, and portfolio levels.
This is why many organizations have turned to hybrid models, like the Scaled Agile Framework (SAFe), as a way to scale Agile (influenced strongly by Lean thinking) across the organization.
Scrum is an Agile method for completing complex projects in a methodical way. It was originally created to help software development teams design more sustainable software products, but can apply to any type of complex, project-driven work.
The Scrum framework includes Scrum Teams and their associated roles, events, artifacts, and rules. Each element of the framework serves a specific purpose and is essential to Scrum’s success and usage.
According to the Scrum Guide, the definition of Scrum is: Scrum (n): “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
- Simple to understand
- Difficult to master
It is lightweight, in that Scrum teams work to eliminate waste by planning work only two weeks in advance. This allows for more flexibility and adaptability than other methods.
It is simple to understand, in that it relies on a few very basic principles:
- Develop iteratively
- Optimize predictability
- Control risk
- Practice process control through transparency, inspection, and adaptation
It is difficult to master, because the Scrum values of commitment, courage, focus, openness, and respect require individuals and teams to hold themselves to a high, disciplined standard of conduct.
Scrum works well for small teams that work together on large, complex projects, such as software development teams. It is typically not recommended for teams with more variety in their workflows and planning processes (such as marketing or sales teams).
Related to Scrum, feature-driven development (FDD) is an iterative and incremental software development process. It is a lightweight, Agile methodology for developing software.
Feature-driven development blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a feature-first perspective, with the goal of creating value for the client. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.
Feature-driven development typically consists of five basic activities. For accurate status reporting, milestones are used to mark progress made on each feature. During the first two activities, an overall model shape is formed; the final three activities are iterated for each feature.
The five main activities in FDD are:
- Develop overall model
- Build feature list
- Plan by feature
- Design by feature
- Build by feature
After unit testing and successful code inspection, the completed feature is promoted to the main build. FDD is a productive, structured, focused method for software workflow management that is a good option for software-focused teams and organizations.
Often Lean and Agile methodologies are discussed interchangeably; although there are differences between them, one could argue that the goals behind them are quite similar. While Agile was born out of a need to bring efficiency to software development, Lean was born out of the same need, but in manufacturing, a few decades prior.
Understanding the history behind these two distinct (but now closely intermingled) methodologies can aid in understanding the differences between them today.
In the 1980s and ‘90s, Western manufacturers struggled to keep up with the efficient Japanese companies, so they had two options: Trim down, or shut down. They began adopting the practices of the Japanese companies in an effort to improve their speed, productivity, and cost efficiency to remain competitive.
Unfortunately, during this time, Lean methodology was boiled down to overly simplistic ideas, generally used to justify relentless cost cutting. That’s why today, the manufacturing industry employs far fewer people than it once did. There are fewer players in this space. They’re leaner, but fewer and larger, too.
Many variations of Lean methodology were born in the years following, including Total Quality Management, Just-in-Time, Six Sigma, and the Theory of Constraints. Each of these movements incorporated various practices from what the Japanese were doing that differentiated them from their competition, although we can safely say that what they were aiming for is now known as Lean methodology.
Many of these popular “Lean” management frameworks were highly prescriptive by nature, and required considerable training to adopt fully. In their books, The Machine that Changed the World and Lean Thinking, Jim Womack and Dan Jones helped us elevate our understanding of Lean thinking, allowing us to move from mimicking Toyota practices to truly understanding the principles that made the whole Toyota system work.
Approaching Lean thinking as a set of guiding principles, rather than a specific set of prescriptive practices, makes implementation easier, more flexible, and more sustainable.
Much like Agile, at its core, modern Lean is a way of thinking. It’s a mindset that helps you make smarter decisions about how to invest your time, energy, and money.
Lean thinking can help you find clarity and purposein your work, by helping you sift through the noise and focus on what matters. When scaled across a team or organization, this type of thinking has the power to transform, revitalize, and inspire. It can turn a dysfunctional, ineffective group of people into a value-generating powerhouse.
Lean is also a practice, something you do daily, aiming to always improve. It’s rooted in the idea that people want to do good work, and organizations want to provide environments that inspire them to do so.
However, individuals, teams, and entire companies are often so entangled by the status quo – their existing processes, tools, ways of thinking, leadership styles – that they lose the ability to innovate.
By practicing Lean, we can slowly unravel the complexity of our work and resume the flow of productivity and innovation.
Lean’s core principles can be applied across a team or group of teams or scaled across an entire organization. Lean’s ability to scale makes it a great, flexible option for both high-growth startups and established enterprises.
The core principles of Lean are:
Unlike many of the Agile methodologies on this list, Kanban can be viewed as a distinct methodology, or simply a tool to implement other methodologies, such as Lean or Agile.
Kanban uses (typically digital) boards to represent the unique steps in your process, and cards to represent tasks as they move through those steps.
In a micro level, this helps teams and the individuals within them combat the damaging effects of multitasking in a hyper-stimulated world. It helps teams have meaningful, focused conversations about work priority and status, saving them both time and frustration often associated with a lack of visibility.
On a macro level, Kanban helps organizations achieve their larger goals. By visualizing all shared work in one place, Kanban provides teams and the people who manage them with the visibility they need to get more done.
Large initiatives can be broken down into smaller, more manageable projects, which can them be broken down into smaller, more manageable tasks. Teams can confidently prioritize and complete work that actually helps the organization achieve its larger initiatives, and leaders can track the progress of these initiatives without having to constantly interrupt and interrogate those doing the work.
Kanban is often viewed as a tangible, practical way to implement Lean and Agile methodologies.