What is Agile product development?
Agile is a way to approach knowledge work - specifically software development - characterized by adaptiveness and response to change.
When your team works with Agile development, you are better positioned to deal with uncertainty and succeed in a turbulent environment.
The term “Agile” was first used to describe an approach to software development in the Manifesto for Agile Software Development, or the Agile Manifesto for short.
Here’s a look at what Agile software development really is, an explanation of the Agile Manifesto and what product people need to know about Agile.
What is Agile development
Agile development describes a way to approach software development based on the values and principles expressed in the Agile Manifesto and the 12 Principles behind it. When your team approaches software development in an Agile manner, you use those values and principles to figure out the right things to do given your context.
There are a variety of characteristics you can use to identify an organization that is working in an Agile manner:
Software development is done by cross-functional teams that have the necessary skill sets to deliver the intended solution.
The people on those teams collaborate with each other to iteratively deliver an evolving solution.
The teams determine their particular approach to software development based on the nature of their environment.
These characteristics position your team to address the uncertainty that comes naturally with software development.
You don’t assume you know everything at the beginning of the effort and try to plan everything out. Instead you accept that you are going to learn new information as you go through the process of developing a solution and you establish means of changing your process when appropriate.
What is the Agile Manifesto
In February 2001, 17 software developers and consultants met at a ski resort in Snowbird, Utah, United States to compare their approaches to developing software. This particular group got together because their approach to software development differed from the planned up front, documentation heavy approaches common at that time.
The authors found that while their individual approaches (including Scrum, Extreme Programming, and others) differed from industry norms, they had a lot in common.
They decided that they needed to find a better name for the collection of frameworks (formerly known as “lightweight methods”). They settled on “Agile”.
That word seemed to best represent the adaptiveness and response to change which was so important to all of their approaches.
They also thought they should put together a document - a manifesto - to explain their beliefs about what software development should be.
The result is the Manifesto for Agile Software Development, or the Agile Manifesto.
Reflection and adaptation are key
Most people focus on the four value statements from the Agile Manifesto. These statements express what values would make software developers’ lives better compared to the common approaches at the time.
The most important part of the Agile Manifesto is actually the first sentence: “We are uncovering better ways of developing software by doing it and helping others do it.”
That statement encapsulates the idea that you should always observe the results of your actions and adjust your approach when you see an opportunity to improve. It’s the core thought of Agile, and it’s the aspect that stands the test of time.
The 17 authors wrote the Agile Manifesto while they were in Snowbird, then followed up over the next six months or so by crafting the twelve principles.
These principles were more of a status report, expressing how the authors thought that software development could be made better for developers compared to the common approach of software development at the time.
Are the principles still timely?
Unfortunately, several of the principles are out of date given trends toward remote working and the influence of modern product management.
Specifically:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. - Our highest priority should be to delight our customers by solving their problems. Sometimes this means delivering software. Sometimes it doesn’t.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. - Every couple of weeks… how quaint. Many teams now strive to deliver working software many times per day - when it makes sense of course.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. - This is still probably the case, but technology has caught up to the point where your team can accomplish face-to-face discussions even at a distance. (But sprinkling in some actual face-to-face discussions is always a good idea).
Working software is the primary measure of progress. This was included as a principal to remove reliance on documentation for the purposes of tracking progress. However, measuring progress via working software means measuring progress based on output. You’re better off measuring progress based on how you’re addressing your selected outcome metric.
What product people need to know about Agile development
It’s important to remember the background of the guys that wrote the Agile Manifesto. They were all software developers or software development consultants. They wrote the Agile Manifesto to describe what software development should look like in order to improve the lives of software developers.
That is by no means a bad thing, but it’s important to remember because it means that Agile was not intended to address every aspect of product development - notably product management.
For example, one of the principles behind the manifesto states “Business people and developers must work together daily throughout the project.”
This principle is intended to make sure that developers do not have to sit around waiting for answers to their questions. It was also intended to prevent teams from starting a development effort and then running away and hiding without ever talking to customers for the next six months.
Those are all good things, but it can also place unrealistic expectations on product people. Engineers can point to this principle and say their product person should be with them all the time.
Product people need to balance working with the product team and understanding the market.
Keeping that example in mind, it’s helpful to take a look at Agile development from a product person’s perspective to gain a sense of clarity and balance.
Agile is not a methodology
Agile is frequently referred to as the Agile development methodology or Agile development process.
It’s is not a methodology but a way of thinking about how to approach software development. It’s an adjective, not a noun.
Alistair Cockburn once described a methodology as the set of conventions the team agrees to follow. Scrum, Kanban, XP, etc. are frameworks that teams use as a starting point for creating a methodology to fit their context.
Agile values and principles provide some guidance that teams can follow when creating their own software development methodology, including the idea that teams should create their methodology in the first place.
There’s more to Agile than just Scrum
More often than not, when an organization adopts Agile, it will use (or say it’s using) some form of Scrum. That leads many people to conclude that Agile = Scrum. Scrum is only one of many frameworks that you can use as a starting point to approach work in an agile fashion.
Why is that important? Because Scrum is the only one way to approach living Agile values and principles. It is not appropriate in every situation, and it is not a complete solution.
You don’t have to do Scrum in order to do Agile, which means you don’t have to work in sprints. Sometimes the nature of the work you’re doing lends itself to reprioritizing and deploying much more frequently than once every two weeks.
Scrum mainly provides a set of practices for cross-functional team collaboration. The official source on the scrum framework - the Scrum Guide - does not address the technical practices that developers should follow to build excellent products. XP fills that gap to some extent.
The Guide identifies a product role - the product owner. However, the Guide only notes the activities of the product owner as it relates to working with developers. It doesn’t speak to all the discovery work that goes along with being a product person.
Product ownership is a subset of product activities
Agile values and principles explain the delivery aspect of software development. They do not address the discovery aspect of proper product development. In other words, they really don’t speak to a large chunk of product management.
Software developers wrote the Agile manifesto and created the corresponding frameworks to address problems that software developers face. As a result, the representation of product people described by those frameworks focus on what a product person does for developers:
Provide priorities for the development team
Answer questions for the development team
Represent the customer to the development team
These are essential activities to be sure, but it’s far from all that product people do.
Remember that product ownership covers the subset of product management that deals with working with your team.
The goal is not to “do agile” or “be agile”
You may have heard the common admonition that you shouldn’t try to “do Agile”, you should work on “being Agile.”
These admonitions are misguided. The goal is not to do Agile or be Agile.
The goal is to deliver maximum outcomes with minimum output. Working in an agile manner is necessary, but not sufficient to accomplish that.
You need more than an Agile engineering organization to realize the benefits promised with most Agile transformations. You need to add proper decision-making and a focus on outcomes.
Working in an Agile manner is a means to an end, not the end in itself, regardless of what your Agile coach may have told you.
Conclusion
Agile is one of the best things that happened to the software development community in the past 20 years. The values and principles involved address some of the biggest challenges that software developers and teams faced.
It’s important to remember that Agile frameworks do not have much to say on product management. So as a product person, it’s helpful for you to know what Agile does for the delivery aspects of your product team, and at the same time remember there’s a lot more involved in the realm of discovery.
We hope this overview gives you a good idea of what you need to know about Agile. If you’d like to dig deeper, we encourage you to check out our information about specific Agile frameworks and practices.
Kent McDonald
Read also
Prioritize with confidence
