The Art of Platform Development: Scaling Agile with Open Source dynamics

I’ve spent nearly my entire career working on “platform teams”.   The teams went by different names including “Shared Services”,  “Framework”,  “Core”, etc.  But the goal was always the same:  to centralize capabilities development and leverage those capabilities across product lines.

Achieving that goal is incredibly valuable.  By sharing capabilities, you can eliminate code and infrastructure duplication, which decreases operations and maintenance costs.   It also ensures consistency and simplifies integration across the products, which decreases the overall system complexity and expedites the delivery of new products to market.  In this model, “product development” can become an exercise in capabilities composition.

Unfortunately, this model challenges traditional Agile development.  Typically, Agile works from a product backlog, which is controlled by the Product Owner.  The Product Owner is focused on the business value of the stories (typically functionality).    Priorities are often driven by market opportunity and customer value.   With multiple products and product owners, where does the platform live?   

Often, the drive to keep the teams isolated and focused on the customer functionality results in silo’d development and silo’d products.  One might argue that such dynamics will always result in a fractured architecture/platform.

(See Conway’s Law: http://en.wikipedia.org/wiki/Conway's_law )

Some enterprises solve this problem by creating a Platform backlog and Platform team, which takes on all common service development.  This can work, but it is a nightmare to coordinate and often bottlenecks development. 

Furthermore, since prioritization of functionality is done within each product backlog, the result is local optimization.   It would be better if the enterprise could prioritize work globally, across all products and then optimize the assignment of that work across all development teams.

In the slides below, I suggest a different model, whereby product demand is collapsed into a single pivoted backlog that focuses on capabilities instead of specific product functionality.  Then prioritization is driven by the collective value of that capability across product lines.

With this pivot however, we lose the affinity between a team and its Product Backlog.  To fix that, I suggest the teams take an open-source approach to development.  Any team can take on any story, and contribute capabilities back to the “platform” via git pull requests to the appropriate component.

In this model, “platform development” is no longer the bottleneck.  Instead, all the teams share the platform, which eliminates the “us vs. them” mentality that can develop and establishes the proper dynamics to support the development of a single cohesive platform.   (aligning with Conway’s law)

Anyway, it’s just some food for thought.  I’d love to hear what people think.
http://www.slideshare.net/boneill42/the-art-of-platform-development