Yes Virginia, there really ARE PM tools which can support both agile and waterfall projects!

swissarmyA challenge faced by organizations attempting to adopt agile practices is deciding what project management documents are valuable – which traditional lifecycle ones should be maintained and which can be discarded?

This is more common than one might assume owing to the reality that very few companies are able to implement a specific agile methodology exactly as this is usually not going to meet the needs of all of the different types of projects within their portfolios. What works well for a “start-from-scratch” application development project may not suit the needs of a business process improvement engineering initiative even though agile principles could help both.

While this is not intended to be an exhaustive list, here are some of the documents which should be used regardless of whether a waterfall, pure agile, or hybrid approach is followed.

  • Project charter: In its most basic form, the charter authorizes the existence of the project and helps to align customer, stakeholders, and team on the expected outcome for the project. Without an approved, distributed charter, the team runs the risk of significant shifts in overall project direction beyond those which even agile approaches can address.
  • Project plan: Size, content and structure can vary between projects, but there is still the need for a document which formalizes governance structure and processes for the project, identifies assumptions, prioritized constraints, resource requirements and provides an understanding as to how the project scope will be delivered and over what timeline. This latter information could be documented using a WBS and schedule on a traditional project, or via a work items backlog and iteration or sprint roadmap on an agile project.
  • Decision records/requests: Regardless of how flexible a project is, there are going to be key decisions on which fundamental project outputs rely which should be formally documented, approved and shared. The volume of these is likely to be smaller on agile projects as compared with traditional projects.
  • Change requests: Similar to decision requests, while these might be used to a lesser extent on agile projects given the likelihood of scope being the most variable constraint, there is still the need to formally acknowledge the decision of the customer to extend or reduce other constraints. One example of this might be the decision to close the project after the completion of the current sprint if the customer’s needs are met in fewer sprints than originally planned.
  • Risk register: A disciplined risk management process is critical for both agile and traditional projects otherwise team velocity is likely to be a fairly unpredictable forecasting measure.
  • Action and Issue logs: Although these are less used by the team on an agile project due to the use of standup scrums or similar tactics, the role of the PM is to remove hurdles from the team’s path and these logs will be a crucial communication tool with key stakeholders.
  • Status reports: Performance measures will vary between agile and waterfall projects, but there is still the need to keep key stakeholders apprised of quantitative and qualitative information on a regular basis.
  • Project close out report: Although this report can contain significantly more, at its most basic, it should provide an understanding of what was accomplished or delivered vs. what was expected/planned, and list outstanding activities or next steps to facilitate transition.

Purists from both waterfall and agile schools are likely to take exception to what they may perceive as too short or too long a list of PM documents. As with most PM practices, this list only reflects the “what” and not the “how” (or rather, “how big”) – that I leave to the individual practitioner as “just right” is always in the eye of the Ursine beholder!

Categories: Agile, Project Management | Tags: , , , , | 3 Comments

Post navigation

3 thoughts on “Yes Virginia, there really ARE PM tools which can support both agile and waterfall projects!

  1. Vaughan Merlyn

    Great perspective! I sometimes see “agile” as a euphemism for “seat of the pants.” Your list reminds us that there are quite a few ‘traditional’ document needs that apply in just about any type of project!


  2. kbondale

    Thanks for the kind feedback, Vaughan.

    Unfortunately, too many agile-wannabes never get to the last line from the Manifesto: “That is, while there is value in the items on the right, we value the items on the left more.”



  3. Kiron,

    Completely agree, a well written piece and one of the reasons we support the use of DSDM Atern. It may call them slightly different things but it has that same set of documents and a process for establishing and then using them through the life cycle of the project. Helping people put Agile on a realistic substantial footing.

    Our Community Edition provides the DSDM Atern agile method for free so please do have a look, nice and easy to follow.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at

%d bloggers like this: