Overcome digital transformation and value delivery challenges, by encouraging modern development teams to reconsider their focus, whilst owning the end-to-end product journey, and align to the business context of corporate leadership and IT.
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.
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.
Work in Progress!
Please reach out for any questions!
Updated about 2 months ago