When starting down the path to Agility using the Scrum practice, common practice requires the delivery team to be composed of cross-functional team members and contain all the people needed to create the software. That's great advice for many application projects, but not so great for enterprise-level development and application lifecycle management.
Why are cross-functional teams a good idea?
- We don't want to wait on specialists, who may not be available to answer our concerns, especially when we need them to do something inside our current sprint.
- We need the team to be able to self-organize and focus on the realization of the user stories in the sprint backlog and not to have time-wasting meetings that keep us from meeting our sprint commitment. It's a lot easier to collaborate with a fellow team member and figure out how to get something done than it is to figure out how to call a meeting, create action items and follow up with yet more meetings and action items until the issue is resolved.
- We want to focus on completing working software that provides value for the product in a sprint -- not on creating documentation for others to ponder and schedule and not on creating components that may or may not be of value in the current sprint.
This simplistic model of
Many times it boils down to the issue of needing Scrum to work in a scaled fashion in an enterprise setting. We fail to separate two major concerns when we build software in the large. Here are the issues:
- Product: what we develop for
- Platform: what we develop with
Application or product problems
The product we develop is the stuff that product owners are concerned about: what is needed, when it's needed and why it's needed. The value proposition to the company, including estimates from the delivery team and tempered with dimensions of risk, are what product owners use to order their product backlogs. And that's what Agile is all about.
In an enterprise setting, the product owner may need input from business architects to help understand the value propositions and some of the risk vectors. They may also need input from software architects to appreciate estimates (especially at first, such as in sprint zero) and other risk vectors.
But few delivery teams create all of the software needed from first principles. They may already have many of the components in the technology stack available. They may purchase components from third parties to use in the product realization.
But in situations where pieces of the technology stack have to be created and reused for other products, we hit an enterprise-specific issue. We may need a software component that is not available in the market and decide to make it. But when more than one Scrum team needs the same component and both are competing for the development cycles of those same resources, then the delivery teams will be competing for the same developers.
When we matrix those developers, we create waste because of task switching between projects. In addition, product owners will have a hard time ordering their backlogs because their delivery teams will be conflicted in their priorities when members are serving many masters.
Here's the missing piece. We fail to notice that we are sometimes developing two different things when we create enterprise applications. In Agile, we tend to focus on the product we are developing, and always look to the product owner for guidance as to what to build next. But when some parts are useful across products, then we have a second thing that we are building. We are also building a platform for the company to build products with.
Sometimes, a "make versus buy" choice occurs. Enterprises that decide to "make" should do so because what they want to use isn't readily available or doesn't give them a competitive advantage for the products being built now and/or in the future.
Think of platforms in that fashion. Now, wrap your head around this: If you allow platform people to develop as if they were a vendor you purchase from, they could develop a product backlog of their own. Things that don't have externally observable value in the real product have value for a component developer. In this light, it makes sense to have a platform owner who is also concerned about what is needed, when it's needed and why. They, too, will be concerned with value, estimates and risks. They will need to rely on enterprise architects and systems architects as well as their own software architects.
Remember: Their market comprises your product teams, so that planning has to happen at a higher level than just sprint planning. For all the platform and product owners to be effective, they need to coordinate on their release planning, so everything can dovetail into position on a schedule that everyone can optimize against.
Separating the product from platform concerns allows us to do the following:
- Mitigate waste due to task switching for platform delivery team members. They can work in natural affinity with other platform people and focus on satisfying needs such as scalability, reusability and other nonfunctional aspects of the underlying code.
- Observe progress in parallel development work. After performing a common sprint zero and working out a platform backlog, teams should rely on the interfaces between the layers in the software stacks being developed -- not on the implementation of lower layers. This allows parallel development to occur against test doubles through Dependency Inversion and iterative demonstrations of progress at sprint reviews.
- Mitigate the risk from late integration. Internal platform teams should collaborate with product teams early and often. Platform teams should allow constant access to their work in progress and permit interim integrations to occur with product teams not less than once per sprint. Both platform and product teams should send key people to each other's Scrums and participate in ad-hoc working sessions when issues come up.
Can Agile and Scrum work in an enterprise setting? You bet! But it takes work to tweak the standard textbook version of Agile and Scrum to do it. Separating product from platform concerns is a technique that helps make it all come together.
This was first published in July 2012