Business Alignment & Project-to-Product Mindset
Built empowered, product oriented teams and help them to understand the business - and vice versa
Modern development teams should be encouraged to rethink their focus: “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.” With VSM we look to enable not only this way of dev team focus but also the empowerment of an engineering team into the business context of corporate leadership:
"Truly empowered teams (...) need the business context that comes from the leadership" is a key quote from the standard-setting book Empowered. It's not straightforward for development teams, and might put them out of their comfort zone - but it's understood to be a key ingredient in modern software development. Similarly, product leaders & modern Enterprise Architects strive to align business with IT, for faster communication, synergies, governance and other reasons.
Newly formed teams go through what is called a “Storming” period before the team starts to gel and move towards high-productivity and high-performance. Minimizing the dip in productivity (see J-curve graph above) by having long standing product teams effectively decreasing time-to-value.
While the Agile methodology recommends dedicated teams, it’s not mandatory and rarely occurs naturally.
Structuring work as Projects directly contradicts that methodology, as the product lives beyond the project scope, and is then the responsibility of group that had no involvement in creating it (bringing us back to the impact on Value Delivery due to the ramp-up time of the new owning team.) - this leads to a harrowing lack of alignment between project teams and operations
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.
This may pose risks that fall upon the Project team to evaluate against the target delivery of the project and how it really aligns with what bring actual value to the product.
How VSM can help
How VSM can help:
VSM is designed with a simple, yet powerful idea to bridge the worlds. Thinking in Products is the software industry gold standard, clearly superior to classical project thinking. Yet, often the notion of a Product is required to understand - but not sufficient to address concerns like ownership. Domains are a straightforward way to capture this internal break-down. Ultimately VSM leverages the data it gathers and reports it generates to tackle two of the key challenges:
Teams that have more focused product areas often yield more efficient results when it comes to delivery. “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.”
“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.” In Product-oriented companies, an existing high-performing team will pull the project and get working immediately, allowing you to pivot as needed with minimal time waste.
VSM can enable both for an efficient transition from project to product focused work through a clear overview of the different views a company should take at their products - external end-user focused as well as an internal view focused on technical domains - as well as a matching assignment of ownership and responsibilities. This streamlines teamwork by making identification of the relevant colleagues and channels to reach them easier.
VSM customers can choose whether they propagate business mapping "from the source", e.g. via CI/CD metadata, or as a manual governance process. Combined with LeanIX EAM, they can obtain an end-to-end mapping from business capability all the way into software development.
What's in it for me?
As a member of a product team: Understand external business context & internal segregation to build better products.
As a product leader: Double-down on empowered teams while speaking the language of the business.
As an enterprise architect: Address key questions (e.g. technology compliance & risk) via automation while creating synergies between product & corporate IT.
As an engineering leader: Evaluate whether software delivered by your teams and underlying technology are supporting business as expected.
The Business Alignment use case relies on having a Software & Cloud Service Discovery in place.
Product & market understanding either Product Leadership or Enterprise Architects need to supply an initial product list with key attributes.
Baseline understanding of the technical proficiency of your engineering department. Are domains already in place you can piggyback? Do we have metadata representing business context, e.g. in CI/CD - or do we need to start fresh?
Build up a domain model early on. Mapping their work directly to business products might be uncomfortable for software teams, and make you miss out on alignment chances, e.g. towards support.
With LeanIX EAM
If you are an EAM customer, the following steps are suggested:
- Import your application list as products from LeanIX EAM
- Create an initial domain model via the Inventory
- Decide how to connect domains & products to software artifacts - most prominent options are:
- Via CI/CD metadata
- Via source code repo metada
- Via Public Cloud tags or Kubernetes labels
- Manually via the inventory
Without LeanIX EAM
Follow the steps above, but with a manual import of products
Updated 12 months ago