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
What risks does your project have? Do you need feedback loops so you can: Cancel the project at any time (to manage schedule and cost risks. Assess technical risks so you can rework the architecture or design to manage feature set risks. Manage what you release to customers so you can manage defect, feature set,
The original signatories of the Manifesto for Agile Software Development wanted to solve these specific problems: How can we: Bring more adaptability to software development? Stop “plan the work and work the plan” thinking? Release something of value earlier? Especially since teams now had these levers, from the iterative and incremental approaches: Prototype something for
I discussed the origins of the agile approaches in Part 5. In this post, I’ll discuss how you can create an agile approach that fits your context. Why should you create your own agile approach? Because your context is unique to you, your team, project, product, and culture. You deserve an agile approach that helps
Which levers does your team need to manage risk in your project? Do you need to cancel the project if you can’t finish a phase? You might not have the time. You might not have the ability to do this project. That’s the point of Serial lifecycles in Part 1. Maybe you need feedback from
So far, we’ve discussed the lever of canceling a project at any time with the serial lifecycles in Part 1. That’s assuming you replan and/or cancel. We added another lever of looking for more feedback with iterating over the requirements in the iterative lifecycles in Part 2. Teams have another lever. They can release increments
Back in Part 1, I wrote about how stage-gate approaches were as agile as we could use at the time. We had one delivery, so our agility was about canceling the project if we couldn’t finish it. However, some smart people also realized that we had another lever, aside from estimation, to replan the project.