Many of my clients are trying to use short feedback loops in agile approaches. That desire bumps up against their management’s desires for longer commitments. This continuum might help them think through their needs for commitment and innovation. High Need for Product Innovation and Change The more need for product innovation and change, the shorter the feedback loops need […]
Is it possible to balance the product innovation and feedback we need, with the commitment our management wants? Maybe. I tried to show my thinking for these questions in this series: When does it make sense to ask for or offer estimation and commitments? When does it make sense to ask for more feedback instead?
What if you don’t need to experiment to reduce risks? You may have technical risks in terms of getting it “all” done. Especially for a given release date. In that case, you have a low need for product innovation. Your planning feedback loops can be longer. I’ve seen this occur in some of these circumstances: A
What if you can plan for a few weeks or even a month-plus at a time? You don’t need the extremely short feedback cycles (hours to a day) because you’re not doing high innovation. You don’t need to change what the team does every few days. You can estimate and commit to maybe a month’s
I’ve been working with several managers at organizations large and small, who want to capitalize their software “earlier.” These managers have some strongly-held beliefs about the people: People are resources Resources can multitask on several projects at a time If “headquarters” does the difficult work, you can move the “grunt” work to lower wage areas
Do estimates make you slightly crazed? Maybe you want to roll your eyes at the organization’s confusion between your estimate (guess) and a commitment. You’re not alone. I wrote an article about estimation, How to give IT project estimates—and when not to estimate at all. If you’ve ever struggled with estimating work, give it a read.
My most recent article on projectmanagement.com is 3 Questions to Ask Before Estimating an Agile Program. In both Create Your Successful Agile Project and Agile and Lean Program Management, I talk about the reality of estimates in most settings. The question is what kind of an estimate does your project or program need? I’m not opposed to
I have a new column up on projectmanagement.com, 3 Questions to Ask Before Estimating an Agile Program. Often, management wants an estimate for the program. I suggest that before a program manager ask the teams to estimate, she learn the answers to these questions from management: How much would you like to invest in time,
Many organizations want to see an estimate for your program (a collection of projects with one business deliverable) before they fund it. So, the teams might spend significant time estimating everything the product owners and managers hope will be in the product from today’s perspective. Or, you might try a “sprint zero” to understand the
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