Monday, March 25, 2013

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.

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.