There was a fascinating Twitter conversation last week when I was busy writing other things. (I also find Twitter to be a difficult-for-me arena to have a conversation. I need more than 140 characters.) The conversation started when Neil Killick tweeted this: orgs need coaches not because “agile is unintuitive”, but because effective sw delivery […]
I met a team recently who was concerned about their velocity. They were always “too late” according to their manager. I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they
Two development managers were arguing: “I need Tom on my team,” Chase said. “He has the specific knowledge I need. We’re not going to be able to release unless we get Tom on my team.” Pierce retorted, “You can’t have him. He’s working really well with my team. He likes my team. Forget it.” They
This post is what you do when you are a program manager and not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change? (In the program management book, I will talk more specifically about change and what to do. This post is the highlights.) Project
If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want
What do you do for geographically distributed teams, if you want to move to agile? First question: does the team want to move to agile? Or, does the management want to move to agile? I am serious. I might take the same actions, but for different different reasons. In either case, the team needs to
The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Why? For several reasons, but the first one is so you can change the project’s priorities. The second is so you can change the project portfolio. The third is to get feedback on what you’ve done. Okay, you can exchange
The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in
I’ve outlined five potential costs of delay in the previous five posts: The delay from not releasing on time, part 1 The delay from multitasking,part 2 The delay from indecision, part 3 The delay from technical debt, part 4 The delay from other teams as part of a program, part 5 The real problem is
Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release. One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all