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
Glen Alleman seems to have nailed it, with Alert – Was Poor PM the Root Cause of ACA Difficulties? Among the many problems: No overall program manager No way for stakeholders to know what Done looks like (no release criteria) No replanning I’m a huge fan of rolling wave planning. (Read Starting with Rolling Wave
I have posted several slideshares for your reading pleasure. You won’t get the pleasure of my humor, eye rolling and jokes. Nope, for that you would have had to hear me speak. In September, I spoke at AgileSoCal, and had an interactive talk, Agile Teams and Collaboration: What’s New About Agile? I have a small
If you read my most recent post, Comparing Teams Is Not Useful: Exposing Another Management Myth and the comments, you will see that I rant about the business of normalizing story points for predicting cost or schedule for a program. That led to several comments re SAFe for programs or other frameworks or lifecycles for
This is the last in this series of organizing the agile program management posts. It won’t be the last of all the posts, it’s just the last in the series of organizing posts. If I’d realized how many words I was writing in each post I’m not sure I would have started the series. Yes,
I read Metrics with Impact by Michiel van Genuchten and Les Hatton in the July/August IEEE Software, pp 99-101 last week. They discuss a metric: Compound Annual Growth, CAGR for software. CAGR is interesting to me, because I’ve actually measured it before. Here are some graphs (no numeric data) to describe what happens in different
We got here because I started with Managing the Stream of Features in an Agile Program. That got me to Organizing an Agile Program, Part 1:Introduction, Organizing an Agile Program, Part 2: Networks for Managing Agile Programs, Organizing an Agile Program Part 3: Large Programs Demand Servant Leadership. Sorry I got behind. Life interfered. Some
We’ve all read a lot about agile software development—the various flavors and methods sprouting up to tackle new issues in requirements, architecture, design, coding, and testing. But it’s rare to hear real, tangible, objective lessons based on the experiences of those who have tried some form of agile development and failed. Get ready to take