One of the most common questions I get is “How do we do Project Management in Scrum?” and I can understand why. Sometimes it’s not good enough to simply manage your product development sprint-to-sprint. Sometimes we release our Product every two, three, six, or even twelve months because that’s when our users need (and expect) it. Sometimes we must make a statement like: “We are going to release Features A and B in 3 months (7 2-week Sprints) at a total cost of 2800 Hours,” and be able to say it with a straight face. Many of us live in a world that requires us to make predictions (that we call Project Plans) about what and when things will happen. In this world, a Project Plan consists of three things:
What are we building? (Specifically, we need to know ‘how much’ stuff are we building)
How much will it cost? (Traditionally, in software development, this cost is given in Hours)
How long will it take? (This is often given as a duration or a number of Sprints)
Let me give you a brief overview of what you need to do in order to create and manage Project Plans. This is not a How-To manual; it is only an overview of what you have to do. The skills and knowledge you will need in order to actually be able to do it are way out of scope for a single blog; this is merely a sketch of the solution.
And, this is a simple discussion, so I’ve simplified it. Software Projects can be complicated and include lots of things; but at their core is Releasing a software product to users. So, when I wrote this, I focused on the simplest possible project — a single Release of a single Product.
Anyway, I must first introduce a new role, the Agile Project Manager (APM).
The Agile Project Manager
The Project Plan is ‘owned’ by a person playing the Agile Project Manager (APM) role. The APM is not a Scrum role, but is a role a Development Organization often needs to have. The primary Responsibilities of the APM (according to standard Project Management theory) are:
- to Produce the Project Plan, determining initial (baseline) versions of the Cost, Scope, and Schedule for the Project; and
- to Manage (Maintain/Update/Re-Baseline) the Project Plan, throughout the Project, making sure the Project Plan is “in sync” with reality at all times.
Because this is a Scrum project, and the development is driven by a Backlog, it is also the Agile Project Manager’s responsibility
- to Synchronize the Backlog with the Project Plan; working with the Product Owner, the Stakeholders, and the Team, in order to assure that the Backlog represents the same work as the Project Plan.
The APM’s primary Accountability throughout the Project — her “One Big Thing” — is to be able to justify the current Project Plan at all times; the APM must be able to explain how the Plan’s Cost, Scope, and Schedule are supported by current data — why the plan is ‘in sync’ with reality. And, by the way, having the Development Team promise that they can do it is not data — we must be truly empirical here… just sayin’…
The Development Team’s job is ‘to do their due diligence and use an appropriate Standard of Care to get Stories Done as fast as possible, without lollygagging or gold-plating,’ and we must make sure the APM does not interfere with this by providing pressure on the Developers to conform to the assumptions of the Project Plan. The speed of development is based on many factors, including the Development Team’s abilities, the Product’s Definition of Done, necessary Chores, Impediments they run into, and so on. The Development Team already has a ScrumMaster and a Product Owner who are making sure the Development Team is as effective and efficient as possible, so the APM should just get out of the way and let them do their jobs… just sayin’…
There’s the foundation for the marriage between Agile Project Management and Scrum. Now what? Stay tuned for the next installment, Producing the Project Plan.