Susan, a new-to-the-company program manager, could not understand why Product A was so late. The teams used a well-known agile approach. They weren’t working on anything else except for production support. Yet, even though the teams worked hard, not one team could meet any of their deadlines. The teams were unhappy with their progress. They […]
In Effective Agility Requires Cultural Changes: Part 1, I said that real agile approaches require cultural change to focus on flow efficiency, where we focus on watching the work, not the people. Too few organizations can do that. But teams can change how they work—in any approach. Here are three suggestions to emulate flow efficiency
I continue to work with people who have trouble with their agile approach. They tell me their relative estimation isn’t working for them. They continue to roll over items, from sprint to sprint. They’ve rolled over some items for six months or longer. The people feel demoralized. And the Scrum Masters or agile project managers
I see many teams and team members who say, “Agile stinks. It’s a way to force me to work too fast and not finish anything.” When I ask people what’s happening, they say: We’re doing an agile death march because someone else already told us what we have to do and the date it’s due.
Regardless of whether you work inside an organization or you work for yourself, the start of the new year allows all of us to reset and restart. That means too many of us think we need to “plan” for an entire year. Before you consider an entire year, reflect on last year: How much of
In How Centralization Decisions Create Friction, Increase Cycle Time, and Cost Money, Part 1, I discussed how removing support staff for departments and managers created longer cycle times. (And sometimes, increased friction so much that people could not easily do their jobs.) Removing those support staff was one indication the companies fell into the Economies
I have a new book: Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility. I wrote it because I’m concerned about what I see in too many supposedly agile teams: Crazy-long backlogs and roadmaps. Those create a serial lifecycle approach with too little experimentation. Worse, sometimes the team doesn’t demo or deliver.
Susan, a senior leader, wants faster throughput. She can see people working hard. Yet, all the projects seem to take much longer than anyone expects. They’re doing a lot of the right things. No team is multitasking—the teams work on one project at a time. And the teams manage their inside-the-team WIP (Work in Progress).
Up until now, when thinking about risks, I defaulted to the risks in the project pyramid. That’s because each project offers different value over the product’s lifetime. (See Product Roles, Part 4: Product Orientation and the Role of Projects for images of why we want ever-increasing product value, but why we might space the projects
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