With the increasing adoption of agile, there’s been a lot of talk about moving from the project-centric delivery to product-centric delivery model. Initially software/IT borrowed project management practices mainly from manufacturing / construction industries, and such projects generally used sequential, waterfall processes. The technology revolution and the pace of change in IT has made such approaches difficult to sustain and the software industry has been quick to adopt agile methods like scrum which are adapted to product-centric delivery instead of projects.
In the manufacturing/construction industries, both problems and solutions were known and repeatable. Traditional project management therefore optimized resource-efficiency. However knowledge economy / software work is different where too often the problem may be known, but the solution isn’t. In cases of startups, even the problem could be unknown and lean-startup methods may be used to validate learning. In such cases, the focus should be on agility and flow-efficiency with product-centric delivery.
The organization structure affects delivery to a great extent. Broad categories are:
- Functional organization - traditional structure of organizations usually with functions like Sales, Marketing, HR, IT etc. Resources are controlled by functional managers and project management is part-time.
- Projectized organization - organized around projects with team members selected from common resource pools and functional units like HR, Administration etc. having a support role. Project management is full-time. Mostly seen in consulting organizations with project teams assembled for clients outside the organization.
- Matrix organization - contains structures which are a blend of the functional and projectized organizations. Project manager authority varies as a function of the relative authority of functional managers.
In a project-centric model, value delivery is organized around temporary endeavors (projects). Teams are assembled with resources from functional / matrix organizations for the projects and disbanded after delivery. Lessons learned from delivery might end-up with the organization’s PMO or in the knowledge management system, but is practically lost due to the lack of stable teams.
In a product-centric model, value delivery is organized around releases of functionality. Products continue to be improved across iterations with the help of stable teams, which develop expertise and make ongoing improvements as lessons learned between releases (projects) don’t get lost in the organizational black-hole. Dealing with multiple teams in a product organization is still a challenge.
With the ever-increasing adoption of agile methods and DevOps, software has continued to move away from project-centric model to the product-centric model of value delivery. It must be noted that organizational structure still has outsize influence on the value-delivery. e.g. while product teams could still optimize locally, unless the organization is structured to engage stakeholders for feedback, it could end up working very efficiently on the wrong set of problems. A lean-thinking approach with layered planning is required from strategy to portfolio to product to accelerate feedback and improvement. I’ll discuss this agile planning in a later post.
The dizzying pace of technological change has forced most organizations to take at their business models and the risks of it being disrupted. “Bimodal” delivery has become the norm. As “software is eating the world”, and lifespan of S&P 500 companies continues to reduce*, it makes sense to focus on approaches adapted to software and more specifically innovation. In practice, this essentially means:
- moving away from sequential (waterfall) approaches to iterative agile methods
- reorganizing teams into cross-functional feature teams or larger product/value stream tribes
- adopting servant leadership behaviors instead of command-and-control management
- instilling a culture of continuous experimentation and improvement (based on measurements)
In some organizations, projects now work with prioritized product backlogs to deliver releases, with the backlog being groomed and updated constantly by the product owner based on feedback from product manager and/ users/stakeholders which could be both features or defects. Budgeting is for the stable feature team and design is not done upfront keeping in sync with agile values.
An oft-cited example is the use of agile methods at Spotify which has been termed the “Spotify model”. Even though it is not a scaling framework like SAFe, it has inspired several other organizations to copy the “model”, hopefully adapting it to their local context.
Change takes time and change management is hard. Different organizations are at different stages of their agile transformation journey. Products used internally in large organizations have different dynamics than MVPs of startups searching for the elusive product-market fit. One size does not fit all. Organizations need to experiment by measuring returns from change (e.g. reorganizations) with project and product centric delivery models in true agile spirit.
comments powered by Disqus