NewYork2008:Agile Project Management

From Managing Nonprofit Technology Projects Wiki
Revision as of 17:35, 13 January 2016 by Miriam (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


What's the difference between project management methodology and software development methodology? What's the difference between (so-called) "traditional" project management and agile project management? When the Agilists today talk about traditional project management, don't they really mean bad project management? Can traditional project management be good (and if it is, it is agile)?

In this session we will:

  • Talk about the difference and overlaps between project management methodology and software development methodology
  • Talk about some of the perceived and some of the very real differences between traditional and agile project management
  • Share experiences using agile methods to manage software development projects

Session Notes

Agile Project Management

Defining terms: Agile vs. Traditional (Waterfall) Read the “Agile Manifesto” – the defining document written by software developers.

Some qualities of an Agile method:

  • Agile does not mean early launch.
  • More about simplifying the process, evaluating as you go.
  • No large document/budget to sign off on at the start.
  • Requirements are modified as you go.
  • Decisions are made on an ongoing basis
  • Stories (as a unit of measurement) rather than requirements. Stories reconnect the client with the overarching goals.
  • Certain amount of stories per iteration (phase).
  • Bill by time/materials.
  • After iteration, reevaluate priorities and move to the next specification/iteration (collection of stories).


  • Agile Software Development
  • Managing Agile Projects, by Sanjiv Augustine
  • Agile Project Management Using Scrum

Discussion of SCRUM (one way to use Agile): Teams of developers who come together every day to ask, “What did we do yesterday, what will we do today, and what stands in our way?” Plan “sprints” (iteration) of thirty days. Assign “points” to each story – more points for more work – and decide how many points can be finished. Large stories are called “epics” and are divided into smaller stories. Deliver and test at the end of each iteration. Client representative is involved in the process so they can give immediate feedback. Revisit priorities. Decide on next sprint.

Concerns about Agile:

  • How do you deal with budget? Yes, this method is problematic with a fixed price. But you can still do an overarching document at the start so you can track money – put it on a wiki and revisit it often. Can be revised, not written in stone, but still important to have a general sense of how much money is left. Lessens chance of “scope creep” or going overbudget – constant reevaulation.
  • How do you manage client anxiety? They do need to trust you.
  • Client has to be more involved. Gather stories, be available for questions from developers.
  • What about documentation? It is still important, but everything is not specified to the letter.

Two members described their experience working on traditional project, working in a general agile style, and using the scrum method.

Discussion of Extreme Programming (another way to use Agile):

  • Team up developers so one is coding and the other is testing, helping, etc.
  • Doesn’t cost more, can save money.

Sometimes when people refer to traditional/waterfall methods, they really mean “bad” traditional method. There can actually be a middle ground. More about changing the terminology and expectations. More about delivering value.

Importance of “soft skills” when using this method. Need to be positive, encouraging. Lots of face time, etc.


  • PM vs Software development – they are very different.
  • There are less differences than you might think before the traditional and agile methods. Can still do work breakdown process and have a budget. More about a different way to look at the same thing. Focus on process and value. Connect back to intangible goals/mission.
  • Simply doing things in chunks is a revelation.
  • Things can be changed later!
  • Really just admitting that you can never control scope.