I’m conducting a Hudson Bay Start for a new offering: a Consulting Workshop. What do I mean? Several people have asked me for help in creating or sustaining their consulting practices. Since I’ve done that for 25 years, I know what works for me. I know the strategies behind how I work. We can translate […]
I spoke with a project manager recently. She told me her story. I used to facilitate project teams as a project manager. Why a project manager? Because the project had a beginning and an end. We had (and still have) too many products to keep the same teams on them for a long time. For
I wrote about how I felt about milestones after achieving a significant milestone last week (How Do You Feel When You Achieve a Significant Milestone?) I specifically wrote about my feelings. During a discussion on LinkedIn, a reader suggested I start with the last sentence I wanted to leave my readers with. Then build back
I spoke with an agile coach whose team works in flow, similar to this board. They don’t use iterations—they plan on demand. The column on the left, “Stories to Workshop” is their backlog refinement column. Recently, the team decided they need “minimum” WIP (work in progress) limits. Especially on the Workshop column. Why? Their product
Do you have trouble fitting “all” of the necessary work into an iteration? Your managers might want to push you to do more. Or, the product owner thinks you can do more. Or, the team wants to do more (see Beating a Team’s Goal.) Agile approaches are not about doing more. Agile approaches encourage us
Does your team have to keep two sets of “books”? You have an agile roadmap to see where you’re headed. You have a smallish backlog of the near/upcoming work. You’re delivering on a frequent basis. And, someone on your team keeps a Gantt chart because a manager wants to see the team’s progress in a
Part 1 was about seeing the value in the various projects. I called the value stream a product so that people would think about who would use it and why. I suggested that we stop work on specific products when you have more products than teams. That would allow you to work on other projects
Note: I had a technical problem with my site and lost this post, even though I had published it. This is the restoration. If you subscribe to my feed, you might see this twice. I’ve been working with some clients who are trying to find the magic way to slice and dice their project portfolios.
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
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