A team was forming. Success was building. Confidence was growing. All in an environment hostile to high performing teams, yet hungry for them.
What was the source of the team's success? Was it a master plan from senior leadership? Was it the result of an intense training plan put in place by executives? Was it because the organization finally understood the maze of artifacts, processes and project plans from the PMO?
In fact, all the efforts laid down from the top had failed. Miserably! It came from the team. The team had the hunger to build working software. Software that had business value. It was the passion of the team that was driving a better way to build software.
A new movement was blooming. Would it survive? Would it be allowed to continue? The process police were gathering. Preparing to pounce. There was little tolerance for doing anything outside the PMO process. It did not matter that the PMO process was not working. After all, the organization just needed just a little more time to get better. How could it miss. The PMO had everything under control. All those documents and artifacts, templates, and milestones contained in those highly detailed plans.
Delivering working software is difficult. It takes an entire team focusing on business value, working through blockers, driving code with tests and seeking and adapting to feedback. Continuously. It works but is hard work.
In the enterprise, every team needs a Sheepdog. The team's Sheepdog protects the herd, that is, the team. From what you ask. From all those that are willing to tell team how to do its job. Guidance from people responsible for delivering nothing ... except guidance.
The process police don't look at what the team has delivered. They don't care that the customer is happy. Instead, they are mad. Very angry. Threatened. The team seems to be breaking all the rules. They don't have a project plan. A project plan with details going out perhaps a year or more. Full of Work Breakdown Structures. Estimates for everything. Dependencies upon dependencies. Highly precise, but in the end, very inaccurate.
Along comes Agile. The team has story cards with estimates generated during planning poker. The estimates aren't in hours but points. Points? What are they? How can this possibly work?
The Sheepdog not only has to understand Agile. The Sheepdog has to understand Classic Project Management. It is necessary to understand the old and the new. While protecting the herd, the Sheepdog will do battle with the PMO, with managers and executives. The Sheepdog has to be able to explain how Agile is disciplined, responsive and delivers working software. How it address the fundamental flaws in a waterfall process that is deterministic. That a process which primarily relies on big up front planning instead of leveraging continuous planning, that has long feedback loops instead of tight feedback loops, will in the end deliver with little chance of success of a satisfied customer, if it delivers at all.
A key role of any Agile leader is to be an effective Sheepdog. A Sheepdog has to know ones team and know the threats to the team. While defending the team, the Sheepdog must learn to teach those that fear Agile to respect and leverage Agile. Only then will Agile be allowed to thrive.
If a team does not have a Sheepdog, its long term success is at risk. The herd is likely to be scattered.