People can get very philosophical when talking about agile best practices. And often, a product manager’s discussion of their company’s agile philosophy is so abstract and high level that you’re left wondering: What exactly does this organization’s agile development process actually look like?
So, let’s talk nuts and bolts.
Let’s assume you’re a product manager and you want to use agile to improve your team’s process, speed up your development cycles, and deliver better products. There are plenty of agile experts whose work you can consult to help get you started. We’ve written pretty extensively ourselves about how to use agile development to improve your product roadmapping.
But for this post, we’ll discuss a handful of agile best practices we think are essential to the process—and which we’ve seen many product teams neglect.
1. Establish a product owner for the agile team—and make sure they fully understand their role.
Every agile development team needs a product owner. In most cases, this will be a product manager. And this isn’t merely a vanity title. Being a product owner has real meaning, which you should understand if you want your agile process to work.
Your responsibilities as a product owner include:
- Determining who will be on your product team, and shielding the team from external interference. (More on this below.)
- Setting the vision for your product team, so they understand what’s expected of them.
- Keeping your team’s focus tight—which usually means a focus on the next two or three sprints, and only on the epics and stories needed for those sprints.
- Making yourself available at all times for your product team during the sprint, in case they have questions or need guidance. If you can’t be available for the duration of a sprint, then you can’t be the product owner—you’ll need to transfer that responsibility temporarily to someone else.
2. Establish the rest of your agile team—keeping out all but those integral to your development plan—and determine and assign their respective roles and responsibilities.
One misstep a lot of product managers make in building their agile product management teams is in allowing the wrong people to join, and neglecting to include some of the right people.
Many product teams, for example, forget to include QA resources. This can lead to bugs making it into the demo—and, ultimately, to rework, which should happen as little as possible in an agile environment. The agile process itself is designed to avoid such backtracking and needless extra work.
Many product owners also mistakenly include too many people on the team, or at least in the product demo at the end of a sprint. Shouldn’t we invite someone from sales, their reason, or marketing?
But during a sprint, your product team needs to be focused on building—not on fielding a request for new features from sales or answering a marketing rep’s question about why certain epics have been prioritized over others on your product roadmap. There are places for such conversations—but a product team’s sprint isn’t among them.
To build your process on agile best practices, your team should include:
- A product owner (whose primary responsibilities I’ve outlined above and will have more to say about below)
- A scrum master (whose role it will be to translate the epics, stories, and other items on your sprint list into actionable tasks for her developers—and to ensure that the dev team is fully deployed at all times, with no wasted resources)
- Your QA resources (who will be responsible for testing the items in development before they’re presented to the product owner in the sprint demo)
3. Translate the strategic elements of your roadmap into your sprint list—and review those details with your team to ensure clarity before the sprint begins.
Product managers often ask whether or not they should share their year-long agile product roadmap with their development team. If the team is going to be focused on short-term sprints, they wonder, should I risk confusing them with a longer-term strategic vision and details they won’t be working on for many months?
Tweet This:
“Translate the strategic elements of your roadmap into your sprint list—and review those details with your team to ensure clarity before the sprint begins.”
Generally speaking, yes, a product manager should share her product roadmap with development—provided that roadmap is built at the strategic level, is easy to view, and isn’t merely a long list of features and to-do items.
But in an agile framework, the product manager (or product owner) should present this roadmap only as a way of strategically orienting her product team to how the stories and features they’ll be working on roll up to a larger, more strategic plan for the product.
Then the product owner should shift focus from the strategic to the tactical—and review with her team the epics, stories, and other items they will be working on for the next sprint (maybe two), so they are able to keep their focus tight and on-mission.
This means that by the time you’re done with your sprint kickoff meeting, your scrum master and development team should understand exactly what you need from each story listed on the upcoming sprint. This leads to the next agile best practice…
4. Clear as many distractions as possible for your team as soon as your sprint begins.
During your sprint—which in most cases will be about two weeks—your development team (including your QA team) should be focused exclusively on the sprint items their scrum master has assigned to them.
In other words, among your roles as a product owner will be to build a wall around your product team during every sprint—allowing them to work on those sprint items free from outside distractions.
This is why it’s so important that you ensure your product team is clear on what you’re expecting from every story, every feature, etc. before the sprint begins. One of those distractions could be that they realize mid-sprint they don’t know what you meant with a certain story—and they have to ask you for guidance at that point.
Remember, once your team starts a sprint, that’s it. If you’ve done your job as a product owner, you’ve made sure they know exactly what they need to do, and you’ve also allowed them as much of a development cocoon as is feasible (you can’t prevent all outside distractions)—so they can deliver their best work before the sprint ends.
5. Don’t forget your retrospective!
Here’s another common mistake in agile shops. Even the most well-intentioned product managers skip the all-important “retrospective” at the end of a sprint because they believe they’re just too busy to have that meeting, or because they simply forget to call it.
The whole point of agile development is that you and your team are constantly learning from your processes, analyzing what’s working and what isn’t, and adjusting those processes to make them better next time.
Tweet This:
“The point of agile is to constantly learn from your processes, analyze what’s working and what isn’t, and adjust those processes to make them better next time.”
That’s why the agile retrospective meeting is designed to be so short—maybe just 20 minutes. No matter how quickly things are moving in your organization, you’ve got 20 minutes, don’t you?
Take that time, with your team, to review your last sprint. Talk about what worked, where your process might have fallen short a bit, or even where it completely fell apart. Then discuss how you can apply what you’ve just learned to improve your development process for the next sprint.
Because there’s always the next sprint.
Have more best practices for agile teams? Share them in the comments below.
