Vicki James, PMP, CBAP, PMI-PBA, CSM

I have the same thought each time I read an article or attend a workshop on “Agile Project Management.” Agile is not about project management. The title is “Manifesto for Agile Software Development.” The statement is “We are uncovering better ways of developing software by doing it and helping others do it.” Agile is a strategy for executing the product development of a project, not a project framework.

I attended a Puget Sound PMI meeting the other day that focused on project management in an Agile world. They had a panel of four Agile experts answer the question “does the project manager have a future in Agile?” The panelist unanimously agreed that the project manager does have a future in Agile. I agree. A development project using Agile methods requires a project manager.

I was following along on Twitter to see what folks where asking in the session. What I found was evidence of why project managers are not comfortable with the idea of Agile. This is because the word “Agile” is used in regards to project management instead of keeping it within the confines of product development. Let’s start with how the decision to develop a product using Agile methods begins. Someone decides that the project is a good candidate for Agile practices during project initiation. The project comes before the product develop framework is selected. This is just one sign of how Agile is not a “project management” framework.

Proof It’s Not a PM Framework

Project plans and delivery will be driven by Agile principles. This does not make Agile the project management framework. Look more closely at the project management planning tasks and see. Each question with the planning task stated below is an element that is not predefined in the Scrum framework (note: Scrum is the only Agile method that I have training and experience in). There is no standard process that the sponsor and team can understand and buy into with more planning. Documented answers to these questions are required for an adequately planned project.

• Scope –Scrum defines Product Backlog processes to define and track scope.

How will this be developed and tracked within this project? Meetings, recording and tracking tool, access by others.

• Activities – Scrum provides information on how to track activities and schedule by the product backlog, release roadmap, and iteration plans.

How will this be developed and tracked within this project? What tools will be use to develop and communicate the status within the team and to other stakeholders?

• Costs – Not part of the Scrum framework.

How will the project dollars be tracked and reported? The product development team does not need this information, but the organization stakeholders and sponsor will want to know the bottom line.

• Communications – Scrum defines Product, release, iteration, sprint review, and retrospective meetings.

Who is involved in which meetings and distribution lists? What is the schedule of known communications and who is responsible? What are the team guidelines on communication for within the team? What communications do the stakeholders who are not team members need?

• Risk Management – Product development risks are managed daily through the Daily Scrum.

Projects face added risks from the organization and external factors. How will these be identified and monitored?

• Human Resources – Scrum roles include Scrum Master, Product Owner, and team members.

Who is fulfilling each of these roles? What other resources need to be identified? Are there peripheral team members supporting the project? How do team members’ capacity affect velocity and team planning? How are they accommodated in planning and communications?

There are too many aspects to the project outside of the product development that need attention. Agile projects need a project manager to give support to the entire project. These are only examples from the planning phase of the project management lifecycle. The list will grow much longer exploring the full list of project management tasks.

Questions on Scrum

Below are some questions I saw via Twitter in the panel presentation on Tuesday. The answers show my opinion as stated above, based on my experience and education.
Who owns the project? Who is accountable?
The Agile team is responsible for the product development. The project manager is still responsible and accountable for the project. This includes ensuring that the direction and processes used by the development team will meet the goals of the project.

Which role or title has the most influence in Agile systems?
The product owner has the most influence in product development. She represent the user stakeholders of the system, elicit the user stories (features) to be developed, and keep up the product backlog list. The product owner is the `single wringable neck` for product development on the Scrum team.

The project sponsor has the most influence for the overall project. The project manager is responsible communicating challenges and status as well documenting and implementing any changes from the sponsor or organization stakeholders.

Could any team ever operate without a PM to coordinate, communicate, escalate, schedule, staff, coach, nurture?
No. Scrum is silent on what the structure above the development team is. The Scrum Master escalates barriers and issues. This implies that there is somewhere to escalate. Although the project manager may be the Scrum Master, the intent of Scrum is that is a member of the product development team is the Scrum Master. I believe the best model is a team member (perhaps lead developer or designer) is the Scrum Master and the project manager serves as a team coach to oversee the processes, monitor progress, and resolve project issues.

How does Agile work for (IT) infrastructure projects?
Agile is a software development manifesto. It was not developed to cover all projects of all types. It has been adapted in some cases beyond software development, but this does not mean it is appropriate to all projects. The International Institute of Business Analysis (IIBA®) does a good job of discussing how to choose an right approach for product development based on if the project is `plan-driven` or `change-driven` within the Business Analysis Body of Knowledge (BABOK®). An infrastructure project is likely to be a plan-driven project, meaning, “requirements can effectively be defined in advance of implementation.” Agile development processes are not recommended in this case.

Is Waterfall bad?
This goes with the previous answer. Agile and Waterfall both have a place in projects depending on the nature of the project. Michele Sliger pointed out several times that Waterfall practice today does not align with the Dr. Royce’s intention. We picked page 2 of a 9-page report and ran with it without due diligence or notice of the statement “…the implementation described above is risky and invites failure.” When defects are found in test “either the requirements must be modified, or a substantial change in the design is required…one can expect up to a 100-percent overrun in schedule and/or costs.” Dr. Royce remedied this shortfall with continuous feedback loops between all team members and end users throughout the process. Waterfall projects today rarely include this feedback loop early and often enough.

Waterfall is not bad. Agile may be better suited to projects where there is a high level of uncertainty in where the business value of the product will be found through requirements (aka “change-driven”).

Paper available at http://Agileconsortium.pbworks.com/w/file/fetch/52184636/Waterfall.pdf

Should Agile be announced or just done?
The manifesto begins “we believe…” This “we” needs be the team’s voice to be successful. I have run two separate projects where Scrum was mandated. The challenge is that time, resources, and training was not available to the team members to give them a proper introduction and practical practice for team members to have trust in the processes. Especially in a matrix managed organization, gaining trust with unconvinced team members is a huge challenge. Simply announcing Agile processes is not enough, the members need training, and commitment, or the project will suffer a new set of risks.

Comments Welcomed

I welcome all feedback in support of or opposition to this article. It should be an interesting conversation and I hope you will take part.

Special Thanks

I wanted to just take a moment to say thank you to the Puget Sound PMI for pulling this event together. The open discussion was interesting. The questions by Tweet helped to keep me engaged long after the presentation was over. Thank you to panelists Bryan Tew, Michele Sliger, Mitch Lacey, Werner Koepf, and Dominica DeGrandis for facilitating.

Related Links

• Information on Puget Sound PMI Meeting including speakers bios and more
• The Agile Manifesto
• My one stop shop for all things Scrum – mountaingoatsoftware.com
• Where is the Line Between Agility and Chaos? – Shoaib Ahmed
• The Three Phases of an Agile Project – Robert Kelly
• Agile Experts Say the Stupidest Things – By Jessie Fewell

Image Credits

• Unemployed – Image: winnond / FreeDigitalPhotos.net
• Questions/Answers – Image: Stuart Miles / FreeDigitalPhotos.net