A client wants to know how best to calculate their software capitalization. They had a “standard” approach when they used waterfall. They no longer have all waterfall projects. They’ve started to use agile approaches. And, the projects don’t all look the same. Being somewhere in the middle means they’re having trouble reasoning about capitalization. Why […]
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.
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?
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
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.
I started this series asking where “Agile” was headed. Part 1 was about the 4 big problems I see. Part 2 was why we need managers. This part is about how people want a recipe, The Answer, for how to get better at “Agile.” Before we can address what an answer might be, your need
In Part 1, I wrote about how “Agile” is not a silver bullet and is not right for every team and every product. This post is about how management fits into agile approaches. Too often, managers think “agile” is for others, specifically teams of people. Teams need to figure out how to manage their WIP,
I spoke at Agile 2019 last week. I had both a great time and a heart-rending realization. The great time was meeting and reconnecting with people. The heart-rending realization is our industry is in big, big trouble. Here are my thoughts and where I think the “agile” industry is headed. Problems I See with “Agile”
I’ve been thinking a lot about planning recently. Many of my clients want to create long-term plans, based on data with short validity, even for products in a high state of change. I suspect the first question is how much change do you need in your product, not how good your information is, or how