What might we gain if we join our engineering counterparts in using Scrum, Lean, Kanban, and other Agile practices on our own work? Agile proponents tell us that we’ll improve productivity, competitiveness, quality, and job satisfaction by going Agile. Isn’t that what all of us want?
This is the first in a series of articles that explores what it might really mean if we applied Agile principles and techniques to software product management. Up until now we’ve mostly adapted our current practices to work with Agile software development teams.
We’ll start with some big questions to get us all thinking. And included below is also a quick poll to gather your input – what’s so crazy it couldn’t possibly work? And what has enough promise that you want to know more about how it might work?
Along the way, further posts will discuss how the process might change, what team might form to support the process, and how we can apply some Agile techniques to manage the way the team works.
Agile techniques and how they might apply to Product Management
The journey to Agility generally starts with chopping big projects into smaller chunks.
Sprints or Iterations
The software industry seems to be settling into 2-week sprints. In order to have work flow across functional boundaries, it’s helpful to synchronize sprint cadence. So what are the implications of breaking product management work into two-week chunks, and re-visiting progress and priorities every two weeks? What are the larger efforts that would need to be decomposed to fit this cadence?
Implicit in this technique is that we only accept into the sprint what is ready to be worked on and can be accomplished. But here’s an issue: that involves saying “no” to some number of requests that don’t fit. Are you empowered to say “no”, or at least “not now”?
Agility also requires that we look at how the people doing the work are organized.
In Development, this means that small teams are composed of developers, testers, and designers. It’s helpful if team members are T-shaped people. The team plans together, works together, and is accountable for results together. What would this mean in product management? Might it mean that your product management team contains some combination of Product Owners, Product Business Managers, and Product Marketing Managers? Research and/or data analysts? Business analysts? Who would be on your product management team? How many products could your team handle, working together?
Next, we look at how we manage the work across the team and during the sprint.
If you’re working as a team, it would be helpful to have daily stand-ups to coordinate the work. One of the interesting ways that Agile development teams begin working *as a team* instead of a collection of individuals is to help each other out on specialized tasks. Wouldn’t it be awesome if someone on your team offered to help you with that sales presentation, or with gathering data for the business case?
Kanban or task boards
One technique often used within daily stand-ups is to review the Kanban or task board. Task boards (physical or virtual) make the work visible. Knowledge work is by nature invisible, so managers have a hard time understanding to what degree we’re overloaded. What if your product management team used a task board to manage the work they committed to in each sprint? What might you learn about how long things take, what gets blocked and why, and where bottlenecks occur? Could you use classes of service to help manage urgent requests?
The backlog in Scrum represents all the work that could be done on the product. Let’s apply that to our own product management work. Product managers are used to having a big “to-do” list. But Lean thinking tells us that long queues are not desirable; high-value work should flow through the system so we can harvest that value. Lower value work is – well, lower value. Should it be done at all? How do we shorten our own backlogs? Can we conquer the “tyranny of the urgent“?
And to wrap up, Agility also asks us to reflect on the work and the process just completed, to see what might improve the next round.
How much time does your product management department devote to improving the product management process, from concept to cash? Part of Agility is being responsible for making our own processes better. Could we incorporate retrospectives and set aside the time to not only identify potential changes but actually implement them?
What about it? What Agile technique would you like to try in product management? What technique is so crazy it would never work? Answer the quick polls below, and leave some comments!