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
Consultants who make money speak at conferences. I love to speak. Give me a microphone—I am a happy person. I keep having to turn down speaking requests, both domestic and overseas. I would love to go, to learn and to meet people. Sometimes, I’m not available. More often, I can’t “afford” to do so. Often,
I’m a shepherd for the XP2019 and Agile2019 conferences. I read the proposals, offer feedback, and then shepherd the papers through to completion once we accept the proposals. I love reading experiences. I’m a total sucker for them. Why? Because they’re short stories that reflect the Satir Change Model, the image here. If you’re trying
I had a chance to be a guest on David Rael’s podcast, Developer on Fire, Episode 402 | Johanna Rothman – Learning and Delivering. We spoke about many things, including my early development career, how I got started as a consultant, my writing, and more. I hope you listen and enjoy it.
I’ve met a number of agile coaches recently. They tell me they’re hired as Scrum coaches or as Scrum Masters. They see their job as “better Scrum.” It would be lovely if that was their one and only job. However, many of these coaches work in organizations just starting a cultural transformation. Even though the
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
I had a wonderful time on the Agile Uprising podcast The Future of Agile. I had such a blast. Listen for the “expletive deleted” phrases. Yes, I actually said the words, “expletive deleted.” I said many other things that might feel contrarian to you. I thank Georgina Hughes, David Sabine for our discussion and Jay Hrcsko for
Several recent clients want help with these problems: Estimation isn’t accurate. Because the estimation isn’t accurate, management can’t predict when they can release anything. Managers can’t manage the capitalization (a way to move from expensing software to capitalizing it). Teams can’t seem to ever deliver a finished feature. The work in progress everywhere is quite large.