In an ideal agile world, the team would work directly with a customer. When you have a small product that serves maybe three types of customer (new, expert, admin for example), and that customer is down the figurative hall, you might not need any product people. You can create short feedback loops with your customer. […]
We have many words for people who shepherd the business value of a product. The many words aren’t a problem, as long as we can all agree on what these various people are and they take responsibility for. When we don’t agree, we run the risk of not managing our strategy, not thinking in terms
You’ve got interdependencies across the organization for a given project or program to release a product. You can see demos. That’s not the problem. You need enough insight or prediction to start the marketing campaign or to create training videos or product documentation. You need some kind of milestone criteria so you know you can complete
Last August, back at the Agile 2018 conference, I had a chance to record a podcast with Howard Sublett. Howard is a terrific interviewer and a good friend and colleague. We spoke about Making Roadmaps More Agile. We had a blast. Several times, I surprised him with some of my thinking and experience. (Since I’m
Many organizations plan to create certainty, guarantees of some variety. What if we thought about agile planning as a way to manage uncertainty? When I look at long roadmaps with all the “must-do” feature sets and the pressure managers put on teams to commit to delivery, I wonder about this question: How well do we
I was on vacation last week, thinking about value. Depending on my role, I might think of value as: Delivery of a feature or story, assuming it’s the right level of quality and when I want it. Information about the story. This might include information from the team about what they think about this story,
Ryan Ripley interviewed me on his podcast, Agile for Humans 83 about Create Your Successful Agile Project. We had a blast. I didn’t stint on my opinions or on my experience with agile teams. One of those opinions was about teambuilding, which I wrote about in Creating an Environment of Teamwork. The other opinion (based on
Let me summarize what I’ve been talking about in these posts. The problem I’m seeing is that too many teams and organizations plan too much in too much detail too soon. Instead of architectural BDUF (Big Design Up Front), it’s project planning as BDUF. They expect one single person (a product manager or a product
The Value of Planning I like my plans. I have several levels of plans: a year or so specifically for books and workshops, a 6-month roadmap so I stay on track or change my track, a one-month week-by-week proposed roadmap, and a weekly plan. I use a kanban board to manage my weekly plans. (See
You’ve started thinking in feature sets. Maybe you’ve experimented with rolling wave plans inside one quarter, so you can change and replan as you need to support your project or program. You’ve discussed flow-based roadmapping as a way to create MVPs and MVEs, release smaller value more often so you can make better decisions. You