It's all about (software) products!

I recently shared my view on agile transformation in an article, initially written for an internal blog within NXP Semiconductors where I am actively driving the implementation of SAFe as framework to Business Agility. My spring vacation inspired me to continue and further reflect on it. And of course I am not hesitating to share this with you, looking forward to your feedback. But as an initial disclaimer: Those are my personal thoughts and experiences in the context of transformation, augmented by content from various books and publications - digest with care :-)

The more I think about transformation, the less I see waterfall vs. agile or projects vs. value streams as the true core of transformation. Moreover, it’s for me about how we approach (software) products and innovation in general. I was therefore reading a lot about transforming organizations to the "product operating model", and that it requires first to understand what your current model is - so let's think about this.

I started my own career as a software developer with an Engineering Service Provider that was doing well in selling software and system development competencies to automotive customers on a project basis. The high level of expertise allowed us to maintain an attractive margin at that time in 2008. Project scope and timelines were contracted in the beginning and any customer changes got monetized on top. Scaling up the business meant increasing headcount at low labor cost while continuously maximizing the percentage of people working in paid customer projects. I would call this the "engineering project model". Nothing wrong about it for a company where engineering services are the actual product.

At least in the automotive industry, many software organizations initially emerged from these engineering services at times, when the raising relevance of software started to lead to increasing insourcing of these critical competencies at automotive manufacturers and suppliers. However, many organizations still kept the "engineering project model" for internal collaboration and planning, even their products changed away from engineering service to products like cars or electronic systems. That not just resulted often in silo collaborations where other teams are seen like (evil) internal customers, but also to the financial view of R&D (and IT) as cost centers instead of value centers.

Some typical symptoms of that model:

• Significant effort are spend on internal specification and change management between business and R&D, reducing flexibility and true collaboration
• Results are measured by outputs (e.g. delivered features or lines of code, cost per headcount, …) instead of outcomes, taking the focus away from measuring business impact
• Funding is done project by project with a high focus on predictability (e.g. speculative business cases), leading to limited room for new ideas and insufficient reduction of technical depth (e.g. strong dependencies, high cost of maintenance)

I see the growing dissatisfaction with this situation and the emerging competition from more innovative software native players as a key reasons why organizations talk about the need to transform to something different.

So, what’s the alternative? Fortunately there is a growing number of great books and academic publications that look into the success patterns of outstanding (software) product innovators to learn from. Some that have highly impacted my view on the subject are the books ?From Project to Product“ by Mik Kerstan and more recently ?Transform“ by Marty Cagan. Marty describes well the three (independent) dimensions of transformations "changing how to to build", "changing how to solve problems" and "changing how to decide as organizations which problems to solve".

Some of the product model principle he mentions are:

• Empowered Product Teams get customer problems to solve instead of feature roadmaps to implement, and are directly in contact with to customers
• Product Teams own both sides, the product discovery and the product delivery, to take full ownership. The teams have all critical competencies on product management (viability), product design (usability) and tech lead (feasibility).
• Product Leaders provide Product Vision and insight based Product Strategy to the Product Teams, coaching the product teams to develop the necessary skills
• Product Discovery uses prototyping and other techniques of running experiments to validate concepts early at minimum cost (e.g. number of tests >> final concepts build for delivery)
• Product Delivery releases software at high frequency to react fast on identified issues and run fast learning cycles (e.g. using CI/CD)
• Product Delivery Instruments releases in order to collect data for monitoring
• Finance and Management provides funding for Product Teams instead of traditional project business cases, and in return measure success on real business outcomes instead of outputs

For me, the idea of fully empowered cross-functional teams that focuses on strategic relevant customer problems and take ownership for both, the product and the business outcomes, are the real deal. But it requires from organizations a clear and understood vision and strategy that enables the teams to make decisions, a focus on the most relevant problems to solve, an aligned approach how to break down these problems into manageable product teams, and trust in the teams.

Since I am driving the implementation of SAFe, I see SAFe and the Product Operating Model rather complementary. However, it also see that implementing "SAFe by the book" will not automatically lead an organization to the Product Operating Model or any similar way of working. Instead, there is a high risk that expectations of the transformations are not met and the underlying problems remain. I would therefore advocate to early start thinking beyond the implementation of SAFe or any framework how your organization wants to play in the (software) product and innovation game in the future!

#agile #safe #software #softwareproducts #transformation #itsallaboutthejourney