Agile, and many of the terms associated with it—like Lean, DevOps, Kanban, and Scrum—can be tough to pin down. In this post, we’ll break down these common terms and provide concrete examples and visual guides to help you better understand what they mean and how you can incorporate them into your workflow.
To kick things off, what exactly is Agile software development and where did it come from? According to Agile Alliance, “Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.” Meanwhile, “Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it.” Product School defines Agile this way: “It’s a philosophy that means breaking projects down into small goals and working towards those goals while adding new goals. It’s set up so a software development system can react well to changes.”
The term “Agile” was coined in this context in the year 2001 when the Agile Manifesto was formulated. According to Agile Alliance, “the authors of the Agile Manifesto chose ‘Agile’ as the label for this whole idea because that word represented the adaptiveness and response to change which was so important to their approach.”
A brief history of Agilе
Officially, Agile was born in 2001 from the Agile Manifesto to improve productivity, specifically in software development, but it has now expanded into other areas such as marketing. Any project team that follows the values of 12 Agile principles can be considered “Agile.”
Principles behind the Agile Manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals.
- Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
On one hand, Agile is now a widespread practice—according to the 2019 State of Agile Report, 97% of respondents say that their organizations practice Agile development methods. Yet according to the same report, only 22% of respondents say that all teams at their organization are Agile. So Agile is now widely practiced, but perhaps not evenly distributed.
What’s next for Agile? Many experts believe it will move beyond the world of software and products to alter how every department and process in an organization works. Agile coach Gerard Chiva predicts, “The next step for Agile being made now is organizational agility. Agile is no longer about product development; it concerns the whole development process and organization. Finance, legal, HR—everything must work together as a complete, adaptable, and Agile organism. True business agility is not only about the production or the operational side of the company. It’s also about the strategy, management, decision making, governance and structure—everything.”
A few highlights from the Agile history timeline
- 2001: Several software developers draft the Agile Manifesto
- 2002: The Scrum community picks up the practice of measuring velocity
- 2003: Mary and Tom Poppendieck’s book Lean Software Development describes the Agile task board as a “software Kanban system”
- 2004–2006: The daily meeting is generalized as a core Agile practice
Source: Agile Alliance
What are the benefits of Agile?
One of the main benefits of this approach is the ability to adapt and change at any step depending on feedback, market conditions, corporate obstacles, etc. and to supply only relevant products to the market.
That is why an Agile company is usually very flexible, quickly adapts to changes, iterates less while implementing faster, and is able to seize new opportunities as they appear. It enables a fast decision-making process through flexible organizational structure and simple communication.
In Agile development, customer value is delivered in small increments, feedback is gathered from customers, synthesized, and used to inform the next stages of the process.
Victor Osetskyi writes, “In the Agile methodology after every development iteration, the customer is able to see the result and understand if he is satisfied with it or he is not. This is one of the advantages of the Agile software development life cycle model. One of its disadvantages is that with the absence of defined requirements it is difficult to estimate the resources and development cost.”
In addition to increased interaction with customers and greater customer satisfaction, other advantages of the Agile model are faster implementation of changes and more flexibility for making those changes.
Top 3 reasons for adopting Agile
- Accelerate software delivery: 74%
- Enhance ability to manage changing priorities: 62%
- Increase productivity: 51%
Source: 2019 State of Agile Report
Agile Philosophy
Is aimed at executing tasks faster, adapting to changes easier
Makes the developing process flexible
Was initially designed for Software Development, then expanded to Marketing, and is currently applied in other areas
Action loop: product backlog – sprint backlog – iteration (sprints) – potentially shippable result
Method for demonstrating progress — definition of ‘done’
Methodologies: Scrum, XP, FDD, DSDM, Crystal Methods etc.
Toolkit: sprints, boards, Scrum Master, acceptance tests, user story mapping etc.
Start for free with Miro’s Product Backlog template.
What are Agile methodologies?
One quick note of clarification: Agile and Lean principles are a basis that can be applied to different methodologies like Scrum and Kanban (which we’ll describe in more detail later), so it would make more sense to refer to Agile and Lean as “mindsets” or “philosophies.”
Some of the methodologies associated with Agile include:
- Scrum
- Extreme Programming (XP)
- Feature-Driven Development (FDD)
- Dynamic Systems Development Method (DSDM)
- Crystal methods
What is an Agile board?
Agile boards are visual frameworks to display and sync upon the tasks moving between the production steps. They are used mostly by software developers and product companies to help manage workload in a flexible, transparent, and iterative way and are commonly associated with Kanban and Scrum methodologies.
Need help building your Agile board? Check out Miro’s Agile board template to get started.
And be sure to explore Miro’s complete Agile development guide!
To learn more about Agile, see the following resources:
- Guide to Agile Practices
- Lean Startup Movement
- The Scrum Guide
- Kanban: Successful Evolutionary Change for Your Technology Business
How do Agile and product management work together today?
It’s difficult to talk about Agile for too long without bringing in product management—see, we only made it through the first few sections of this article! The product manager’s role is sometimes referred to as the “CEO of the product,” although Harvard Business School lecturer Julia Austin takes issue with this definition, quoting Martin Erikkson: “Product managers simply don’t have any direct authority over most of the things needed to make their products successful—from user and data research through design and development to marketing, sales, and support.”
At a high level, a product manager is looking to the near and long-term future and making decisions on how to develop the product in relation to those needs. According to McKinsey, “Product managers now function on two speeds: they plan the daily or weekly feature releases, as well as the product road map for the next six to 24 months.”
Due to the fast-paced nature of software engineers’ work (they can write code and push out new features on a daily basis), the product manager’s role has been significantly impacted by Agile, and most product managers incorporate an Agile mindset and associated methodologies with their work.
Typically, product managers work closely with engineering teams, but The State of Product Leadership Report 2019 found that many product managers are now prioritizing alignment with other departments like design and UX, marketing, and customer success: “How products are designed; how they’re marketed and distributed; and how they’re made “sticky” for end users together comprise the holy trinity of modern software.”
Some of the most common aspects of a product manager’s job include:
- conducting user interviews and user testing
- running design sprints
- feature prioritization and product road mapping
- translating business to technical requirements and vice versa
To learn more about what a product manager does on a daily basis, see our Guide to a remote product manager’s daily routines: tools, processes and tips.
Changes in the pace of software development mean that Agile has had a significant impact on most product managers’ work. Let’s look at this concept in a bit more detail. Atlassian product manager Sherif Mansour writes, “Agile product management is all about understanding customers’ problems. By any means necessary.” He continues, “The Agile manifesto reminds us that we don’t always have to do it the ‘traditional’ way. As product managers, we should be doing whatever is required to tell the story of the customer. Try different things: experiment, explore, then do what works best for you and your team in the context that you might be working in.”
Product manager vs. product owner: What’s the difference?
Many modern work methodologies assign one person who serves as the product owner and helps the team adopt good habits. However, not every product manager can be called a product owner. We outlined some of the main differences so you can see what makes a role of a product owner special.
A product manager:
- Owns the product road map
- Advocates for the product internally
- Represents the customer in meetings with development
- Is a job title
A product owner:
- Grooms the team’s backlog
- Answers the team’s questions about requirements
- Has discussions with stakeholders
- Accepts content from the team
- Is the title of role, which could be performed by someone with any title
According to Agile Alliance, “Many infer that a product owner is someone who can spend a considerable amount of time with the product development team providing clarification on product backlog items, and making decisions about which product backlog items to do and regarding the specifics of those particular product backlog items.” It means that on an Agile team, product owner is someone who has a clear vision for the product, what problem it solves, and for whom — all these factors allow the product owner to be effective at prioritization.
For more on this topic, see How Agile distinguishes between product managers and product owners or watch a video Agile Product Ownership in a Nutshell.
Looking for a collaboration tool to improve your team’s performance? Try Miro free
5 Things a Product Owner Must Do
Here’s a quick way to determine how well you’re meeting your obligations as a true product owner. Ask yourself if the following statements describe you:
- I think of myself as part of the product development team. I’m not simply a product manager who writes specs, delivers them to our developers and then waits for them to build something. I am an active member of that team, from the initial product kickoff meeting, through launch and beyond.
- I attend and actively participate in all sprint planning sessions.
- I attend and actively participate in all sprint demos. (In fact, our development team won’t hold these demos without me.)
- I am always available to my developers for questions or discussions about the details of the product they’re coding.
- I review every story (which usually must include a mock-up) before it gets into a sprint.
Source: Product Plan
Tips for succeeding as an Agile product manager
There are numerous resources out there to help you develop your Agile product management skills. Here are a few to consider:
- Agile Product Management Training & Certification from 280Group
- Product Management with Lean, Agile and System Design Thinking from Boston University, offered through EdX
- SAFe Product Owner/Manager Certification from Scaled Agile
Charlotte Mallo from Crowdbotics shares a case study of how her team adopted a Lean Agile approach to product management. Her tips include: taking every opportunity to upskill themselves, prioritizing one item per sprint, and measuring tasks to increase their ability to estimate and prioritize. Read more of Charlotte’s tips in Why We Succeeded in Agile Development and What We Should Have Done Better.
What is the Lean methodology?
Initially, the Lean movement was born in Japan in the mid-1950s in the automotive industry and was mainly aimed at loss reduction and sustainable production. In the 2000s, Lean was adapted for software development by Mary and Tom Poppendiecks who related it with 7 initial Lean principles and Agile philosophy.
Following the trend that Lean could be extended to any industry, Lean was applied in the startup industry in 2008 by Eric Ries as a way of developing “new products and services in circumstances of extreme uncertainty.” To be considered “Lean,” a startup should follow the values of 5 Lean principles by Eric Ries, outlined in his book The Lean Startup.
5 Lean Principles
- Entrepreneurs are everywhere
- Entrepreneurship is management
- Validated learning
- Innovation accounting
- Build–Measure–Learn
Source: The Lean Startup
A typical Lean company follows a learn – measure – build cycle, and conducts many tests, frequently connects with customers, understands their value, and focuses its key processes to continuously improve it. A never-ending cycle leads the startup to sustainability, smart development, and success.
While reducing the high costs of getting the first customer and even higher cost of getting the product wrong and shortening technology development cycles, Lean Startup philosophy helps new ventures launch products that customers actually want, far more quickly and cheaper than traditional methods, making startups less risky.
The Lean Startup
What’s the difference between Agile and Lean?
Both Agile and Lean are aimed at achieving business goals and delighting clients with a competitive product of the best quality. These and many other shared features between the two mindsets often lead to people mixing them up.
However, they serve different purposes and tasks, and that is why it’s important to draw a clear line between them.
The term Lean is wider than Agile because its smart approach influences all types of losses (not only time loss) such as money, labor, energy, etc. Moreover Jeff Sutherland points out that Agile was born after Lean, so they are closely related. Conceptually Agile is a subset of Lean principles and practices which are in turn a subset of Systems Thinking.
Lean Philosophy
- Is about Smart development, when you improve virtually everything you do by eliminating anything that doesn’t bring value to the customer.
- Makes the developing process sustainable
- Started from traditional manufacturing (“lean manufacturing”) and expanded to all existing industries
- Action loop: build-measure-learn
- Method for demonstrating progress — validated learning
- Methodologies: Kanban, Kaizen etc.
- Toolkit: hypotheses, split (A/B) tests, customer interviews, funnel and cohort analysis, Customer Success Manager etc.
What’s the difference between Agile and Waterfall?
The traditional or “Waterfall” approach to product management treats each stage as separate and sequential. Agile methods, on the other hand, use iterative work cycles or sprints. According to Study.com, “The main difference between Waterfall and Agile methods is in the goals; the Waterfall method wants to get everything right the first time, and Agile methods want to get things released quickly. Differences in adaptability, documentation, testing, and collaboration support the different goals.”
Why is it so important to move away from Waterfall and towards an Agile mindset? Lean UX author Jeff Gothelf puts it this way: “I also see that many project management professionals are coming from the Waterfall mindset. I think that’s a big challenge; it’s a mentality that the way we work has to change. If you’re working in software, you’re dealing with a certain level of ambiguity and uncertainty. You can’t predict the net result or the end state of these initiatives, and to pretend that you can is risky. It’s a risk for your project and should be mitigated”.
He continues: “Product managers are trying to figure out how to incorporate themselves in such a way that they’re enabling the team to move forward quickly in the right direction without getting blocked in extensive upfront planning, and trying to predict exactly how the product will work and perform at that time. To me, that is the biggest challenge of working with traditional project managers.” Hear more from Jeff in our interview with him on the challenges of Agile transformation.
The most effective way to overcome the Waterfall mindset is to get them to give you the opportunity to work differently and show them how that work changes the way the teams are performing and what they do.
Jeff Gothelf, Author, Lean UX
What is the difference between Agile and SDLC?
Software Development Life Cycle or SDLC models refer to the process that’s used to develop software. Different examples of SDLC include Waterfall, Iterative, Spiral, V-Shaped, and Agile. No matter which model is used, they all tend to include certain stages like planning and requirement analysis, designing project architecture, development and programming, testing, and deployment.
Here’s an illustration of the Agile SDLC model:
What’s the difference between DevOps and Agile?
First of all, it’s worth noting that, unlike Waterfall and Agile, DevOps and Agile are not that different from each other. Atlassian suggests that “they work better in combination than as adversaries.”
But what exactly is DevOps? The phrase DevOps is a portmanteau of the words “Development” and “Operations” and, according to Atlassian, DevOps seeks to bring that Agile attitude toward change to a new audience: IT operations. One of the main distinctions is that DevOps occurs in response to unplanned events like performance spikes, system outages, or compromised security. According to Atlassian, “These events demand immediate response. There’s no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them.”
Similarities between DevOps & Agile
- Both working to enhance business productivity
- Adopting the Lean philosophies
- The collaboration process
Differences between DevOps & Agile
- Methodology & deployment
- The number of members of a team
- Cross-functionality vs. segmentation
- Approach to planning
- Documentation & interaction
Source: Agile vs DevOps: Major Differences and Similarities
What’s the difference between Agile, Scrum, and Kanban
Scrum and Kanban are two of the best-known software development methodologies. Traditionally, a Scrum or Kanban board was a physical board within an office, but with the increasing number of distributed workers, it’s becoming more common to use visual software for Agile product teams.
Learn more: 5 False Hopes of Scrum and How to Fix Them
Scrum
- Timeboxed interactions prescribed
- Team commits to a specific amount of work for this iteration
- Uses velocity as default metric for planning and process improvement
- Cross-functional teams prescribed
- Items broken down so they can be completed within one sprint
- Burndown chart prescribed
- WIP limited indirectly (per sprint)
- Estimation prescribed
- Cannot add items to ongoing iteration
- A sprint backlog is owned by one specific team
- Prescribes 3 roles (PO/SM/Team)
- A scrum board is reset between each sprint
- Prescribes a prioritised product backlog
Kanban
- Timeboxed interactions optional
- Commitment optional
- Uses lead time as default metric for planning and process improvement
- Cross-functional teams optional, specialist team allowed
- No particular item size is prescribed
- No particular diagram is prescribed
- WIP limited directly (per per workflow state)
- Estimation optional
- Can add new items whenever capacity is available
- A kanban board may be shared by multiple teams or individuals
- Doesn’t prescribe any roles
- A kanban board is persistent
- Prioritization is optional
According to Scrum guru and author of Scrum: Doing Twice the Work in Half the Time Jeff Sutherland, Scrum is “a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
The fundamental principle of Scrum is that by splitting time, product, and organization, you optimize the process and guarantee impressive results. Here’s how it works: a company establishes small teams and gives them small tasks for short periods of time (e.g. two-week sprints). The teams track their progress on Scrum boards which have the following sections: backlog, to do, in progress, and “done” tasks.
Interested in running sprints with your distributed team? Be sure to check out our sprint planning guide and templates.
Before running a sprint, the team should do product backlog refinement. This may take the form of an initial product backlog refinement meeting when your team doesn’t have a backlog yet, a story generation workshop when your team needs to understand how to implement a new feature, or an ongoing backlog refinement to ensure your backlog is healthy. See these tips and templates to help you improve product backlog refinement at your organization.
Kanban, on the other hand, is a scheduling system of visual management aimed at just-in-time delivery to prevent team overloading. Similarly to Scrum, Kanban tracks ‘to do – in progress – done’ activities, but it limits the number of ‘work in progress’ activities (this number is defined by the team manager and cannot be exceeded).
As we already mentioned, product owners in Scrum are called Scrum masters, while in Agile they’re called the Agile coach. The main distinction is that a Scrum team works in a series of sprints, so there’s a clearly defined beginning and end as well as a planning session. Kanban, on the other hand, is a continuous process, so there’s no sprint backlog. For more on the differences between these two methodologies, see this video.
Curious to explore more? Browse some examples of digital Scrum vs. Kanban boards.
