Agile has reached, and frankly blazed past buzzword stage. It’s no longer new (the term being applied to software development over 2 decades ago). And there are a lot of different perspectives about what agile is, and isn’t.
There’s also a lot of myths and misconceptions about agile practices and techniques. Here’s my attempt to add some clarity about agile for product people.
1) Agile is not a methodology. It’s a way of working.
People frequently call agile a software development methodology or a project management methodology.
It’s neither of those things, or any kind of thing (which also means it doesn’t “say” anything). It’s a way of looking at and thinking about how to approach knowledge work. Instead of a noun, it’s an adjective.
Alistair Cockburn described it best on his blog. He explained that a methodology is the set of conventions the team agrees to follow. Scrum, Kanban, XP, SAFe, etc. are frameworks that teams use as a starting point for creating a methodology to fit their context.
The agile way of working provides some guidance that teams can follow to create their own methodology. That includes the idea that teams should create their methodology in the first place.
2) There’s more to agile than just scrum.
The Scrum framework won the agile “market share” wars as the most common framework people use. That leads many people to conclude that agile = scrum. In reality, scrum is only one of many frameworks that you can use as a starting point to approach work in an agile fashion. I like to use an analogy here: scrum is to agile as Kleenex is to facial tissue.
Why is that important? Because scrum is only one way to approach living agile values and principles. It is not appropriate in every situation, and it is not a complete solution.
If people think that they have to do scrum in order to be agile, they also conclude they have to have sprints, even when the nature of work lends itself to reprioritizing and deploying much more frequently than once every two weeks.
It also leads them to ignore the excellent technical practices found in extreme programming.
3) Product practices are more relevant than ever
Just because most frameworks don’t mention product management, user experience or business analysis doesn’t mean those activities are not important. The frameworks are not intended to be all encompassing.
Software developers created agile frameworks to solve problems that software developers face. All of the frameworks have a role that is determines the right thing for your team to work on. Those same frameworks leave out any guidance on how that person should operate. That’s where the practices that product people use come into play.
4) Agile alone will not get you better, faster, cheaper.
When organizations adopt agile in their IT and development organizations and do not make corresponding changes in how they manage their portfolio of work, they soon find that they have become more efficient at producing the wrong things.
It’s only when organizations combine proper decision making and a focus on outcomes with well functioning development teams that build quality into what they build do they truly realize the benefits of an agile mindset.
5) Writing and mapping user stories is not the whole story
User stories and story mapping are just a couple of mechanisms that you can use to help build a shared understanding with your team about the problem and the solution. There are many other techniques that are helpful to have in your toolkit such as jobs to be done, specification by example, context diagrams, process models, mockups, wireframes, and a host of others.
The next time you get obsessed with how you write user stories, remember what Jeff Patton says “Stories get their name from how they should be used, not what should be written.”
6) Product ownership is a subset of product activities
As mentioned above, software developers created agile frameworks to address problems that they and other 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 important activities to be sure, but it’s far from all that product people do.
The key thing to remember is that product ownership covers the subset of product activities that deal with working with developers.
7) The goal is not to “do agile” or “be agile”
A trendy admonition for organizations that adopt agile is 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. The goal is not to be agile.
The goal is to help customers solve their problems in a way that works for your business. Working in an agile manner can often help you accomplish that.
Working in an agile manner is a means to an end, not the end in itself, regardless what your agile coach may have told you.