John Daniel Fletcher

The signs of project teams are plain to see: teams of mercenaries (order takers), slow velocity, little to no innovation, ballooning technical debt, no ownership of results, orphaned projects and blame directed everywhere.

More generally, one of the things we learned many years ago is that success does not come from projects, but rather from continuously working and iterating on an area until we achieve the necessary outcomes.

The difference between a product and project team is essentially about ownership. The difference between a team taking responsibility for an outcome, versus a team just there to deliver a project (output), and then move on to something else.

Software development is an iterative design process. In order to achieve true iteration and realize the value of fast feedback, its activities need to be performed with a single team (having a common reporting line) as far as possible. Many internet business and independent software vendors (ISVs) already operate in this way.

In large organizations... The lower tier teams (infrastructure/security) treat the higher tier teams as their (internal) customers in a problem-solving (not scope-delivery) manner.

activity-oriented teams are prone to optimize for their own activity and not for the bigger picture of delivering useful software.

Specialization isn’t the problem; organizing along lines of specialization is.