arlene trimbleAssistant IT Director| Local GovernmentAlamo, Ca, United States
In the Agile space, what elements or information do you include in your project plan?
To whom do you distribute the project plan? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Nothing change when you use agile approach (agile is not agile software development only). The information you will use depends on the project management process you will use and the tools and techiques that you will use. Sometimes if you select a specific agile solution delivery method (SCRUM, DSDM, etc) it will determine the amount of information a subsidiary plans you will create. Saving Changes...
Strictly speaking, in Agile (scrum) there is no project plan, or project manager. The scrum master basically referees and enables the work, but does not manage. Projects are self-managing, relying on specific stakeholders - including management - to fully participate according to their roles.
Project scope evolves continually from an initial set of User Stories; time and cost are balanced dynamically with scope as the project moves forward. If you fix time and cost, then it's just a matter of shaping what can be accomplished, but where's the fun in that? At the end you hopefully have something coherent that meets the evolved expectations.
Anything can change as long as the implications and consequences are accepted.
An Agile project plan might take the form of a pact, spelling out the roles, scheduling sprints and related reviews, approvals, logistics, etc. Assuming there's conventional management somewhere in the organization, the plan might also include policies and processes specific to Agile (namely, as opposed to conventional management). It has to be a pact because in order for Agile to work, there has to be total buy-in from all parties and full participation.
One could see the PM role as wrangling all the stakeholders in order to establish and maintain buy-in, because that's where Agile typically fails. Without buy-in and participation according to role, Agile quickly becomes an excuse for sloppy planning, haphazard execution, and finger pointing when it gets ugly.
I say make a project plan that prevents those things from happening and keeps everyone on track, and you've taken a good first step.
In Agile there is something called "Planning Onion" (google it and you will find many images).
The concept is simple: you can have plans for every level of the onion, from Strategy to Day through Portfolio, Product, Release and Iteration. Each level needs a more detailed plan.
And the methodology you choose to manage the project, gives some artifact or ceremonies to follow. Saving Changes...
Laura CarringtonPortfolio Management Group Leader| Oak Ridge National LaboratoryOak Ridge, Tn, United States
I agree with Frank Revi's comments. In addition, from the Agile Manifesto, responding to change is valued over following a plan. So, planning is done iteratively throughout the project, in planning sprints and releases. This is in contrast to the planning being done up-front as with traditional waterfall projects where there is a project plan and full requirements, and a design before any work can begin.
In agile, there isn't a project plan but a project charter and maybe a team charter. But, these are flexible, intended to change over time. There is also a concept in agile of doing 'just enough' planning to reduce risk/rework.
A project charter could include the business case, project vision and goals, measures of success &/or definition of done and what obstacles there may be with mitigation. But, these can change over time and adapting to change is fundamental to the agile methodology. A project charter, depending on your organization, is typically what you need to get project funding.
A team charter, if you have one, has working agreements, maybe values/strengths of the team and how the team works together.
Saving Changes...
Peter MorrisPM Consultant, Author| INDUS TechnologySan Antonio Texas, United States
I've never bought the popular notion that a CSM can replace the Project Manager. There must though be some consideration for communication. While typically Agile teams resist documentation of daily meetings due to time constraints and the need for team members to speak freely, a minimum of weekly documentation of progress in the form of burndown, velocity, or whatever metric the Agile PM chooses is necessary in order to keep the PM informed, since the PM does not normally attend these daily meetings. Saving Changes...
In Agile projects we do not have a very detailed plan or a lots of documentation, but I insist that there is always a project plan. To start with, we have to have at east an outline or a very high level project plan.
Talking about the role of project manger and scrum master are completely different. I would assign the responsibility of outline planning to the project manager, and the teams are facilitated by scrum master. project manager or sponsor may also play the role of product owner or it may be the product manager. Saving Changes...
In my experience the plans are although not elaborate, I included the the expectations (visions), outcomes(missions), the initial scope, the initial schedule or roadmap, the exit or acceptance criteria, the load (velocity), the expected budget but not final, the benefits and beneficiaries of the project. Sometimes, the need and necessity or justification as well to go for agile.
The stakeholders are the senior management, the team and most importantly the customers. Saving Changes...
