A big trend in the agile community is to move from projects to products, where an organization sees all work as the creation or modification of its products. The organization funds products for the long term and allows persistent teams and their product owners to determine how to spend that money.
Here's a three-step guide to get started.
1. Identify your products
Identifying your products sounds easy, but it is not. All my clients have struggled with this. One challenge is deciding if "products" means external products for the customer, or internal products for another team.
To achieve the biggest gains, you should master understanding of the flow of products to the outside customer. However, many clients are so removed from the externally facing product that focusing on this seems unhelpful. Some groups on their own agile journeys do not influence the larger organization and may wonder if the move from projects to products has any value at the local level.
Imagine that the scope of transformation is only Step 3 of this value stream. Any optimizations you make will improve only Step 3. But if Step 3 is not the bottleneck in the flow of value, you are unlikely to make a significant difference overall.
If the bottleneck is in a previous step, Step 3 may already be starving for work. If the bottleneck is after Step 3, optimizing Step 3 will only further overwhelm those steps. Improving Step 3 would make both worse!
This can be confusing to the organization funding the agile transformation of Step 3: Will the investment yield tangible results? Is it worth optimizing only Step 3? Here are a few thoughts:
- It is likely that no one knows where the bottleneck is. Imagine that Step 3 is software development. It is possible that development is the bottleneck in value delivery.
- Since the people working on Step 3 are asking for help, they already believe a change will help value delivery. They are probably right, even without supporting data.
- In parallel with improving Step 3, you must also take a systems view and look at all of the steps to begin understanding the impediments to value flow.
- If Step 3 is the bottleneck, you've optimized both that step and the entire value stream. If Step 3 isn’t the bottleneck, you’ve still optimized this step and you are able to prove that the value flow is better. That evidence can be used to convince the other step owners to follow a similar optimization, starting with the step that has the actual bottleneck.
- Eventually Step 3 might become the bottleneck, but these owners will already have the skills to detect this and improve.
It's best to address all the steps. But if your scope is to improve only one step in the value chain, you must improve that step and also take a systems view. Only then can you expand the transformation to the other steps that might need the help more.
You need both types of products: those for the actual users, and the products of Step 3 and how those products support the true products.
Imagine you are improving the HR department of an organization. One internal product of HR might be talent acquisition. Is talent acquisition the biggest bottleneck to overall product flow? Maybe not. But if the users of HR feel it is one bottleneck, it is still worth improving.
How to identify all your products
One client already had an Excel spreadsheet with their products. This was a wonderful head start, until they tried to use the list. The products were inconsistent. Development used one set of ideas for products. The managers had put together a different list. Operations had a third list of products. And finance had a fourth answer. All were different yet represented the same products.
It is critical to get a list of products that all of these groups agree to. When everyone sees a different answer, improving product flow becomes difficult.
Some may feel they have only one product—oil, for instance. This rarely holds true, but it is a self-correcting problem. If there is more than one product, this will emerge as you move forward. So don't fight it; improve when you learn more.
At the other extreme, some clients have thousands of products and struggle with how to model them. Here are two strategies:
- Focus only on the subset the organization is actively working on in the next quarter. You may have thousands of products, but you're not working on all of them unless you have thousands of teams. Focusing on just the next quarter limits the scope. In subsequent quarters, you can add more products to the model as needed.
- Abstract those thousands of products into product lines and focus on those instead of on individual products when creating your product model.
Lessons learned:
- Identify the products for your sub-organization.
- Identify the products of the real outside users to take a systems view.
- Start with only one external product if you need to. You can adjust later.
- If you have too many products, limit your scope to just what is being worked on in the next quarter. Or abstract upwards into product lines, and focus on a line instead of products to manage the complexity.
- Ensure that all audiences—including roles such as development, operations, management, portfolio, finance, etc.— agree on the products being defined.
2. Create persistent agile teams
Companies need to move away from transient or temporary agile teams (TATs) to persistent agile teams (PATs) that will outlive their current work. Many organizations have agile teams, but they are project-specific and are dissolved when the project ends.
Every time you modify or form a team, it incurs a "J curve": Productivity dips before eventually rising again. So it stands to reason that if a company wants to maximize product flow, it should work hard to ensure that teams remain stable for long periods of time.
This also starts to address DevOps transformation. If teams own the products until their end of life, that's part of a DevOps mindset. You can still have a call center that handles issues, but the teams that created the product still exist and still own improvements to them.
I am a fan of Microsoft Azure DevOps (ADO) for agile work management. The setup is elegant yet simple, and it is the only tool I've seen built on this product mindset. I've used Jira, VersionOne, and Rational Team Concert—and Microsoft Teams was the only one where I could set up a product hierarchy in a day without the need for tool experts.
One of my clients—the one that had an Excel spreadsheet of their products—decided to use Microsoft ADO to manage its work. When they learned how to enter their products into ADO instead of Excel, they were delighted. But then when it came time to enter their PATs, they had no idea what that meant.
It turned out that they didn't have teams at all. They had five department managers, each of whom had lots of reports, but everyone was working on pretty much everything. The entire idea of small agile teams was lost on them.
Once the client understood the value of PATs, they began to refactor the organization to maximize PATs.
Lessons learned:
- Move away from TATs and toward PATs; as you identify your products, identify longstanding agile teams to own them.
- Keep teams stable, since any changes set off a J curve.
- Ensure products are owned by longstanding teams until the products' end of life.
3. Align with both finance and portfolio for value delivery reporting
As one client identified the products and PATs, a finance team member asked if there was a way to somehow align what they had in finance with all of this and whether it was worth the time and effort. He said, "We know people are spending money, but it is really tough to understand what value we are getting from that spend."
On the flip side, the portfolio team was struggling with knowing how much the epics, features, and stories were really costing. (Some definitions: Portfolio is the group that decides what to work on and the priority of when to work on it. Their skill is in understanding value delivery. Finance is the group that watches how money is managed. Their skill is in accounting, and they understand auditing, financial statements, and the like.)
There were a few issues at play here.
- Finance had no idea how the epic/feature/story hierarchy worked for agile teams, especially those using the SAFe definitions for these terms.
- The portfolio views in the tools did not use the same categories as the finance buckets, and portfolio team members didn't have much understanding of those buckets.
- There was no one tool that connected both perspectives.
- The way that epics, features, and stories were being written was not good enough to understand the value.
The client solved these problems by working with finance to understand how the products they had identified aligned with their financial categories. They then incorporated those categories into ADO, Microsoft's agile work management tool. They had previously added all the products to ADO, so now they added the financial buckets at a higher level and nested the products within those buckets.
Further, this financial team had already committed to moving toward funding value streams, product lines, and/or products. That's something that SAFe advocates for, so you can decentralize portfolio decisions and thus get to true lean portfolio management.
Seeing value for the first time
Once this task was finished, suddenly it was clear what people were spending money on and the value they got. They could just look at the epics or features recently closed, the features in flight, and so on. And they did all of it by way of the big visible information radiators (BVIRs) in the ADO tool.
Stories were too granular for top-level reporting. Epics were too slow-moving to be the only report. SAFe asks for large teams to be feature production machines, churning features into production like bonbons in a factory. So reporting on value at the feature level was the true currency for this type of reporting.
However, epic movement was still reported on, since it was always critically important to understand risk when an epic rumbled along. Teams continued to measure themselves on story production, as did their product owners and product managers.
At this point there was only one issue left to resolve: The quality of the epics, features, and stories was not good enough for the reports to be meaningful. That was a big problem, but there was more motivation to fix it than ever.
How they fixed that will be the subject of a separate article. (Teaser: In essence, the company realized that teams were using the epic/feature/story hierarchy, instead of a value hierarchy, as a substitute for the classic waterfall work breakdown structure. By using the value-stream vocabulary, they were able to significantly improve visibility into value delivery.)
Lessons learned:
- Work with finance to include their buckets into your product architecture hierarchy.
- Use your agile work management tools to align product work with the finance buckets.
- Use Kanban boards to report on value delivery per product and product line.
- Writing epics, features, and stories well is critical in this model. (My next article will talk about to accomplish this.)
Follow the patterns
The patterns described here will help you on your journey from projects to products. The journey is worth it, since it can increase the flow of value into the hands of your users. But remember that, while the steps sound straightforward, in practice they can be trickier than you think.
If a company started from scratch but had members from finance, portfolio, development, and operations, as well as an agile specialist and permission to make changes, it could do this in months, not years. But if the team were missing members, it would take much longer, take more wrong turns, backtrack more often, and might never be done—or it would take years.
[ Read also: Anthony Crain's Projects to products: What it means, why it matters ]
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
