Too many teams have overloaded Product Owners. The teams and PO have trouble connecting the organization’s strategy to what the teams deliver. The teams, PO, management, all think they need big planning. Too often, the POs don’t do small-enough replanning. They’re not living the principles of the agile manifesto. That insufficient collaboration means the PO […]
Hours of Overlap, the First Principle of Successful Distributed Teams Do you work in a building with other people? You might think you’re part of a collocated team. Here’s the test: Is everyone on the team within 30 meters (or seconds) of walking to each other? If so, yes, you are collocated. If not, no,
I started this series with the question: If we have teams for all other aspects of an agile approach, why wouldn’t we want the product owner to also work as part of a team? Could a team reduce the feedback loop durations? In Phase Gate or Other Serial Approaches… When projects use a phase gate
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