This description is intended to help guide the implementations of Scrum of Scrums at Program / Train level.
It all started with this picture that Mike Cohn published over 10 years ago. In the explanation he briefly mentioned a hierarchical structure where multiple Scrum teams get together when they are working on related projects.
Often I explain it as: team-based Scrum behaviors, just up a level.
This article has been floating around my head for quite a while. It will encompass several themes. The first being, how do we “account for” the time and focus within our agile teams? Second is, how granular do we plan for and monitor the focus of our agile teams? And finally, when planning and forecasting, should we plan at the individual level?
The “we” in these is a bit broad. I would include managers, directors, VP’s, C-level folks, the PMO and Project Managers. Virtually anyone who is tasked with “caring about” a technical team and what, how, and when they do what they do.
The Dinosaur Age
Well in this case, it’s not that long ago, but the analogy feels right to me. In this Dinosaur Age, project managers and “all management” for that matter, cared about people and their time. What are some of the aspects of that?
Does anybody remember the Cool and the Gang song Celebrate?
I sure hope so.
I want to write a short post about celebrations. For some reason I've encountered quite a few teams lately who are struggling. They're completing sprints and releases without getting much in the way done or meeting expectations.
In other words, they're ending their efforts: sad, depressed, without a sense of accomplishment. In a word, they’ve got no reason to – Celebrate.
Of course there are many reasons for it and I can't possibly explore all of them here. But the examples have made me reflect back on some of my best experiences with teams delivering “the goods”, and I wanted to share an example.
I’m often quite wordy in my blogs. I’ll pose an initial question in the title, throw out a thousand words or so, and then present a conclusion. I’m not going to do that here. Instead I’ll be much more succinct.
Is forecasting evil in agile portfolios?
The context for this conclusion and subsequent discussion is three-fold:
- Forecasting when you are just building your agile teams OR are in the early stages of an agile transformation;
- And, when you’ve been doing agile for awhile, and you’ve become overconfident with your capacity awareness;
- And forecasting in this sense is anyone determining how large or how long something will take and NOT fully engaging their team in the estimation, planning and forecasting.
If you don’t know, I’ve got some opinions about Scrum, the Product Owner role, Backlogs, and User Stories. I’ve written a book about Product Ownership and I spend a great deal of my time up to my eyeballs in stories and backlogs at various clients.
One of the things that frustrates those clients is that there are very few “prescriptive rules or firm guidance” when it comes writing stories and crafting Product Backlogs; in many ways, it’s more art than science. It’s also a practiced skill that gets better the more you actually do it—of course as a team, which is also true of agile estimation.