Agile Artifacts

Question

Do Agile projects have Charters, project plans and baselines?

How to obtain the classical artifacts (which are necessary to report back to the business) in an Agile environment which focuses on delivery?

Answer 1

When using the Scrum framework reporting is different to traditional development.

The four main reporting mechanisms are:

• The Product Owner - As the PO is typically the business person who is most interested in the outcome of product development, their heavy involvement with the Scrum team provides a very direct form of reporting.
• The Sprint Review - Happening at the end of each sprint, this ceremony is a window in to the progress of the Scrum team. Anyone in the business interested in the product can (and should) attend the Sprint Review to see how things are going.
• Information radiators - As Agile emphasises transparency, Scrum makes public the product backlog and sprint backlogs. These give a clear indication of progress and a good idea of what is to come next.
• Frequent releases - By releasing frequently (ideally every sprint) the business gets to see exactly what has been achieved and how much is still left to do.

Given these forms of reporting, there should be no need for traditional development artifacts like project plans, milestones and baselines.

I've described Scrum here, but other Agile frameworks also typically avoid the need for traditional development artifacts.

Answer 2

Project plans and baselines for Agile is like trying to fit a square peg in a round hole

The basic premise of agile is that you cannot make a project plan and baseline it - because requirements change and technology changes.

To make a project plan, you need to know all of the requirements in advance, create a work breakdown structure (WBS) that accounts for all of the tasks needed to be done to accomplish those frozen requirements. Agile says that you cannot know all of the requirements in advance, that they emerge during the project. This is the reason Jeff Sutherland, co-founder of Scrum, says:

The venture capitalists I work with say they have never seen a correct GANTT chart in a board meeting.

Also see this report from Forrester Research, "Common Project Management Metrics Doom IT Departments to Failure":

The metrics organizations commonly use to determine whether an IT project is a success or a failure—whether the project is completed on time, on budget, and delivered the initial requirements—do more harm than good for IT departments.

"Project requirements change for a variety of reasons, and schedules and budgets change during the lifetime of the project based on better information as to effort, complexity and interdependencies."

So, to answer your second question first:

How to obtain the classical artifacts (which are necessary to report back to the business) in an Agile environment which focuses on delivery?

Don't try to obtain classical artifacts in an Agile environment. They will show successful projects as failures and vice versa.

And to answer your first question:

Do Agile projects have Charters, project plans and baselines?

Agile projects do not have project plans in the traditional sense and certainly not baselines. But Agile is not anarchy. As a business, you do need to know what the ROI is before making an investment decision. You can certainly have a Charter. But instead of project plans and baselines, you can have a roadmap with specific business goals you are trying to accomplish in each sprint/release.

Answer 3

No, not really. Agile principle #1 is : "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" and the principle #7 is: "Working software is the primary measure of progress".

Forget the classic artefacts for reporting: every stakeholder will be more than happy to see a working product adding or improving regularly functionalities instead of a gantt chart.

If indeed is not the case, then the project / environment / culture are not suitable for an Agile approach. Agile is not a silver bullet for every project / everyone.

Answer 4

There =are= useful artifacts from Agile projects. At some point, for instance, you will want to be maintaining "built as" diagrams, showing what you built, how it all fits together, etc., so that the people maintaining the software and/or the network, or whatever you built have some reference. These docs can also contain information about things that aren't easily abstracted from the code later--the callbacks or callouts (and who maintains them; where credentials, roles, whatever are stored, etc.) You will know what is useful to maintain for your team--what will help people a year from now when some pieces of the project want to be refactored, and when it may take more than exploring the comments in individual bits of code to figure things out.

At the same time, it is very useful to start an initiative--an epic or larger--off with a week spent doing User Story Mapping or other work to get a sense of what is being built. That may be stored as simply as pictures of stickies on the wall, but that effort will help give a sense of milestones (at least as perceived from the beginning of the initiative) and other critical pieces that will help resource planning further up the organization.

Working code is more important that documentation, but there will always be points where some documentation--in a Sharepoint or a wiki or other context-maintaining environment--is valuable.

And note, that as other people have already written, traditional artifacts like charters and work breakdown structures are usually irrelevant and counterproductive.