Ghost in the Agile Machine

How the Invisible roles in Scrum can Make or Break You

Harry S Long
Serious Scrum
4 min readJun 9, 2020

--

There are a few important people in the IT organization that have crucial roles that the Scrum Guide leaves out. These are people with functions that cannot be replaced or undone . In a Scrum implementation they often feel left out. Because of the supporting nature of these of roles, each one can make or break a Scrum implementation. Only by taking to account these essential supporting roles, the team, the project an the organization can achieve a solid transition.

When I first started as a Scrum Master, I was part of a major Enterprise level transition — that failed. It was simply too much to try to change the mindset of an entire company with an over 100-year history! This company had several thousand employees in IT, all with different interests. But I was successful with the small teams I served. We connected at a human level, and lived up to the Scrum Values and the Principles of the Agile Manifesto. Given my experience in such a complicated company set-up, my first shot at leading a transition in a small company surely would go better!

As joined a new, smaller company with a personal success behind me, I joined an awesome small team. The IT department was no more than about 100 people, maybe less. And we did a great job! I was the SM for only one team — the cornerstone team — and we gave it a good go. Of course, it was difficult, but we got our bearings and teamed; we kept moving forward. After about a year of doing Scrum ; other parts of the organization saw our ceremonies. They started asking me about what all these “standups” were about . How could they use these tools to be more effective? It was working! The transition had broken through the IT barrier! And two months later, without fanfare or announcement — it was all canceled.

The change had not happened “fast enough”. The board, running out of patience, demanded a change in direction. This would include a complete retooling of the IT structure. The Scrum implementation that we worked, that was about to cross the line of sustainability and delivery was done. All because a set of strong stakeholders who did not work with us had expectations that were not communicated thought they had a better idea. Again, I was left with personal success — but a failed implementation. Due to a set of people that were outside looking in. People with enough power to shut everything down. People with no interest or vision into what the Agile transition was all about. I discovered that people that do not have roles can really hurt a Scrum Implementation!

From that day on, I kept an eye out for more of the people in IT that could help us maintain the change going until the Scrum implementation was successful. We all know not all roles are included in the Scrum Guide! And we all know that to some degree, this is on purpose. I felt that if we included some of these roles as active participants in the process, we’d have a better chance of moving the change forward. This might avoid a painful stoppage.

The first role, and one that raises the most questions when an organization starts a transition to Agility is the Manager. We all have a dislike to “command and control” thinking that is stifling to projects and success. We train our new clients to change their way of thinking from this to a more open ended and effective way. These words may seem innocuous to some, but to a manager, they could spell some real concern! Add to the complexity that even when the way the IT team works, the way budgeting and HR work generally does not. This can leave a manager in a very anxious and demanding place! Not to mention all the other things that are expected of the managers in most organizations.

Our first installment of the Ghost Roles is the Manager — I hope to show you how an understanding manager can make all the difference for his team. In follow up installments, we will visit people whose roles are critical for success. But people that are left undefined so that we can work together to make this work.

Do you want to write for Serious Scrum or seriously discuss Scrum?

--

--