How to link Scrum release backlog to conventional project plan (MS project) in keeping sprint benefits?

Question

We use the Scrum methodology for our software development. Since software development isn't the core activity of our company, and since this company isn't agile methods oriented yet, I need, as the ScrumMaster, to provide an interface between the Scrum methodology and the company.The top management asks me to maintain a classic project plan, using MS Project, at mid-term (6 months), with resources defined, etc...My question is: How can I provide a useful project plan for my top management while keeping all the flexibility and agility of my team in the daily organisation and operation, and also stay Scrum compliant?!For me, defining resources in the project plan removes a lot of benefits of sprint concepts, right?

Answer 1

Your dilemma is not unique. Executives are generally uncomfortable allowing projects to go on without some sort of milestone-based reporting. Without it they have no concept of whether their investment in the endeavor is paying off, what unforeseen risks may be forming and whether the budget will be met.

Lets begin by saying Agile is NOT a project management methodology. What!? Yes that's right. A methodology requires methods be applied in getting from here to there. You are not very Agile if you are following strict methods. That said, Scrum, of all the Agile approaches is probably the most rigid.

The point is, don't go looking for a tried and true approach that fits all projects and all organizations.

In your situation I suggest you establish, crisply, what do executives want to know. For example, almost universally, they want to know a) how is money being spent, b) are resources working efficiently, c) are we going to get everything done when the customer expects it to be, d) has anything changed in the risks identified at the start and, e) how will we learn of 'issues' that the team is not able to solve on their own?

Breaking this down, find out what kinds of expenditure-data they want and how often they want it. Determine how you will collect this data and how you will present it (i.e. MS Excel, Crystal Reports).

Find out who among the execs want to learn about resource conflicts and impediments. You may find that they want to meet you weekly or biweekly face-to-face for this.

Identify a few key milestones (maybe 3 to 5) that can realistically be set to a date or narrow timeframe for completion. You don't need MS Project for this -- but if the execs are used to reading MS Project Gantt charts, and they insist on it, put the major milestones in (perhaps they are epics or set of epics), fix their dates and use high-level, broad descriptions of the work to be done in between. Maybe it's the deliverable(s) and a list of the repetitive steps taken by the team (design, code, unit test, demo) or the name of the sprints for the work in-between, but try to avoid tasks that, if permitted to return to backlog, you end up editing the Gantt.

For risks and issues, do the same as I stated for resource conflicts and impediments. Consider lumping them all into the same meeting. Naturally the execs will want these things written up before the meeting, updated with decisions made during the meeting, and saved somewhere for posterity.