In Effective Agility Requires Cultural Changes: Part 1, I said that real agile approaches require cultural change to focus on flow efficiency, where we watch the flow of the work, not the people doing tasks. Too few organizations can do that. Then I offered three suggestions for teams in any lifecycle in Effective Agility: Three […]
For years, managers have been trying to find ways to make software product development faster and easier. As an industry, we’ve tried tons of things. Here are just the one I’ve experienced in the 70s, 80s, 90s: Structured Analysis and Design. (That was the precursor to Big Design Up Front.) The SEI’s Capability Maturity Model
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).