Agile has reached, and frankly blazed past buzzword stage. It’s no longer new (the term being applied to software development over 18 years ago) and there are a lot of different perspectives about what agile is, and is not.
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 mindset.
Agile is frequently referred to as a software development methodology or a project management methodology.
It’s neither of those things, or any kind of thing. 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. The key part of his argument is that 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 mindset provides some guidance that teams can follow when creating their own methodology, including the idea that teams should create their methodology in the first place.
2) There’s more to agile than just scrum.
The Scrum framework has won the market share wars as the most commonly used framework when organizations adopt agile. 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 still relevant
Just because most of the frameworks do not mention product management, user experience or business analysis does not mean that those activities are not important. The frameworks are not intended to be all encompassing.
The agile frameworks were created by software developers to solve problems that software developers face. All of the frameworks have a role that is responsible for determining the right thing for your team to work on but provide no 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, agile frameworks were created by software developers 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 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 the development team.
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 deliver maximum outcome with a minimum output. 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.
Did I Miss Anything?
I’d like to hear your thoughts. Is there something I missed that product people need to know about agile? Do you have questions about anything I listed?
Let me know in the comments.
Leave a Reply