I thought watermelon status was something “everyone” knew about. But it’s not! Read No More Watermelon Status Reports: How to Use Stories to Explain Project State. That’s a persona-based approach to help other people understand the project’s reality. You also might like Velocity is Not Acceleration to see charts and data I use and recommend. […]
Several people on social media have denigrated the terms “project manager” and “program manager.” These people claim there is no need for either role in an effective team, especially an agile team because the team can manage its own deliverables. While some agile teams can manage their own deliverables, that’s not the only role for
I see too many teams feel frustrated because their managers say the work takes “too long.” (The team feedback loop is the inside of the onion for how agile the organization can be. See Multiple Short Feedback Loops Support Innovation.) The longer the work takes, the more pressure managers exert on the team and the
A colleague unfamiliar with lifecycles or agility asked, “How can we use sprints in this approach?” and pointed to a phase-gate approach with documentation deliverables after each phase. It looked just like the serial lifecycle in the image on the left. (That’s because a finance person drew the lifecycle.) I said, “You can’t use ‘sprints.’
Joanie, a new VP Engineering, joined the company a couple of weeks ago. Her boss, the CEO, wants to know how long it will take engineering to finish all the projects. Joanie asked the various leaders these questions for every project in progress: When did you start this project? Are you still working on this
The larger your product, the more likely you have components teams. I often see component teams because of the architecture of the product. In this first image, the Integrated System Program, the rest of the product uses the Platform of Common Services as components. Also, the teams find it tempting to think of the common
Continuing the series on dependencies… Maybe you don’t have the problem where the team creates internal dependencies with their process. And you don’t have to wait for someone outside the team to approve your work—an organizational process. But you do have a combination of platform/component teams and feature teams. I see this most often in
Does your organization have an enterprise architect or Chief Product Person? We create these positions to check that the teams don’t try to implement something “wrong.” However, a single person in this position creates bottlenecks and dependencies. (A committee might create even tighter bottlenecks.) Those dependencies slow the work. If a person delays the work,
Even when managers try to create cross-functional teams, the teams still have dependencies. Dependencies slow and make finishing the work more difficult. Too many teams have a built-in dependency creator—code review. When we take time to perform code review after we write the code (or the tests), we create dependencies between the people on the
Over the past couple of weeks, several potential clients have discussed problems they want to fix: What are the teams doing, at a detailed level? (The managers want to know when the teams will finish certain features in the short term.) How can they plan for six months at a time? (They want to understand