The project manager is one of the most popular and desired professions today. In the…
Scrum is one of the most popular methodologies in software product development. This framework is often considered a project management methodology. However, this is a mistake because Scrum does not manage the project, but the way the teams work.
One of the main reasons for an organization to include Scrum in its production processes is precisely the ambiguity in the processes or even the lack of a specific process. Scrum provides transparency and adaptation. Transparency is needed so that participants in the process can understand each other, contribute to each other to achieve a better product, as well as monitor the effectiveness of what they do and add value to the product. Following the development and effectiveness, many unclear or even bad practices can be found – Scrum provides an opportunity to discuss the problems that have arisen and possibly take measures to avoid these practices. The lack of openness, clear discussion of obstacles and problems, and the search for optimization methods, even delving into unnecessary tasks, may suggest that the Scrum framework may be better.
Scrum offers adaptation
Scrum allows participants to adapt. This is important in situations where the product is constantly changing. This is important to facilitate day-to-day work processes that simply help solve tasks and lead to ‘volume of completed tasks’. They also help to solve common tasks of the same type faster. To develop the processes and increase the business value of the product, it is important to go back and try to make things easier and faster in the next sprint. The ability to adapt and the awareness that you will be given the opportunity and time to adapt also helps the purely mental state of the participants, smooth communication, and reducing stress in the workplace.
Scrum requires regular inspection
Scrum allows frequent and timely inspection of tasks and progress. Through tools such as backlog board and product division into specific tasks – described in detail and objectively, as well as by engaging project participants and delegating specific tasks to them, you can get a clear idea of where (and even with whom) ) things work or don’t work. It is important to clarify that the inspection is not for ‘holding someone accountable’ or ‘throwing blame’ on someone but as a means of detecting pitfalls. This is something that helps the whole team achieve its goal. What matters here is the ability of the Scrum Master and possibly product owners to communicate clearly, to understand, with empathy (as far as possible) – to understand that they are in a position of dependence on what their team will achieve. Reference: What is it like to be a Scrum Master?, https://projectmanagers.edublogs.org/2020/09/14/what-is-it-like-to-be-a-scrum-master/
Scrum requires transparency
Scrum requires transparency. In my opinion, from my personal professional experience, this is one of the main reasons why Scrum is not chosen as a way of working. Here, of course, I am referring to organizations that prefer to follow cumbersome and often vague and extremely inflexible processes. Organizations in which for one reason or another some (legislative) rules or other management practices have to be followed (ITIL management comes to mind, where things have to happen in a certain way and certain artifacts have to be created before all the work it can start and end, all of which are naturally complemented by roles – specific people who have to do something specific in the specific situation, and in time). Or, for example, Waterfall – where you can’t adapt your product if in the middle of the process you realize that something has changed and your work no longer contributes to the product. You can only do it after the end of the project, which is maybe only after … years?
Let’s go back to transparency. If the organization knows in advance that it is extremely committed to following certain processes, or if it has an extremely strict management structure, it would be atypical for it to choose Scrum. If the team and the work take place in a Scrum environment, this will mean that senior management cannot interfere in the work of the team. Of course, this is not to say that senior management is completely unnecessary, it is no coincidence that it exists. I mean, if the work had to be organized according to Scrum, it would take away some of their ‘jurisdiction’ and direct interference in the work of their subordinates.
When organizations do not use Scrum
Why wouldn’t an organization introduce Scrum? Because often these same organizations are certified and are aware that they work with a lot of other principles, which are often completely contradictory. In short, will the organization prefer to throw away its ISO certification or introduce Scrum, although in specific situations the ISO procedure will not be completely Agile so that the organization can use Scrum tools in parallel?
They would not accept Scrum if they purposefully cover problems with communication, the imposition of ideas/power, the lack of time to adapt and discuss lessons learned (retrospection). Unclear tasks and unclear distribution of roles. Lack of empirical data used to assess success. Lack of information, feedback from the team about coping with the tasks, or purposeful ignoring or lack of interest in it. Too many participants in the process – as you mentioned 9 people is the maximum and this is consistent with a lot of things that Scrum suggests. Everything about communication, discussions, roles, so that everyone in the team knows where we are and where we need to go.
The diversity of the participants’ background/qualifications is what they know, not because they cannot get involved in the work, but because other team members are often required to help them with this, to train them, to explain to them, and so on. There is often no time for that.
The difficulties of organizations
Often, senior management is far from the problems of the small Scrum team. They take care of the vision of the organization, budget, strategic planning, etc. Senior management is responsible for big goals, and often big goals depend on achieving small tasks in the various smaller teams.
This is where the important role of the Product Owner and RTE in larger organizations comes from. Reference: What makes a good Product Owner and what do they do?, scrumtime.org, scrumtime.org/what-makes-a-good-product-owner-and-what-do-they-do/
They are the intermediate level, the medium between the high-level problems (the strategic goal of the top management), and the individual small teams.
As a difficulty here, I appreciate the lack of time for senior management to get acquainted with the problems of small teams. Reference: Scrum problems, causes of failure and mistakes, phron.org, https://phron.org/scrum-problems/
Also, senior management’s understanding of agile and scrum procedures often differs from what it means (and what it doesn’t). For example, I often hear questions like Why is this so? Can’t we change it, shouldn’t we be Agile? Yes, we have to be flexible, but even in Scrum, there are rules. If there are no rules, there will be chaos. It takes time for things to become flexible, but it also requires experience and understanding from senior management. A change in the culture of the organization and the way of working is required. In the organization I work for, we hired consultants to come and teach us how to be agile and what scrum is. The training was 1 day (you can imagine what we learned).
In my opinion, all this is related to the lack of time, and why not the lack of finances to hire consultants. Usually, the work is so much that the teams do not have time to reorganize and start using a new way of working. They don’t have time to learn something new yet. They have no faith that this might help them. Results are wanted at the moment.
In my opinion, it is also difficult to find the right people for the right positions (roles). Scrum requires a change of mindset. Often, a person who has been a team leader (a person who takes care of team building and pure staff management, but is also responsible for what work he does) cannot easily become either a Scrum Master or Product Owner. References: Scrum Sprint Review meeting Questions and Answers, policymatters.net, https://www.policymatters.net/scrum-sprint-review-meeting-questions-and-answers/ and Problems of the Scrum Master role with the Sprint Review and Scrum Sprint Retrospective meetings, nebraskasocialstudies.org, https://www.nebraskasocialstudies.org/problems-of-the-scrum-master-role-with-the-sprint-review-and-scrum-sprint-retrospective-meetings/ Both positions require qualities and methods that he has never used before or will feel insecure or even downplay. Senior management here is in a dilemma whether to put these specific people in these positions directly and leave them to learn on their own, whether to invest in them and send them on a course or just find people from outside – to hire already certified people with experience. Reference: Professional Scrum Master vs Professional Scrum Developer, stc-montreal.org, https://stc-montreal.org/professional-scrum-master-vs-professional-scrum-developer/
Even the latter does not guarantee success, as organizations, work, people, and attitudes are often extremely different and even incomparable.
- Using the Scrum framework as a project management process for product development, https://newia.info/using-the-scrum-framework-as-a-project-management-process-for-product-development/
- Real Scrum problems of the Scrum Master role during the Daily Scrum meeting, https://mpmu.org/scrum-problems-scrum-master-daily-scrum-meeting/
- Comparison between Scrum and Kanban methodologies, https://www.kosovatimes.net/comparison-between-scrum-and-kanban-methodologies/
- The Scrum Master role in real project teams, https://bpedia.org/the-scrum-master-role-in-real-project-teams/