Dave, the tech lead, was trying to use an agile approach with his team. Four of the people worked together in a team room in Waltham, Massachusetts, a Boston suburb. Two people worked from their homes in New Hampshire, and one person, the product owner, worked from her home in Indiana. Their agile approach wasn’t […]
Summary: Too often, customers have a “fake certainty” about the problems they want to solve. They might not have defined the real problem, but they have frequently defined the solution anyway. The risk is that we might build the wrong thing. When the product owner works with the customers to define the problem, then works
Summary: Many managers and distributed team members think that if they just had the right tools, they could make some agile approach work. Maybe, but tools only enhance the work of a collaborative agile team. Before you select tools, make sure you have people who can work together and have enough skills and capabilities for
In our previous article, we discussed the importance of sufficient hours of overlap in managing a team’s workspace. As a reminder, here are the four components we see that need to be managed in a distributed team workspace. Sufficient hours of overlap in everyone’s workday. Sufficient communications technology that supports everyone equally in synchronous and
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
As I’ve written these product role posts, a number of you have asked about how to use component teams. You might have a security team. Maybe a performance team. Regardless of my desire, you have component teams. You want a more agile approach to manage the interdependencies among the teams. You want to be able
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
An agile approach requires a cross-functional team. That means that everyone on the team focuses on the same intent. That intent might be an entire product. It might be a feature set as part of a larger program. But, the team focuses as a team. That cross-functional team is a product team or a feature
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.
Dan, a product owner felt as if he was stuck between the proverbial rock and the hard place. His managers wanted “everything” in the next release.He knew the team couldn’t possibly deliver all of it. He hoped to get most of the features. He met with Polly, the agile project manager, and asked how much