If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas. You have a couple of preconditions: The teams get to done on features often. I like small stories that the team can finish in a day or so. The teams continuously integrate their features. Frequent features […]
A cargo cult occurs when people adopt rituals expecting some good behavior to occur. They really don’t know why they are doing these rituals and don’t understand the reasons behind them, yet they keep doing the rituals expecting great results. In this article, I’ll give two contrasting examples that I’m familiar with: Project A talks
I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective. There is a problem with commitments and the need for
In agile, we separate the Product Owner function from functional (development) management. The reason is that we want the people who can understand and evaluate the business value to articulate the business value to tell the people who understand the work’s value when to implement what. The technical folks determine how to implement the what.
The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management. I hope you like the information there. If you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.
Many product owners have a tough problem. They need so many of the potential features in the roadmap, that they feel as if everything is #1 priority. They realize they can’t actually have everything as #1, and it’s quite difficult for them to rank the features. This is the same problem as ranking for the
Do you have a title such as product manager, product owner, or business analyst? We hear these titles all the time. What does each do? Here is how I have seen successful agile projects and programs use people in these positions. Note that I am discussing agile projects and programs. The product manager creates the
Agile product leaders (product managers, product owners, and business analysts) all have one goal: How do I support the team in their quest to deliver better and faster? Product leaders do this by helping the team plan with minimums, and continually replan. These two workshops help you do that. I offer two versions: for teams,
Several years ago, I had a senior VP as a client. He wanted his managers to work as more of a team. He thought they were not working together for the good of the company. I asked him why he thought that. “When they estimate, they don’t work together on an estimate. They each estimate
As more of my clients transition to agile, many of them have a fascinating question: How do I assess who is doing what on my team? When I ask why they want to know, they say it’s all related to reviews, rewards, and general compensation. They are still discussing individual compensation, not team compensation. When