Many companies and practitioners are unfamiliar with the idea of moving their agile approach from projects to products. Although there's a great book about it, Project to Product, by Dr. Mik Kersten, many people who ought to read the book don't yet know why they should.
It's a fairly new concept, and although there are some posts on the subject, some are quite complex, some are wrong, and others miss what I think are the most exciting points about moving from projects to products.
If you already are a believer in this approach, and you already understand the benefits, I'll cover that in an upcoming article.
But if you're new to the idea, or have had trouble understanding the value, here's why a projects-to-products (P2P) mindset is the critical factor in ensuring that your agile, DevOps, and digital transformation initiatives succeed. With this knowledge, you can articulate that value to others who do not yet understand it.
Who owns the shopping cart? You do!
Imagine that an executive hears that the shopping cart for the company's website is making people unhappy for some reason. The executive walks into a room with all of the company's developers in it and says, "Okay, who owns the shopping cart? I have some critical improvements that I want done immediately."
In an organization that is project-focused, no one owns the shopping cart. Instead, there may be an operations group that takes in all sorts of improvement requests and works on them, getting help from development when needed.
The executive's request would go on that backlog, competing with a bunch of other issues for prioritization. And if the change was a big one, a business case would be written, and a team would be assembled that would have to learn about the existing work. The team would then build a solution, deploy it, then dissolve. All of this takes a ton of time.
In a product-focused organization, a longstanding, persistent team (with a fun team name such as the Barracudas) owns the cart. In a 2018 Harvard Business Review article, a USAA executive reported that this was the case at his company. When someone asks, "Who owns the customer's change-of-address experience?" they always know the answer.
When a company moves from projects to products, they are changing the focus of every person in the organization from a short-term "let's get this project done and move on to the next" perspective to a long-term ownership perspective.
In this product-focused world, teams don't work on a project; they own a product from concept to decommission. Imagine the difference in quality and in employee engagement when teams own products instead of being treated like resources to be shuffled around.
How P2P affects value delivery
Like agile and DevOps, projects to products (P2P) promises to increase the flow of value to your users. Here's why.
- You don't need to spend time forming a team to implement a "project," which can take months in some organizations. Not having to form a team decreases time to value.
- New project teams incur a J-curve; this is a dip in productivity before they gel into a high-performing team (if they ever do). This can take days to months. Product teams are longstanding, so they do not incur the J-curve of team formation. This also increases time to value.
- Product teams don't focus on a project scope that must be completed. They are seasoned, well-oiled feature machines that put small units of functionality into production as frequently as possible. If you bring them work to improve the shopping cart, they will decompose that work into valuable chunks and begin flowing that into production as quickly as they can. This decreases time to value.
Figure 1. This overlay of a J-curve on Bruce Tuckman's stages of team development shows how team productivity changes over time. Note the initial dip from the forming stage to the storming stage.
Giving work to an existing high-performing team will get you results much faster than having to form a team first, then dissolve that team at the end.
Some people wonder how this is different from agile, which always asks for dedicated teams. The question is the answer: Agile always asks for dedicated teams, but that rarely occurs. The P2P solution enables the organization to finally form these persistent agile teams that we have needed all along.
How P2P affects funding
In the project world, business cases are written to justify funding, and all the funding is granted up front. The team is then formed and given the funds to complete the project.
If the project runs over, new negotiations are needed. If it runs under, the team often uses up the funds on other good but not critical work. This both increases the time to value and can lead to "gold-plating" of a solution—in other words, adding features because they seem exciting, even if they don’t provide any obviously measurable business value.
In the product world, all this time is eliminated. New work is decomposed into work items and prioritized against existing backlog items. If the work is critical, the team can begin flowing that work at the next increment (say a two-week sprint) or even sooner in an emergency situation, and swap out other in-progress work.
SAFe value stream funding
The Scaled Agile Framework (SAFe) has a goal of decentralizing portfolio management. In SAFe, value streams represent a series of steps that an organization uses to implement products, services, or systems delivered to a customer.
In SAFe, four guardrails help decide which work can be managed by the agile release trains (ARTs) and which need to be looked at by a centralized lean portfolio management (LPM) team.
The idea is that by funding value streams—which are aligned with one or more products—the value stream owners (the ARTs) can decide how to spend their money. Only when a request exceeds the portfolio threshold is the LPM team needed.
This allows ARTs to make faster decisions about what to work on and to react more quickly to common-sense ideas. This assumes that the ART is a large, dedicated team that pulls in new work as it gets allocated to a prioritized backlog. In other words, it's a product team.
Why funding teams may not work
Funding teams is problematic in the capex/opex world of finance. A team is not a product. Funding products is financially more accurate, but also has challenges. One is that executives need to clearly see the value created by the funding as it is consumed. The importance of reporting on value delivery increases when companies choose to fund products instead of projects.
Nevertheless, funding products over projects makes a lot of sense; this approach creates or improves a product, which is of direct value to your users.
Funding projects puts a second level of abstraction between the funds and the products. In other words, this method makes the product the primary source of funding and allows work in the form of epics, features, or stories to scope that work.
In SAFe, value delivery is in the form of two kinds of features: business features and enabler features. As long as those can be proved to be valuable, your flow of value for the dollars is clear. In Kersten's book, he defines four types of value: features (which are actually user stories), defects, risks, and debts. Again, as long as we have clear definitions of value, both product models (SAFe and Kersten's) can be used to prove what value is being delivered for the funds used.
How P2P reduces the impact of running late
When a project runs late, there is a more significant impact than just the time spent renegotiating. When a project ends, the team is dissolved. Each team member is likely to get pulled into a new team.
Imagine that a team of five is delayed. Imagine that each was slated to join a different project. All five subsequent projects are now affected because they are missing a critical team member.
In the product world, only one thing is impacted: whatever is next on the team backlog. Further, the complexity of navigating the change is much lower. It isn't five people and five projects; it is one team and the next item on their backlog.
How P2P affects DevOps
The DevOps movement has always had two goals: shift operations people left by including them earlier in the development lifecycle instead of keeping them confined to the end of it, and increase the dev team's ownership of the work after the end of the project.
Here is the issue. The project ends, but the product lives on and must be cared for by a separate group that probably had nothing to do with building it.
In the P2P world, teams own their products long term—from concept until the end of life. So the second DevOps goal is achieved by eliminating the project mentality and adopting the product mentality.
Also, when forming these longstanding teams, you use the agile mindset. You create cross-functional teams that will take on any work as long as it means product success. They will gravitate toward their specialty, but can and will pivot to any work that is a bottleneck to value delivery.
With persistent agile teams, you include people from operations. Ops becomes a skill, not a role or a team. And those with ops skills can ensure a higher-quality product. This includes providing valuable telemetry once the app is in production. As team members, they influence what the team works on and ensure it includes ops features.
How P2P affects digital transformation
A pivot is when you need to switch work from one idea to another. With a product-related pivot, you need only figure out which product or products are affected. You can bring the idea to the appropriate team, and it can pivot, either during the next sprint or immediately, to the new idea.
Companies that have to assemble teams in order to pivot to new opportunities will always lag behind companies that use existing high-performing teams. Organizations taking a project approach will lose precious time looking for people to put on a team.
The people pulled will cause disruption to multiple other projects that each was previously on. They will lose time to the J curve. And they will lose time as the teams figure out how they will move their solution into production.
In contrast, in product-oriented companies, an existing high-performing team will pull the project and get working immediately. It will decompose the solution into minimal viable products to validate the solution hypothesis. The team may even be able to use existing CI/CD techniques to ensure to flow the solution into production much more quickly than can a team that is just forming.
P2P teams are cross-functional, with business and technical people working together to assure value delivery. Agile always asked for this, but the P2P movement brings these worlds together into a real team.
Agile and DevOps are critical goals on the path to digital transformation. And a product-centered approach is key to making agile and DevOps work. With a project focus, both agile and DevOps have to deal with disrupted teams on a regular basis and lose precious time.
Get going with P2P
Adopting a projects-to-products mindset is the critical factor in ensuring that your organization's agile, DevOps, and digital transformation initiatives succeed. Funding products instead of projects will allow for faster pivots, faster time to value, higher quality, collective ownership, and alignment with the needs of your customers.
In an upcoming article, I will outline a three-step strategy for how to implement P2P.
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.
