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 […]
Every so often, managers want to compare teams. You’ve heard this in several ways: Managers want teams to “normalize” their story points, so they can better predict the cost or schedule for the rest of the backlog in large programs. This doesn’t work, but managers want to do it anyway. Managers want to compare teams
Are you going to Agile 2013? If you are, maybe these tips will help you. Consider using the schedule planner app to remind you of the sessions you thought you wanted to attend. However, don’t be bound to those sessions. You might meet someone in the hall, or at a meal, have a conversation, and
A few weeks ago, Dave Prior interviewed me for Projects at Work. He posted that interview as a podcast. Yes, registration is required. We spoke about Personal Kanban, my process for getting my work to done, how I carve out time for intellectual work, how I protect that time, how I iterate on my work,
My most recent column on projectmanagement.com, Using Release Trains to Get on Track is up. It’s another one of those columns that addresses the question, “What do you do in a program with agile and non-agile projects?” I hope you enjoy it.
Do you want to immortalize your agile team? Would you like to contribute to the research about how agile teams collaborate? If so, have I got a deal for you. My friend and colleague, David Socha, a professor at the University of Washington, in the Seattle area is writing a grant for the NSF to
Bad management is easy. Well, let me rephrase that. It’s easy to perform management badly. But, it’s not so easy to perform management well. From the outside, it can seem as if management is effortless. But that doesn’t mean that good management is easy. Early in my management career, I returned home one day, plopped
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