Donald Reifer, Consultant
Many people that I talk with ask me to explain the “no project” movement within the agile community? They are curious why so many agile thought leaders believe that projects and project managers are not needed. I believe the reason revolves around who is put in charge and where emphasis is placed. As shown in Table 1, agile efforts emphasize delivering working software that provides value to the customer. In contrast, project managers focus their attention on satisfying scope, cost and deadline goals as defined by requirements. “Are these differences really that important,” you might ask. My answer is “yes” because these dissimilarities leads to major distinctions in (1) development philosophy, (2) focus, (3) organization, (4) controls, (5) ownership and accountability, (6) teamwork and (7) implementations (rally points).
|No||“No Project” Movement||Traditional Project Management Approach|
|1||Product Owner sets priorities||Project Manager is in charge|
|2||Product/Value Stream||Project success|
|4||Flexibility||The triple constraint (time, cost, and scope)|
|5||What is it worth?||What does it cost?|
|6||Product-based and feature-oriented||Plan-directed and task-oriented|
|7||Product architecture the rallying point||Process compliance the rallying point|
|8||Flexible requirements||Firm requirements|
|9||Working product provides visibility and release delivery||Reviews, documentation and metrics provide visibility and evidence of milestone completions|
|10||Self-organizing and collaborative teams||Leader dominated and temporary teams|
|11||Cradle to grave accountability||“Build” accountability|
|12||Emphasizes simplicity and elimination of waste to achieve efficiencies||Uses competition between groups to achieve efficiencies (matrix management, systems vs. software, etc.)|
|13||Outcome ownership||Task ownership|
Table 1 – “No Project” and Project Management Movements Compared1
When you look at the guiding philosophy for project management, it is defined in the Project Management Institute in their Body of Knowledge2 (PMBOK™). Project managers get tested and certified based on this knowledge. Emphasis in the PMBOK™ is placed on planning, organizing, staffing, directing and controlling the project tasks whose purpose is to satisfy project requirements. Such requirements are expressed in terms of scope, cost and schedule, i.e., the triple constraint. Work to be performed is addressed from an activity- and task-oriented point-of-view in a step-wise or waterfall manner. Progress is assessed using a series of formal reviews and lots of reports. Metrics and documents are generated at key points during the development process to identify and address issues and provide evidence of completion. Because tasks may have interdependencies, existing ones may need to be completed before new ones can be started.
In contrast, agile efforts focus on the delivery of working software by teams developing features under the premise that they provide value3 to the customer. Working software is released frequently beginning soon after the project starts. Agile teams strive for simplicity, flexibility and a minimum of documentation, metrics and controls. Feature mapping is done by release during the development to identify what functionality will be delivered, when, and why it is important to the customer. A Product Owner acts as the voice of the customer and works as a full-time member of the team to prioritize the release contents. Progress is assessed based how well the working software products satisfy the customer needs. In contrast, traditional projects are evaluated against requirements which are often out-of-date and ambiguous.
Project managers plan and control their jobs using criteria established for completion milestones. In contrast, agile managers define their releases in terms of the features that need to be delivered and their acceptance criteria. While both approaches get the job done, each defines success differently. To illustrate the point, think of the managing a project using a hierarchical diagram that shows what task inputs are needed to generate outputs at key milestones starting with requirements and ending with delivery of the software. In contrast, view agile product generation using a network that shows which features must be generated to satisfactorily complete specified business processes and get the required work done satisfactorily. As another way of looking at the differences, view project plans as deep and rigid and agile networks as flat and flexible, i.e., more agile.
The Project Manager is the person who is responsible for initiation, planning, execution, control and completion of the project. Project Managers spend most of their time defining and tracking milestones and determining progress. Their primary job is to ensure that all of the requirements (scope, cost, and schedule) established for the project are fully and faithfully satisfied as it is implemented. Requirements are defined in specifications which outline the functions needed, interfaces and performance expectations for the job.
In contrast, a product manager bears the responsibility for product definition, introduction and delivery on an agile job. Product managers spend most of their time mapping user stories (requirements) to releases as features are identified, prioritized, implemented and completed. Work is typically performed on a best-effort basis by a permanent team in iterations. The product manager owns the architecture, while the Product Owner works with the team as the voice of the customer.
Projects are aimed satisfying the software requirements, i.e. the rally point. Satisfaction is defined in terms of outputs that fully satisfies scope, cost and schedule goals with no exceptions. In order to succeed, project managers define and baseline the requirements as early during the development process as possible. This provides them a solid baseline to work from. Because failure is not an acceptable option, projects spend as much as half of their time and effort defining the requirements4 before a line of code is written.
In contrast, product managers define the features the customer identifies as the most important, i.e., those that provide value. Because agile teams release working product frequently, i.e., every two to four weeks, the customer sees the progress they are making release to release. If they do not like what they see, they change the requirements for the next release to accommodate their new product definitions and priorities. Priorities can vary so that the features that are deemed to be most important are delivered first. Evidence of progress is provided via the working product, not through reviews, metrics and/or documentation.
Project managers organize and staff their project to satisfy the requirements using teams that are created for that purpose. In other words, they staff an effort and schedule tasks to be completed based on estimates of what they believe the resources are that it will take to satisfy the requirements. If scope varies, i.e., requirements change, as the project unfolds, they seek budget or schedule relief. They often over-run the budget and/or deliver late when they do not get the relief requested.
In contrast, product managers use teams of a fixed size to develop as many features as they can on a best effort approach. They do this by committing to frequently deliver software that provides best value based on the priorities they are set for the job. If scope or schedule changes, they focus on delivering the high priority features and backlog the rest. Backlogged features are worked into future releases.
To control the progress of a project, work is planned and tracked using milestone completions. Reviews are held and documents produced to provide proof that the completion requirements set for the milestone were satisfied. Reviews are held, documents generated and metrics tallied to provide evidence of progress. In contrast, agile product teams deliver working product to provide customers as evidence of their progress.
Project managers act as the focal point for a project and as its spokesperson. They provide the leadership needed to surmount any obstacles that are encountered as teams endeavor to achieve milestones with the resources allocated. In contrast, agile product teams are self-organizing and managed with team leaders being elected by the members. Teams are collaborative and use self-imposed norms to govern group behaviors. The Product Owner acts as the voice of the customer and the team leader serves as a focal point and spokesperson. A Scrum Master to administer team activities and facilitate getting the work done.
As noted, the rally point for project managers are the project’s requirements. Budgets and schedules are established based on the scope. Success is defined as satisfying the triple constraint. In contrast, product managers focus on delivering working code that provide customers with value. Product managers prioritize the work to ensure that the most important features are completed using available resources (people, budget and schedule. Success is defined as delivering a viable product with available resources. While such a product might provide less than 100 percent of the required functionality, it is delivered on time and budget.
In summary, I have shown that there are major differences in approach and philosophy between the project and agile no project management factions. Project management views its world from an output point-of-view. It is hierarchical, leader-dominated and focused on requirements. Success is defined as meeting the triple constraint. In contrast, agile efforts look at the outcome and whether value was provided. They are flat, collaborative and focused on product and product architecture.
The question that people often raise is “do these differences really matter?” My answer is “yes” because conflicts arise when organizations try to use one or the other approaches and do not understand the differences. That does not mean that organizations cannot use both tactics in harmony. Congruence can be achieved when an effective agile-at-scale program/product management infrastructure is put into place across the enterprise. Such an infrastructure melds the two approaches and philosophies together so that they can work in such a way that both flexibility and control can be exerted as development proceeds and software products are released. However, compromises have to be reached by both communities in order for such a venture to succeed.
My next blog will discuss some suitable solutions and some of the concessions each camp has to make when implementing such an agile-at-scale approach.
1 Shane Hastie – Linkin post, 8/6/208 (his table stimulated mine).
4 Barry Boehm, et. al., Software Cost Estimation with Cocomo II, Prentice Hall, 2000.
5 Carl Pritchard, Risk Management: Concepts and Guidance, 5th Edition, Auerbach Publishers, 2015.
You can call, email or correspond with the author of this report at:
Donald J. Reifer
La Quinta, CA 92253
Phone: (310) 922-7043
Web site: www.reifer.com