Several of my clients have intertwined problems. Everyone agrees they want innovation: Which products and services the organization offers. (The project portfolio) What features the product offers, or the problems the product solves. (The product roadmap) In the team, to solve the problems in a way that will attract users/buyers/customers. (The team’s backlog and how […]
I spoke with an agile coach whose team works in flow, similar to this board. They don’t use iterations—they plan on demand. The column on the left, “Stories to Workshop” is their backlog refinement column. Recently, the team decided they need “minimum” WIP (work in progress) limits. Especially on the Workshop column. Why? Their product
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
Do you have trouble fitting “all” of the necessary work into an iteration? Your managers might want to push you to do more. Or, the product owner thinks you can do more. Or, the team wants to do more (see Beating a Team’s Goal.) Agile approaches are not about doing more. Agile approaches encourage us
A colleague asked me about the kinds of documentation the team might need for their stories. He wanted to know what a large geographically distributed team might do. What was reasonable for the stories, the epics, and the roadmap? How little could they do for requirements documentation? I start with the pattern of Card, Conversation,
I started this series discussing the issue of the various product-based roles in an agile organization. I suggested a product value team because one person becomes a bottleneck. One person is unlikely to shepherd the strategy and the tactics for a product. And, batching the product planning in one-quarter chunks doesn’t encourage us to reduce
Many people in the agile community promote a product orientation over a project orientation. That’s possible because an organization has product or feature teams. That works until you have more products than teams. That’s when you might still need projects to accomplish everything. If you keep teams together, you can still use projects in a
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
Especially when we use agile approaches, we want to be close to our customer. If you’ve ever had a chance to sit with a customer, you’ve learned how effectively (and fast!) the team and the customer learn from each other. And, too few teams have any access to any customers. Most of their customer information