Product v Project Focus in Software Development
Many IT organizations use a traditional project approach to software development. Agile success is dependent on forming product teams that have these characteristics:
- A defined focus area (application, domain, system, etc.)
- Persistent over time
- Cross-functional skill sets, giving it the ability to deliver a fully baked solution in each iteration
- “Concept to cash” responsibility—taking work from early discovery and design steps through delivery and into production deployment and operational support
It’s important to understand the difference between product focus and project focus. A product team can still deliver value in a project context, but the way the team is organized and delivers is very different. Here are some contrasting characteristics:
|People||Team is the primary means of creating value. They stay together over a long period of time and over multiple “projects” as a self-organizing unit.||Treated as specialists in functional silos; focus is on 100% utilization (watching the runner, not the baton). Spread thin across multiple simultaneous projects, each competing for his or her attention. Death marches and heroes are common.|
|Customer||Integral part of team; key to defining value and providing feedback on deliverables. Partners with team to define roadmap in terms of business value.||A request submitter. Incentivized to create large project requests because they get one shot at success, then relegated to back of line. Confused about who they can get info/updates from.|
|Demand Management||One prioritized backlog per product.||Repository of an unlimited number of requests of all shapes and sizes. Plan-driven resource allocation.|
|Delivery||Iterative and incremental with focus on highest value soonest. Opportunity to change priority regularly.||Unpredictable and unreliable. Project at constant risk of being put on hold or deferred.|
|Quality||Integral to every work item; owned by the entire team. Benefits of collective code ownership and continuous refactoring to reduce tech debt.||Most frequently sacrificed characteristic in a plan-driven, deadline-oriented project. Highly variable from project to project because a continuous improvement process is lacking.|
|Intangibles||Higher level of commitment from the team due to higher levels of ownership and accountability, defect level, tech debt level, and architectural integrity.||Project team disbands and members move on to next project. Long cycles and unique work mean no opportunity to regularly inspect and adapt. Ad-hoc teams mean individual performance standard and improvement path. Hero culture.|
Plan-driven traditional project approaches apply industrial process efficiency principles and practices that are poorly aligned with the realities of software development. Agile product teams are more aligned with principles and practices that work best for the type of creative, problem-solving work that is software development.
The choice of product teams over a traditional project approach to software development creates a foundation for achieving organizational goals of high quality software delivered on a regular, predictable cadence, and highly engaged and focused people.
About the Author
Keith Klundt has close to 20 years managing software development. His roles have included: Product Manager, Scrum Master, Project Manager, Agile Trainer and Coach, as well as leadership roles as a CTO, VP and Director of Engineering and Agile PMO. Keith holds an MBA from Brigham Young University.
Keith is passionate about Agile and Scrum and believes the principles, values, tools and practices they provide are an organization’s best way to achieve high levels of productivity, product quality, and morale.