So far, this series has focused on smaller efforts, such as one or two products or one or two teams. But what if you have a larger effort, where several teams need to collaborate to deliver the business value? That’s a program. (I wrote Agile and Lean Program Management: Scaling Collaboration Across the Organization to […]
I started this series bemoaning the fact that we have too few product managers. That leads to no product leaders for a team. Worse, some teams have either strategic product thinkers or tactical thinkers—but not both. Instead, we can consider several possible product value teams to prevent insufficient product leadership. I already discussed the Vertical
I had a wonderful time discussing management myths, fake agility, and how to get to done with Kumar Dattatreyan. He runs the Agile Meridian podcast. You can also find the video here: https://www.youtube.com/live/_L4TnfDeQAs?si=SZs1oLuL6faYG7Bg Kumar was a terrific host—we had a delightful conversation. We discussed several of my books: The Modern Management Made Easy books (the
As far as I can tell, all organizations have the appetite for more work than they have people or time to do that work. It does not matter if the organization is one person or thousands. We all want to accomplish more than we have people. That’s why we need a product vision to drive
I started this series by saying a team can create a useful project charter in less time than you think. So what prevents teams from doing so? Too often, the project is not ready. The team might be ready, but the project is not. In effect, the project starts with scarcity. (I used to think
Do you use schedule or tracking tools to predict the future? None of them can predict the future. Worse, too many of them hide the past, especially the recent past. A schedule or tracking tool can only predict one thing: the first possible date you cannot prove you cannot finish the project/story by. Let me
So far, I’ve addressed how a project charter can help a team start a project fast and well. That’s why the project charter must clarify product vision, the various project risks, and product risks. And, it’s equally important to know what done means. If the team does not know how little they can do to
In Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project, I explained how project risks can affect the team’s approach to the work. But project risks are not the same as product risks. Product risks are about the need for product innovation. The more innovation this product needs, the more
Let me set the context for this post about the project charter: By now, the team knows what it has to accomplish because they have a product vision. The next question is: How will the team manage their risks to achieve those outcomes? That’s where I recommend a team define its project driver, up to
Does your team have a project charter so they know what to do for this project? I see too many teams try to start work without one. That leads to feature factories, apparently random work that does not add value, or worse, a product that’s partly done in too many areas. Teams start without project