The juxtaposition of the term ‘Agile’ and the term ‘Project’ actually creates a bit of a conundrum.  They may even be contradictions.  However, these two words are used together as a term constantly as Agile continues to make its way into development teams across the world.  This is a big mistake, in my opinion.  Agile is inherently goals driven (think business results, such as “Reduce customer trouble tickets by 10%”), whereas a Project will involve identifying, planning for, and executing specific actions (scope) to achieve a result within a specific time frame and for a specific cost.

Consider the below principles of the Agile Manifesto (there are twelve in all), as currently stated on Wikipedia:

1. Welcome changing requirements, even late in development
2. Working software is delivered frequently (weeks rather than months)
3. Working software is the principal measure of progress
4. Sustainable development, able to maintain a constant pace
5. Close, daily co-operation between business people and developers
6. Face-to-face conversation is the best form of communication (co-location)
7. Projects are built around motivated individuals, who should be trusted
8. Self-organizing teams

Now let’s take a look at the main definition of a Project, as defined by Merriam-Webster:

1. a specific plan or design : scheme
2. a planned undertaking: as
3. a definitively formulated piece of research
4. a large usually government-supported undertaking

In Agile, we iterate into our solution, and we focus on delivering working software with each sprint.  With Projects we set a specific goal, we plan to reach that goal, and we execute…projects start and projects end and are measured against their estimated scope/schedule/budget (loosely speaking).  Agile is by its nature ambiguous and lacks specificity…it suggests that we don’t know what the detailed final solution will be when we start out, but that we should just do and refine our goals we progress.  Here is an example of an Agile Roadmap or Task Board

For many businesses, we also have projects that can last years, not actually delivering working software for months or years due to complexity of organizing around a broad, integrated environment, shared resources, and changing priorities.  For many executives responsible for funding projects, late requirements that may lengthen or add cost to the project would make them feel like the team didn’t do enough planning up front and would consider those late realizations a blight on the project team.  In the ever evolving global economy, many companies have thousands of employees that are spread all over the world in different time zones making colocation impossible.  Finally, most management funding specific projects want to understand the cost of the work, which includes knowing who needs to be involved and what they’re going to be doing…this involves a LOT of planning.

All of the above are contrary to the tenets of agile previously listed, however, successfully delivering “Projects” in an “Agile” environment may be thrust upon you nonetheless.  In this case, I have found it best to create a waterfall overlay of your project, which should be used from the outset to report against status of the initiative, rather than trying to provide various Agile metrics such as velocity, burndown, etc., as these metrics really only matter (…or have in my experience with large, complex organizations) to IT management, and the scrum team (to measure how efficiently resources are being utilized).   When you are working with a project, you can generally chunk it up into phases…pick your methodology…the phases are generally the same:

1. Initiation, Discovery, Inception
2. Elaboration, Requirements, Design
3. Construction, Development, Test
4. Transition, Delivery, Deployment, Post-deployment

These familiar phases are something that sponsors and stakeholders can wrap their mind around, even though underneath your teams may be iterating through them on a sprint by sprint basis to manage the actual work.  If you are always speaking about the project in these terms, and include them in your status reporting, it will make a significant impact in terms of clarity in communications about a project.  Take the below example:

This example satisfies the curiosity around agile sprints, while providing more consumable data from a project-perspective…again, agile in it’s most practical sense is simply how we’re executing the work within each phase and ideally making the progress more efficient.  Always communicating about it in these terms will keep the sponsors and stakeholders from getting confused.  It’s not deception, it’s real, it’s simplifying, and it’s accurate.

On top of views like the above it will also help to educated your audience as to what agile is, and that the dates outlined need to be considered targets until the team iterates close enough to be more firm about specific time frames for delivery.  Armed with this view and approach, you should be able to add sense and insight in the puzzling world called Agile Project Management.  Your audience will appreciate and see you in a new light;  that of a Gantt Artist.  Good luck!