Note: I had a technical problem with my site and lost this post, even though I had published it. This is the restoration. If you subscribe to my feed, you might see this twice.
I've been working with some clients who are trying to find the magic way to slice and dice their project portfolios. Their organizations treat the software people (IT or Engineering) as a shared service. That means the software people “service” the rest of the organization. While the organization might use products and product lines, the software people work in projects.
That might not be bad. I've said in the past that as soon as we have more work than teams to do the work, we need to switch the work.
I tried to show how that might work for one team with a primary product and “other” work.
The team works on Projects 1, 2, 3 for the duration of those projects. In between, the team works on “other” work. That work might be projects. It might be periodic work, such as quarterly reports. It might even be emergency projects, or ad hoc work. Not everything is a project.
Whatever the work is, the work offers value to the customers, and by extension, the organization.
Products vs Value Streams
I'm going to rant a little about the term “value stream.” I'm not sure why people use that word instead of products. Yes, I'm showing my ignorance, and asking for your help to educate me.
I think of the product and the value stream as the same thing:
- Both products and the value stream create capabilities for the user. (At some point, there is a user, even if you sell to a distributor.)
- Both products and the value stream need to release so that the user can use the work.
Any work that's done but not released is inventory. (See Knowing When You Release Value.) Inventory is not an asset. That's because software inventory tends to age and not be useful.
I happen to find it more useful to think about what's in the product that the customer can use vs. what's not in the product yet. (If you have other useful ways to think about this notion of product vs value stream, do let me know. I'd rather be embarrassed I didn't understand something than to lead my clients astray.)
Flow Work Through Product-Based Teams
I don’t use the words “epic” or “theme.” I talk about feature sets. That means the Reports module is a set of features. So is the Search product. So is the Email feature set. I don’t differentiate between what they are, because they are all more than one small story.
If we can agree that a team can become expert on the Reports, Search, or Email, then the team can finish the projects for their product/feature set.
By finish, I mean release something of value to the users. That’s why I find the word “project” as a container for:
“Here’s what/the value we want to release now, for these customers. We’ll do another project, with other features/value for those customers, later. In the meantime, as the customers learn to use these features, we’ll move to another product or other work.”
When we use projects as a container, we can:
- Think about how little we can do, not how much.
- Consider small, safe-to-fail experiments.
- Think and work in MVE, MVP, Minimum whatevers.
Projects, as a container for work, tend to nudge the team to finish the work. In my experience, the project-as-container also nudges the user, managers, whomever to stop adding more work. The team finishes projects. They tie a bow on that work. They can move to other work.
When you have small projects, it’s easier to assess the projects. I’ll address assessing the various projects in Projects, Products, and the Project Portfolio: Part 2, Assess & Rank the Work.