This website or its third-party tools use cookies which are necessary to its functioning and required to improve your experience. By clicking the consent button, you agree to allow the site to use, collect and/or store cookies.
Please click the consent button to view this website.
I accept
Deny cookies Go Back
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

KBP Media

Just-in-time resources for product people

  • About
  • Blog
  • Contact
  • Newsletter
  • Login

Kent McDonald / December 1, 2019

7 Things product people need to know about agile

Tweet
Share
Share18
18 Shares

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.

Filed Under: Product Ownership

Become a more effective product person

Previous Post: « How to use outcomes to decide how to deliver a solution
Next Post: Build Measure Learn »

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search this Site

Become a more effective product person

Learn more about these topics

Business Analysis

Product Ownership

Product Management

Portfolio Management

Technique Briefs

Footer

Contact Us

3232 190th Street

Prole, IA 50229

515.344.3290

About Us

KBP.Media provides services and resources to help your organization reach its outcomes, make your product team more effective, and your career more rewarding.  
Learn More

Inside Product

Get a weekly rundown of hand picked resources for product owners, business analysts, and product managers. 
Get Inside Product

© 2021 KBP Media · Rainmaker Platform

Privacy Policy

  • Home
  • About
  • Contact
  • Privacy Policy