Agile references for PMs

This post was originally published here.

By “PM”, I’m referring to Project Managers.  Adopting Agile can be a scary proposition for those entrenched in waterfall processes.  I have a lot of sympathy for PMs whose dev team decides to switch to Agile out from under them.  PMs need not be left behind, and in fact, have a very valuable role in Agile development, just not what they might be used to.  I see it as a re-education on the reality of software development, that Gantt charts don’t define reality, they distort and mislead those trying to make decisions based on reality.  Here are a list of references that will help those on the PM side try to make sense of those crazy developers and their Agile ideas.

• Intro to Agile and overview
• Quick intro into Lean, an Agile management process, from Fred George, a VP at ThoughtWorks
• Agile & Iterative Development: A Manager’s Guide, Craig Larman

• A great book on the history of iterative development and an overview of several Agile processes

• Agile Project Management, Jim Highsmith

• Guide for PMs to learn or adapt Agile

• Agile Manifesto

• Also check out the list of principles

• Specific processes
• Scrum process guidance from the VSTS process template, Scrum for Team System

• Great presentation and overview of Scrum

• Agile Software Development with SCRUM, Ken Schwaber

• Explanation of key Scrum roles, artifacts, and processes in more detail

• Agile Project Management with Scrum, Ken Schwaber

• Case studies from PM and other role’s viewpoints on many different projects and scenarios

• Enterprise Scrum, Ken Schwaber

• Scaling Scrum out to the enterprise level

• Lean Software Development, Mary Poppendieck, Tom Poppendieck

• More information on Lean, which evolved from the Toyota production system

• Other PM-related activities
• Agile Estimation and Planning, Mike Cohn

• Guide for creating realistic, accurate estimates for use in any Agile process

• User Stories Applied, Mike Cohn
• Or, why “The system shall” style requirements are evil

Eliminating the PM role is ultimately a mistake for a dev team moving to Agile, as someone eventually has to answer the $$$ questions.  Putting the onus on the development team/organization to determine costs, staffing, direction, etc., can drag their focus away from delivering business value.  Not having a PM on your team (or reducing the role of the PM) is the quick-and-dirty fix to a dev team’s Gantt chart nightmares, but eliminating that role won’t address the business needs of having the role in the first place.