The New Pact: Why Scrum is more than just a project model
One prevalent management mistake in Scum implementation is to assume that the introduction of Agile, Scrum, Scaled Scrum or similar ways of working essentially amounts to introducing new templates for project management, new agendas for status meetings and new titles for project manages and team leads, lots of certifications, an Agile manual on the intranet and then all is good.
Oh yes, you also have to add a proper splash of “Agile mindset” – and after that, the soft part becomes very fluffy and unclear. And that is where the trouble starts:
The actual suitability of introducing Agile is very often not analyzed.
Agile and Scrum fail too often due to misunderstood intentions between the involved parties.
Unfulfilled expectations and biased interpretations of each other’s motives can lead to disappointment and even conflict.
The initial setup is often tweaked and adapted without systems thinking but driven by urgencies, personal preferences or enterprise systemic pressure.
In the end, neither party reaps the benefits, compromises and dysfunctional adaptations plague the teams and their stakeholders, and the cost of Scrum implementation becomes too high or even meaningless.
When management concludes that “Scrum doesn’t work” or “Agile is dead,” teams simply lose interest, and people across the organization are left confused and disillusioned after yet another failed change management wave.
This scary story might seem exaggerated, but it happens in many variations. The key here is to understand the nature of Scrum and Agile. It might sound a bit pretentious, but Scrum really is a new pact between Teams and Management; it must be understood and agreed upon by both parties. Attempts to force it through will typically fail.
If forced by the teams, Management and stakeholders will not play by the rules and will undercut the effort.
If forced from the top, teams will not commit to and embrace the framework, and contrary to some current management beliefs, the adoption of personal values cannot be ordered.
What do we want to achieve?
This is the golden question often ignored in busy business life and, unfortunately, when introducing new ways of working in an organization. It is one of those deceptively simple questions that can be very difficult to answer, and often, in my experience as an agile Leadership consultant, an organization doesn’t have any clear answer when asked why Scrum or Scaled Agile has been introduced.
It might have been a decision made by an earlier manager, evolved by or introduced by the team as a survival technique during times of high management pressure, assumed to be the “best” way to build digital products or even introduced to improve employer branding and attract more talent to apply for positions.
It also takes a very short time for something to become “the way we do things around here,” essentially institutionalizing habits into a culture that can be difficult to challenge. But an essential Agile principle is a continuous reflection on and improvement of our ways of working. Nothing is set in stone, but even so, this also happens to Scrum.
Taking a long, hard look at this question also allows you to adjust – or maybe even completely renew – the implicit pact that has been agreed upon.
Making it public
While some organizations use the introduction of Agile or Scrum as an opportunity to show renewal and vitality but sometimes do not implement it, others try to move under the radar to avoid startling other departments or higher organizational echelons with language and concepts that could be seen as controversial or even revolutionary.
Implementing Scrum without management commitment is one of the most basic mistakes in Agile transformations. If you estimate that the organization will not be able to handle the change, you are either initiating a mistake or not doing your homework.
There will always be detractors and organizational impediments during significant changes, but forcing Agile onto an organization or “sneaking” it in is counterproductive and quite plainly against the Agile mindset. Agile values require leaders to create conditions that enable empowered, self-managing teams and to let go of older, hierarchical ways of working. This demands openness to change, agreement across all levels, and public management support for the initiative. The Pact must be explicit; it should not be toned down to avoid resistance.
What does the New Pact imply?
A new pact between management and employees means that accountability and power are shifted. Agile has different values, ways of working, work identities and organizational cultures than what you might be used to; finding common ground is the trickiest part of Agile transformations, in my experience.
Scrum, the most prevalent Agile practice, has few but clearly defined rules and roles—which also apply to management and other stakeholders. Self-managing teams follow clear business-driven priorities (but they internally decide who does what, when, and how during the Sprint). And they need help learning self-leadership skills. We limit the amount of work in progress and reduce multitasking.
The focus is on Short-term, continuous, iterative, incremental product planning and development. We release and test early and often. You need to find out if this is a suitable way for your organizational context.
Agile requires cross-company engagement, trust and fair play. Extensive and structured stakeholder involvement to reduce risk, noise and waste is critical to Scrum success. This means you!
So, what can be done?
There are some simple principles that you as a manager, stakeholder or team member in a Scrum setting can follow that, even if they sound banal or very simple, can significantly increase the chance of a successful Scrum implementation – for the benefit of all:
Say what you do and do what you say
Show professional integrity
Always assume good intentions and competence
Don’t shy away from clarity, even when it can be painful
Accept that perfection is out of reach, but improvement is always possible
Commit to making informed choices
Understand the essentials of Agile and Scrum – it’s easy to learn
Something that is seldom done is to include stakeholders in Team Working Agreements. Why this is so can only be speculation. Still, I suspect that many managers fail to understand that they, by being direct stakeholders and decision-makers, are also a part of the delivery organization, even if they are not working in a Scrum Team.
One helpful example of doing this is often seen in scaled Scrum settings, where longer-term plans are made:
The team agrees to do everything in their power to meet the agreed objectives.
The Management agrees to do everything in its power to minimize outside disturbances.
If the plan becomes unfeasible, the team agrees to escalate immediately so that corrective action can be taken.
By confirming a simple pledge like this every time the Scrum Team and its stakeholders review a plan, we are reminded of the mutual dependency essential to Agile success. And while these may only be words, they matter.
You’ll learn to engage with Scrum teams, improve collaboration, and build agility in your organization. The course covers Scrum fundamentals from a leadership perspective, focusing on your role in supporting product development, managing expectations, and aligning business goals with team outcomes.
Get ready to transform how you lead and collaborate. Scrum for Managers and Stakeholders is your tool to succeed in the fast-paced Agile world!
Christian is an Agile practitioner, seasoned project manager, accredited Scrum & DevOps trainer and leadership consultant. He is now bringing his expertise and unique view of Agile, modern leadership and related disciplines such as Scrum and DevOps to the students at the Corporate Revolutionary Academy, which he has co-founded.
