When Mark Kilby and I wrote From Chaos to Successful Distributed Agile Teams, we suggested teams add a text backchannel. Even when the backchannel is asynchronous, the information in it increases the value of all the team’s communication. The backchannel helps everyone see all the information. That helps all the team’s communication. Some of my […]
What happens when you use the word “estimate?” For many of my clients, “estimate”== guarantee. Which is not what those words mean. Even if you update the estimate based on data, too many managers still want to know, “When will it be done?” Emphasis on done. And, while managers might not remember the assumptions you
Your team says they use Scrum in two-week iterations. And, in order to “finish” everything inside the timebox, you don’t do any of these things: Refactor to simplify the code or the tests. Create automated tests. Use formal acceptance criteria on a story or for the iteration or the project. That means you have work
In my experience, too many projects are under too much pressure. The sponsors want all of the features, completed in too-short time, with no defects. And, if possible, the sponsors think the project should cost nothing, the team should not need any training, and the team can work in any way, regardless of the desired
I wrote about how to pick a driver in Part 1. In Part 2, I wrote about how you might finesse some of the constraints and floats if you can release frequently. What if you’re like this organization, Acme? Acme has been working towards agility for the last couple of years. However, they still have
In Part 1, I wrote about the origins of drivers, constraints, and floats. I needed them when we only could release the project once to the customers. You saw the questions that help people choose the project driver. What about the constraints and floats? I think of constraints as bounding the project inside the driver,
Do you know your project’s bounds? Do you know what your sponsors want from your project? For many years, I heard about the “iron triangle.” Sometimes, the triangle was “Scope, Quality, Cost.” Sometimes, it was “Scope, Date, Cost.” It was always three things out of a minimum of four possibilities. I never saw a triangle
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
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