One of the experiences people miss in distributed teams compared to collocated teams is the ability to serendipitously bump into other team members or just other people. They like the idea of having random encounters to share what they did for the weekend or, more importantly, discuss problems they are struggling with at work. Sometimes […]
At the Influential Agile Leader workshop earlier this year, I led a session about scaling and how you might think about it. I introduced the topic and explained that “scaling” might not be the answer. My experience is that when people use frameworks for larger efforts, they experience these unexpected side effects: The framework actions
If you wondered why I’ve been so quiet here on the blog, it’s because I’ve been managing my own product development. This announcement is that Esther Derby and I have teamed up to offer online workshops based on Behind Closed Doors: Secrets of Great Management. Go to Your Management Mentors to see our first offering: A
I’ve been thinking a lot about planning recently. Many of my clients want to create long-term plans, based on data with short validity, even for products in a high state of change. I suspect the first question is how much change do you need in your product, not how good your information is, or how
I suggested ways to think about more agile budgeting in part 1. I didn’t tell you why. How do you budget your own money and time? If you’re like me, you have a plan for the year. I evaluate the plan—my products, services, and clients—on a regular basis. I always evaluate monthly. Sometimes, I evaluate
Too often, organizations want to budget for an entire year. The managers run around for two or three months in advance of that fiscal year, attempting to predict a ton of things: Estimates for not-well-defined projects or features, Capital equipment or tool needs, “Headcount” aka, people needed. Then, the organization doesn’t finalize the budget until
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
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
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