Ken Schwaber & Jeff Sutherland, the authors of the “Agile Scrum Guide” introduce the Agile Scrum methodology as lightweight, easy to understand and… difficult to master. How difficult could it be to master a set of basic principles contained in a few-dozen-page booklet?
The above-mentioned guide describes the roles and responsibilities of a Scrum Team in an easy, straightforward way to be understood by anyone, even if not directly involved in project management. The guide comprises a kind of “service agreement” between the Scrum team members, where everyone realizes their particular roles and duties.
However, aside from the guide, there is one more important document that allows greater freedom of interpretation of Scrum, and which differs significantly from the more rigid and formal “traditional” waterfall methods, that is:
THE AGILE MANIFESTO
It is a set of 4 main principles to follow so that Agile Scrum as a method of running the project can fully spread its wings.
1. Individuals and interactions over processes and tools.
Up to 10 people
10 is the maximum number of members an Agile team should have to be fully productive and to ensure that communication in the team easy, or should we say -“agile”? That’s what the Scrum Guide calls it anyway.
You do not have to look too far in the literature related to team management to find out that 7 is the most common number of people recommended to be working with one manager and that number is considered the “golden middle” when striving to maintain top efficiency when delegating tasks.
“In management circles, it is common knowledge that the ideal number of direct subordinates a manager should have is 7±2 (say it with me now: “seven plus or minus two!”)”
~ source: https://managementforstartups.com/articles/whats-the-ideal-number-of-direct-reports/
However, the real strength here lies not in numbers (of people in the team), but rather in the friendly and mutually helpful relations between people working in a small, non-competing group. Such a group of specialists working in close contact with each other could be compared to a group of friends-enthusiasts involved in creating their own startup. Titles and experience, or barriers in communication, have no place here, while informal discussion about problems and open communication most definitely do. The amount of work to be done by particular people is agreed by self estimating one’s own capacity (over a cup of coffee) rather than by assignments, which gets rid of a lot of pressure associated with “delivering and exceeding KPIs” under threat of escalation.
If we add the Product Owner (usually client appointed) to the mix – a person who can perfectly fit with the Scrum team, identifies with it and becomes its integral member, then the respect for the value of individuals over the tools and processes comes naturally.
2. Working software over comprehensive documentation.
Well-Documented failure – is one of the examples of project management from the Project Manager’s angle. Even if this type of description raises some controversy, I assume that the majority of PMs can – based of course on the experience of their colleagues, not their own … :), recall at least one such project.
The second principle of the Agile Manifesto takes on this issue.
This approach to the matter draws more attention to the Scrum Master’s continuous dialogue with his team asking themselves: What should we do for this to work? Instead of explaining to the client why it doesn’t work.
There is one more element necessary for Scrum communication to work, and it’s “trust” – the word that does not appear often in business. Scrum Master with a technical background that understands the details of the developers’ work and who is able to independently estimate the time for specific tasks, is a walking gold. However, not all companies can afford such comfort. Therefore, the issue of building openness and trust in the team is one of the key drivers in team cooperation and is what actually makes delivering working software possible.
3. Customer collaboration over contract negotiation
Another quite demanding condition to meet. Especially if we talk about budgets and multi-million contracts mulled over by law firms before being signed. Bringing this principle into the Agile yard, where our direct client is usually the Product Owner – an integral part of the team is another element of everyday cooperation.
Should you rather respond positively to the last conversation or stick to the terms of the contract?
In this case, the ability to actively listen to the Scrum Master is valued much higher than the ability to read with understanding.
4. Responding to change over following a plan
From the Agile point of view, the change is not an element that appears in the project and needs to be managed. Change is its integral part. Such an explanation of the process in the team at the very beginning of the project makes it easier to work in its further phases.
In addition, Scrum Master does not manage the change but manages the emotions of his team while the changes take place. The best practitioners of the art of management know how the concerns of their team members turn into the emotions of waiting for something positive that comes along with the change.
The change in Agile Scrum is a sign that our idea is starting to clear and the differences between what the client expects and what has been so far produced are decreasing. We are closer to what the project is all about.
So what is the difficulty in agile management methodologies? Confidence, mutual respect, openness, transparency, right to make mistakes, flexibility and other soft skills. Behaviors that cannot be assimilated over a weekend course or by learning a textbook by heart in a few days, and training of which often takes years.