Individuals over Interactions over Processes over Tools
Being Scrum Master sometimes gets you dragged into discussions about the Agile Manifesto and Scrum.
A colleague in or outside the Scrum Team might say: “Hey Scrum Master when it’s all about Individuals and Interactions over Processes and Tools, where does Scrum — being a process (sic) — fit into this?”. The colleague might also say “Hey Scrum Master, you are our Jira administrator — right? Isn’t that a tool?”
I’d recommend for the Scrum Master to think about what the colleague could want when asking those questions. Some examples:
- They want to rant about something (Scrum or not). The Scrum Master made themselves available for this.
- They want to learn about Scrum and/or the Agile Manifesto.
- They want to do something different, as what the Scrum Master said, or the Scrum Framework advised. They prepare this, by showing that Scrum is not perfect.
All should be ok for now, and a Scrum Master could give different answers based on their experiences with the colleague.
Shouldn’t you have any of those answers present, I recommend going for: “That is a rather interesting observation — thank you for this. Let me reflect and get back to you.” But first here are two textbook answers:
- Specify, that Scrum is a lightweight framework (that helps people, teams, and organizations generate value through adaptive solutions for complex problems) and not a process. Point them to the Scrum Guide. This approach will help those, who wanted to learn about Scrum.
- Clarify, that you are only administering Jira, to help the team. Point out that “administering Jira” certainly would not be a Scrum Masters task — but you do this gladly. This approach will show the colleague, that they are free to propose Jira improvements or even take over the administration.
You could also explain the first sentence of the Agile Manifesto:
All four items are relevant. Otherwise, they wouldn’t be included. It’s also stated below, that, while the authors determine the items on the right to be valuable, they value the items on the left more.
You wouldn’t say “Individuals and Interactions over Cannibalism and Warfare” — this would be a waste of space. I guess including two more “over” makes it easier to understand, and we go right to left.
Tools are relevant for our daily work. They allow us to do many things faster, more secure, or more transparent. Examples could be Development Life Cycle Tools like Jira, TFS, Rally, or even hardware tools like laptops or post-its. Tools always have an inherent restriction — they can’t be easily changed. The higher the customizability, the more complicated the process of change.
Tools sometimes define parts of processes (like ERP, CRM,…). The limit of tools as stated in the manifesto is, that they should be less relevant than good, up-to-date processes. A Scrum Master promotes tools, which don’t restrict the change of processes for the better. Sometimes a Scrum Master helps a team with some tools for a limited amount of time.
Processes describe workflow steps, give a reason for them, and what the result should be like to provide value for the company. Sometimes they also include who should do this step — department, role, or name. Processes are — or should be — more adaptable than tools. Try changing SAP in comparison to adding a step to your billing process. Processes are either written down or communicated orally.
Processes are also describing a few interactions. Processes can be changed more easily than tools, but less easily than a spontaneous interaction like a coffee break talk. A Scrum Master promotes processes, which are transparent, lean, lightweight, provide value, support collaboration, and are agreed upon in teams.
A Scrum Master also promotes changing processes when new learnings emerge, or when they limit valuable interactions.
Interactions sometimes are prescribed or limited by processes (which sometimes are limited by tools). Processes can never describe all interactions between individuals (no one would have the time to read or write this). Interactions between tools aren’t what the authors aim at — it’s about human interactions only. The limit of interactions would be, where they don’t provide value to individuals.
A Scrum Master promotes fruitful interactions of the Scrum Team by helping, coaching, teaching, and causing the removal of impediments. Examples for impediments aren’t provided in the Scrum Guide. My guess is, that rigid tools or processes hindering a Scrum Team in generating business value, could be regarded as such.
A Scrum Master helps the Product Owner, leads and trains the organization, and removes barriers between stakeholders and Scrum Teams. How this is done, can’t be completely described in processes, nor programmed in tools. Interactions, which have proven to be harmful to individuals, shouldn’t be repeated, since individuals can leave cooperations, and when they do, there are no more interactions, no one to do process steps or to work with tools.
Individuals are more flexible and adaptable than tools, processes and learned to interact with other individuals for a long time. Individuals not respecting the tools, processes, and interactions in a company at all, might not like to work there. Individuals not being able or willing to change tools, processes, and interact within a company for the better might also like to find more satisfying employment opportunities.
Individuals can change themselves, but changing other individuals is harder than changing tools, processes, and interactions. Expect not even being able fully to describe what a change the colleague should carry out. Individuals are more complex than tools, processes, or interactions. Companies expecting individuals to change after hiring them would fare better by having a second look at their interactions, processes, and tools.
A Scrum Master builds on individuals by:
* promoting a team-first culture,
* making learning opportunities visible,
* showing a broad selection of tools for people to choose from,
* handing people all data they need for them to choose from,
* keeping processes lightweight so individuals can change them,
* and showing the results of interactions so individuals can determine by themself, whether those should be repeated.
By answering the colleague like this, they learned about Scrum, about the Agile Manifesto, know their scope and accountability for doing something different, and maybe they also got to vent a little bit.
