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”.
The third statement of what we value from the Agile Manifesto states:
Customer collaboration over contract negotiation
This is an interesting statement for me as I am a consultant and the basis for my engagements with customers starts with a contract, in my case a Statement of Work (SOW). While an SOW is the starting point it is often left fairly vague in some ways to allow for adaptation during the engagement. We do this purposely so that we can work with the customer to uncover the requirements that fit into the broader framework of deliverables.
It is clear to me that the authors of the Agile Manifesto felt that clearly collaborating with your customer was superior to using a contract as some kind of checklist. The project may become highly adversarial in the event that we spend our time fighting over items in the contract instead of making sure we are collaborating with our customers. There is nothing less agile than simply following a contract instead of being focused on delivering the right business outcomes.
I have been as guilty as the next person is thinking that the customer understood the contract in detail, and when we delivered to the letter of the contract we actually had issues. This became my fault by not collaborating with certain stakeholders to the degree I should have. In fact, I know a fair amount of customers who never even read the SOW, so thinking you can use that later to negotiate delivery is somewhat meaningless. On the other hand, I have worked with customers where they analyze every sentence, clearly using the contract as the source of truth for all deliverables. This is both painful for the project team and really not in the customer’s best interest.
So what’s the best thing to do during an engagement if you are to adhere to the agile tenant where collaboration is preferred over contract negotiation? My advice is to do the following:
- The contract is a starting point for understanding high-level deliverables, maybe these deliverables become Epics in your backlog.
- Let collaboration guide your team with the focus on creating business outcomes, instead of blindly producing what the contract outlines.
- Instead of spending your time talking about what is in the contract, it is better to collaborate with the customer to show them that you will over-deliver and have their best interests at heart.
While this seems like such a simple statement that we value collaboration over contract negotiation, it speaks loudly to the real intent. In almost every engagement I’ve been a part of, requirements change as we learn more, and an agile team knows this and will use it to their advantage to produce something better than originally scoped out. Letting a contract dictate the total scope of the engagement and ultimately what is delivered in the end is not agile, but instead waterfall.
I would love to read your feedback on this subject.