The Product Stream concept is a simple one. A product stream contains a self-organising team and a Product Owner , yet it engages with the Business more deeply than just having business representation in the Product Owner. Engagement is the wrong word, I suppose, because it's more than that. Software development is absorbed back into the Business. It's no longer just aligned, it's integrated; it's part of the Business .

Product streams may be simple, but already we know it's challenging to establish them within large or enterprise organisations because we're doing it now. It's definitely not impossible though because, from the very start, we've been seeing real successes. But inevitably there's always resistance to change. So far we're seeing more from the IT part of the organisation than from the business part.

The Business has stepped up. The business people within each product stream are doing everything required of them, and more, to collaborate constructively and responsibly and keep up with a weekly delivery cycle. At the end of one of the earlier showcase s, our Product Sponsor asked: "Am I doing this right? Is there anything more I should be doing as sponsor?" We're seeing collective ownership of product as business skills are mixing with technical skills to deliver value to the customers.

Generally speaking with respect to IT, the challenges for the Product Stream concept are largely based on IT's fixation on reducing perceived inefficiencies. With the business parts of companies being more vocal about the failings of their IT departments, IT is trying harder to provide better services. The problem is, in a world focused on cost, IT is often concerned more with efficiency than effectiveness. And efficiency without effectiveness just means a poor service will be delivered more quickly. Spot the vicious circle. IT has developed a predilection to centralise things that are common in order to achieve organisational scalability and software re-use, and to reduce expenditure. These are understandable goals but there are consequences if they are pursued without regard for effectiveness. Excessive centralisation has led to over-organisation and fragmentation, and the introduction of unnecessary dependencies, artificial barriers and waste (pdf) , all of which hinder product delivery.

Ideally a product stream would be made up entirely of generalising specialists - people who are jacks-of-all-trades and masters of some - and would therefore contain all the skills it needed all of the time. However, there just might be some rare skill that is needed once in a blue moon, which cannot be found in a generalising specialist. In this case the product stream would have to look externally for a specialist in that field and hire him, on an on-demand basis, for the short period required. On the other hand a generalising specialist with that rare skill might be found, but if he's the only one and there are many product streams requiring that skill, what do you do? In both circumstances, it can make sense to centralise the skill, in which case the product stream has a responsibility to learn from the specialist to reduce the dependency. Ultimately, the product stream should rely on the specialist for advice rather than action.

Re-using software is another sensible goal. A product stream can make its software re-usable so that other product streams can use it. But beware. Re-usability doesn't come for free. It requires additional effort that might otherwise be spent delivering product and it creates dependencies between product streams, which may slow things down. IT often moves what it considers to be core software into centralised teams, but this strategy often leads to a focus on infrastructure software rather than product. There's an inherent danger that effort will shift from delivering product to customers - something the Business definitely cares about, to delivering generalised, re-usable software within IT - something the Business doesn't typically care about. The potential long-term impact of re-usability should be assessed beforehand because its affects can end up costing much more. What might be gained by developing once can often be lost, many times over, in the dependencies created. For example, if different product streams using some infrastructure software require changes to suit their specific needs the team owning the infrastructure software can quickly become a bottleneck. And a central bottleneck will slow down the delivery of all dependent products. The Business isn't going to be happy when that situation arises. Infrastructure software isn't all it's cracked up to be so consider re-use on an investment basis rather than a means to reduce costs.

It's preferable to make software available to others as open-source. By that I mean other product streams can take the source code and effectively own their own version of it. They are free to integrate it however they choose, deploy it to their environments, and control the hosting of it to serve their product. If they want to modify the source code they can; they can even submit improvements back to the product stream owning the original source code. The open-source model creates a loose dependency and provides product streams with continued autonomy while allowing them to benefit from the work of others.

Service-oriented dependencies should be avoided wherever possible. This is where a product stream makes functionality available to others via a published API or some client-side code that must be integrated. This is a tightly coupled dependency because the product streams using the service are entirely dependent on the service provider for the functionality. The service provider probably keeps the source code private (or doesn't allow anyone outside the product stream to maintain another version), and hosts and controls the service. If a product stream requires a change to the service or bugs to be fixed it must ask the service provider to make the changes. If the service fails, the product streams rely on the service provider to take corrective action. Consequently, product streams using the service lose some of their autonomy and to a degree, control of their own product.