In my last post I talked about how Scrum can generally address some key challenges faced by product managers. But we didn’t get into the details of how Scrum can be applied, and that’s really what we’re talking about today.
First, let me state that Scrum can be successfully applied to product management whether they’re lone-wolves or part of a product management team. This is important to note as the majority of product managers out there are either lone-wolves or part of teams with 3 or less people, below the threshold typically recommended for software development teams using Scrum. But we’re not talking about software development teams – we’re talking about product managers, and we’re a bunch of magical sparkle ponies, so there! I’m only half-kidding about the sparkle ponies, but trust me, this can work.
Second, let’s talk about those other folks doing Agile with Scrum. How does Agile Product Management with Scrum fit into the picture if both your development and marketing teams are already doing Scrum? That’s a great question! In that situation, you could potentially wind-up with 3 organizations running 3 different sprint schedules and each having to spend time in each other’s sprints as key stakeholders. Thankfully, a bit of forethought and experience in these situations has already produced some guidance. Let’s talk about the relationship with your development team first.
You are a product manager. You provide leadership and vision. And you can’t lead by being a step behind everyone. So for this simple reason, you need to schedule your product management sprints so you have your planning meeting ahead of your development team’s planning meeting. And by “ahead,” I recommend that you schedule your product management sprints to run on an in-between schedule with your dev team so your sprints and your dev team’s sprints overlap.
This is much more productive than trying to schedule your PM sprints and dev sprints to have the same start and end dates. If you do that, you don’t give yourself enough time to actually plan and execute some of the work you need to feed into the dev team’s sprint plan. Also, it’s convenient to have the dev team’s sprint reviews occurring ahead of your PM sprint planning so you have a little time to digest what they delivered and any stakeholder feedback.
The example schedule above shows a PM team sprinting such that their sprints begin/end in the middle of a dev sprint. It doesn’t have to be exactly splitting a dev sprint. Actually, there are two pointers to glean from the example:
- Your PM sprints don’t have to be the same length as your dev sprints. And, as with Agile Marketing, I suspect that Agile Product Management teams will want to use longer rather than shorter sprints.
- Stagger your PM and dev sprints so PMs are planning at least a week ahead of dev planning so you have time to prepare your input and guidance.
When it comes to timing with the marketing team, it works fine to have their schedule set up so they’re sharing planning dates with either the PM team or the dev team. Here are some reasons to choose one versus the other:
- If your marketing team often requires your dev team to work on marketing deliverables (like metrics or promos built into your product – very common with SaaS), then have marketing planning sync up with PM planning. Preferably have marketing as a stakeholder in the PM planning meeting and then have PM attend marketing planning as a stakeholder.
- If your marketing team simply wants to know when product value props are being delivered so they can plan their marketing activities in short order, then have marketing sync up with your dev team. Preferably have marketing as a stakeholder in PM and dev planning and in dev sprint reviews. That way marketing can produce work just-in-time based off of actual deliverables and not vaporware.
So let’s update the previous example schedule, this time adding the marketing team:
As you can imagine, if so much of your company adopts Agile using Scrum, you’ll probably wind up finding ways of streamlining things – like sharing sprint planning and review sessions when they happen to fall on the same day. Or at least the part that involves exec stakeholders before they get sick of Scrum meetings. But really, this would be an awesome problem to have!
Whatever you do, do NOT simply to roll all of your PM work into your dev team’s Scrum process. This may seem tempting, so why not?
- You need to stay ahead of dev and drive the direction.
- You need to organize and execute a lot of work beyond what you need to do for the dev team.
- You need to be working with a lot more stakeholders than are typically involved in a dev team’s sprint planning.
Now there’s a lot of additional details we could discuss about applying Scrum to Agile Product Management, and we’ll get to some of them in future posts. But then we’ll also talk about applying Kanban to Agile Product Management. See how fun this can be?
In the meantime, are any of your using Scrum for product management today? For those who aren’t but who work with dev teams using Scrum, how different would your world look if you used Scrum like we talked about above?