I have started many agile engagements and I always get asked where is your project plan? Can you tell me the project milestones and target dates? Now, mind you this is before I have anything resembling a backlog or attended any kind of discovery workshops with the customer and core team members. I try to explain that while we have a Statement Of Work (SOW), it is high level and purposely vague and it will take some time before we understand the requirements and have a backlog. This means whatever plan I have produced is subject to change, in fact it will change.
After all, I am not a Soothsayer, and what I understand early on during a project is but a very high-level understanding of what will be delivered. Agile frameworks like Scrum lend themselves to adapting to change, but it never seems to satisfy the need for certainty that sponsors and other key stakeholders seek. So the team will press on gaining a greater understanding of what needs to be accomplished and a solution evolves, but even after gaining insight things change. Even simple things like setting up cloud accounts with the services and access the team needs can take weeks instead of days in some organizations, throwing your plans out the window. A user story that is targeted to take a week, drags on for several sprints as you are dependent on other teams who have their own challenges to deal with. An initial design using a particular technology after further consideration becomes unfeasible, and then it is back to the drawing board.
Agile projects tend to evolve as deliverables change, and the cold fact is your project plan is constantly changing. This is why agile frameworks like Scrum were created because the waterfall methodologies that were steeped in planning generally failed to deliver to the plan. If you can’t coach your sponsor and other senior executives that change is inevitable, then you will likely be subject to a mountain of criticism. This is where the ScrumMaster and Product Owner must seek to provide reality checks and be persuasive to stave off the blind adherence to a plan.
So that is why the authors of the Agile Manifesto stated: “We value responding to change more than following a plan”.
AgileMethods.blog 