You’ve got an impossible project. You have no flexibility. The project is a fixed-price, fixed-scope, fixed-date project. And, you have a specific team to do the work. (There are other impossible projects. Such as when you have a collection of people who multitask among several projects.) Can an agile approach save these projects? No. An agile […]
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
What Happened to the Beautiful Plans? (They Became Experiments) Tim, a senior manager, loved seeing plans for work and roadmaps. Then, the organization decided to Embrace, Not Manage Change. Tim wasn’t sure how to track the work. This image helps me frame the need for an agile approach. (See the blog series: Where I Think “Agile” is
Do you have trouble fitting “all” of the necessary work into an iteration? Your managers might want to push you to do more. Or, the product owner thinks you can do more. Or, the team wants to do more (see Beating a Team’s Goal.) Agile approaches are not about doing more. Agile approaches encourage us
Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons: “Beating” the last sprint goal Assisting the PO in a forecast of when things might be done. Let’s examine these ideas. Clarify Story Points Why even bother with story points?
Create Your Agile Culture: Embrace, Not Manage Change Stu, a manager who’d been successful throughout the years by managing risks and managing change was concerned. “I don’t want to move fast and break things,” he said. “I don’t want to move too slowly. I’d like to move fast. But I don’t want to break anything.”
I’m not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.) Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish
Does your team have to keep two sets of “books”? You have an agile roadmap to see where you’re headed. You have a smallish backlog of the near/upcoming work. You’re delivering on a frequent basis. And, someone on your team keeps a Gantt chart because a manager wants to see the team’s progress in a
It’s time to wrap this series. I started asking if you actually need an agile approach in Part 1 and noted the 4 big problems I see. Part 2 was why we need managers in an agile transformation. Part 3 was about how people want a recipe. Part 4 was about how “Agile” is meaningless
I started this series asking where “Agile” was headed. (I didn’t like what I saw at the Agile 2019 conference.) Part 1 was about the 4 big problems I see. Part 2 was why we need managers. Part 3 was about how people want a recipe. This part is about what “Agile” or “agile” means.