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.
If you’re like many of the teams I meet, you’ve sort of got a handle on things. You can release. Your product mostly works. And, then Something Happens. And, your team has trouble recovering. That’s brittleness in the system. You can build resilience as a team. In this post, I’ll summarize how your team can
This series is about helping a team create a less brittle environment—more resilience. Part 1 was about individual work. This part is about shortening feedback loops. Brief description of the problem at a recent client: Person A checked in code that broke an “unrelated” part of the system. I’ll call this checking in code in
In Costs of an Agile Approach for Hardware Products, I suggested that an iteration-based approach for hardware was too expensive. I focused on the actual development costs. Let me talk a little about the team and alternatives here. What Does a Hardware Team Look Like? Agile software teams are cross-functional and interdependent. The team is
A potential client called me. “What’s a good tool to see the state of my projects? I need a tool.” I asked, “What problems do you see?” “Everything is late. No one’s synchronized. I can’t tell where the projects are.” “How many projects do you have in progress?” “At least 100.” (I was pretty sure
I suggested ways to think about more agile budgeting in part 1. I didn’t tell you why. How do you budget your own money and time? If you’re like me, you have a plan for the year. I evaluate the plan—my products, services, and clients—on a regular basis. I always evaluate monthly. Sometimes, I evaluate
Too many teams have overloaded Product Owners. The teams and PO have trouble connecting the organization’s strategy to what the teams deliver. The teams, PO, management, all think they need big planning. Too often, the POs don’t do small-enough replanning. They’re not living the principles of the agile manifesto. That insufficient collaboration means the PO
I started this series with the question: If we have teams for all other aspects of an agile approach, why wouldn’t we want the product owner to also work as part of a team? Could a team reduce the feedback loop durations? In Phase Gate or Other Serial Approaches… When projects use a phase gate