I admit, I used to love project plans. I was a master of MS Project, with a sub-specialty in GANTT charts. I could link and unlink, change durations and critical paths with the best of them. You need a project to end in November, bang! it ends in November (the 30th, but still November).
Now, I cringe when I see them. I realize how much wasted time and effort went into these. And the wasted bullshit. “Can you finish testing by the 15th?” “Abso-fucking-lutely” and they still aren’t finished to this day.
Douglas Adams summed up deadlines very nicely with this:
Hours spent changing dates, futzing with dependencies, all to make something that wasn’t going to happen. Countless useless meetings, that had been scheduled and re-scheduled multiple times, which to be honest, should have been the first clue that the plan wasn’t going to work.
Under Agile the fixed project plan goes away in favour of getting work done. However, the Project Management Pyramid still holds in one aspect, flexible scope.
Utilizing Agile you are able to get a better understanding of scope and, it seems, people are more willing to negotiate on scope, which helps bring in the cost and time elements as well. You only have 3 months until release? Fine, we are going to work on the items that have the highest value.
All this doesn’t mean you don’t need to have a plan (and saying this is going to make some of my friends in the Agile community get mad at me). There are other parts of the organization that rely on the output of the development effort and need to have an awareness of when things are happening so they can coordinate items on their side. Letting Load & Performance testing know that you are delivering, and when you are delivering, gives them the ability to plan for the work that is coming to them. Release management, sales, marketing, security, hosting, and support are all groups that need to have a forward notification that projects are coming their way. The main difference between a ‘traditional project plan’ and the agile plan is the way in which it is communicated. You don’t need to send a thousand line plan to all the stakeholders to get their approval and buy in.
You need to involve them in the Vision Sessions, the demos, and grooming sessions so they know when things are coming their way, can better plan for what is coming and put items on their own boards to handle the workload and timing. I’ve held hour long ‘planning’ sessions (they really were scrum of scrums but I couldn’t title them that) to make sure all the teams were aware of what was coming, and what changes were happening in schedule and scope.
No need to spend hours updating and sending out a project plan before a meeting, only to have the content of the plan change during the meeting, requiring a subsequent update that becomes out of date as soon as it was documented. Communication is the key.