I have done a small amount of research on this topic and was surprised to find there is not a lot of useful content explaining the difference between the Project and Product and the resulting roles. So I’ve thrown this post together which are my thoughts based on experience and hope it will be helpful to someone.
The term Project, according to Wikipedia, is a collaborative enterprise, involving research or design, that is carefully planned to achieve a particular aim.
The word coming from the Latin projectum meaning ‘before an action’, and the original adoption into English meant the planning of an action and not the action itself.
In modern business, a project is usually taken to mean the planning, the execution, and the delivery. The term in software development is more often used when the process used for delivery is a non-Agile methodology, such as waterfall, and usually refers to a set of sequential specialist stages in which a manager is required to keep track of the many dependent parts, the finance, the risks, and the time to deliver.
In my opinion, a Project Manager is required on any initiative, Agile or not, if the organizational design is optimized too much towards specialization of skills or architectural components (Conways Law). Over-specialization is a local optimization which supposes that if you group people around a specific skillset (for example DBAs, or BAs) or architectural component (for example a code library, or service) that this gives efficiencies in either cost or quality. Unfortunately, this is rarely true in practice, and this type of optimization has the flip side at the system level, of producing high levels of hand-off, work in progress, lack of ownership, and poor quality. You can read more about this in my blog post on gaining more capacity without hiring anyone and in Craig Larman’s presentation recorded at Adventures with Agile last year.
The Project Manager is required in this instance as the only point of ownership to somehow bring the whole initiative to its intended conclusion.
Typically, a Project is funded with specific goals and a business case in mind. Being of finite time, and of finite expected value and cost, it is typical to bring people or teams together for the purpose of planning, executing, testing, and releasing the outcomes of the Project. Often these teams are disbanded at the close of the project.
A Project Managers function then is to create a plan, often called a baseline plan, that the project will follow, and then to drive the people involved in the project to follow that plan with as little change as possible. If there are deviations from the plan, then the Project Managers role is to limit these deviations and to bring back the execution as close as possible to the original base line. If this falls outside an accepted variance and is not recoverable, the Project Manager must explain and gain acceptance from the original stakeholders or investors, or in a worst case, tell them how it is. Sometimes this deviance from base plan may result in the funding being pulled from the project.
A Product Owner conversely has no baseline plan. A Product Owners role is to constantly evaluate the viability of continuing the execution of delivery. The Product owner may optionally produce a high level road map instead of a detailed plan. The roadmap is typically detailed only for a few weeks ahead and then becomes progressively less refined as the time horizon increases.
Ultimately, estimation and forecasting are not required in many cases, as everyone knows the teams are working on the most important items at any given moment.
A Product group in Agile is typically formed of long lived teams, that last sometimes for many years. The Product Owner has two responsibilities; these are prioritization and clarification. By continually prioritizing work, and making sure the delivery teams are working on the highest priority possible, stakeholders know that whatever the outcome, the teams are optimized around achieving the right objectives with the smallest amount of work possible.
In Agile development, feedback is gained every release or sooner. In Scrum this at the end of a sprint, and in Kanban and sometimes Scrum, every time a work item has been completed.
This feedback then guides the prioritization of further work ensuring that the teams are building the right thing (reducing business risk) and that they are continuously delivering (reducing delivery risk) every few weeks at longest.
The pressures that occur in the team due to large batch delivery cycles that are typical on Projects that fix time, scope, and cost, often cause the teams to take shortcuts, resulting in lower motivation from lack of mastery. The primary measure of the success of a project is often given to the delivery teams as delivering a set of features on time and within budget. This focus, removes the ability for the team to ask the question WHY and focuses the teams on the WHAT and the HOW. Lack of motivation is increased because the teams lose a sense of purpose and become merely an extension of the Project machine. Compounding low motivation also comes because of fixed scope and the loss of autonomy in how to operate. The most efficient means of execution in a crisis, is where the manager tells the team exactly what to do and when. When crisis becomes the usual mode of operation, and autonomy is removed, motivation and dissatisfaction increases accordingly.
As motivation is reduced, people leave, compounding the problem of delivering on time.
Conversely, in a Product delivery team, there are no such pressures. The time and cost may be fixed, but scope is not. With variable scope, and through feedback and collaboration with stakeholders, the manager / leader / Scrum Master, is able to remove this pressure, and create an environment where individuals reach a higher potential and operate autonomously, resulting in better problem solving, higher ownership of outcomes, and faster time to market.
In short, a Project Manager, whether they have Agile in their job title or not, is a stop gap role, whilst the organization removes the impediments stopping a team from being self-managing and optimizing around Product delivery.
This is typically:
- Introduction of the generalizing specialist (system optimisation) and reduction of over-specialised silo teams and bottleneck people (local optimization)
- Introduction and maturity of automated testing allowing shared code ownership across teams and automated integration
- significantly reducing the need for people level co-ordination and instead moving dependency problems to code level dependency
- Removal of long term fixed scope initiatives and instead value / risk based prioritisation
- Change of management style from Theory X to Theory Y
- removal of arbitrary deadlines
- removal of the idea of developer commitment even over short time frames
- removal of locked down internet sites
- removal of bonuses as a means of motivation
- increase of transparent financial management
- increase of short term rolling budgets funding prioritised backlogs and constant product viability feedback
- rise of the leadership and reduction of management
When this happens, the need for the Project Manager just disappears. There is simply less need for the high level of co-ordination required and fake motivation required for teams working in a purely Agile way.
Further reading
Co-ordination Chaos. Thank you for Ari Tikka for sharing.
Thank you to Ram Srinivasan for sharing the following links:
Enjoyed reading this article, thank you for taking the time to put this together.
Good read and very helpful, thank you.