Scrum & Agile process comment based on job descriptions

Hello All,
This post has no question but I just wanted to share what I read.
Here you are:

Some software companies are looking for employees experienced in "scrum" and "agile process" terms.

• Knowledge and experience in Scrum, Agile processes is a plus

So I started searching for them even though I have no relation with software field.

Scrum sounds like a project management tool. A way of problem solving/product development methodology..
I'd like to summarize what I understood from the websites I surfed regarding the term "scrum".
I am familiar with TPM. Scrum sounds pretty similar to TPM used in industry (automotive/white house appliance fields). (Early equipment, early product etc)

From below, you might find it much boring. I am sorry for the long story.
Short summary of "scrum" with my words (Not sure if I get it correctly):
Scrum is a subprocess of agile processing which provides flexibility and fast coding
in software/development projects..
Scrum consists of "product backlog" and "sprint backlog" subprocesses.
(Maybe there are more process but what I read was saying like that)
I hereby pronounce "sprint backlog" as sprint. Sprint is subprocess/subtask of scrum.
At the beginning of the project a meeting is held with the participation of the project sponsor.
and the outline (the purpose of the project) is defined in that meeting. The outline is called "product backlog".
We may think of it as a project book. (Something like a project management book which summarizes the main aim of the project, content, purpose, sources to be supplied, budget, market share, product/service lifetime etc..)
Each requirement/process has a priority number and project should be followed up by given order.
During the project management, the processes are kept up to date by project sponsor. New functions could be added into the list or the order of the processes could be changed.

Scrum is divided into subprocesses which we call “sprint”. Each sprint can not take more than 30days. Project team is called "scrum team". Project manager is pronounced as "scrum master".At the beginning of each sprint, a new meeting is held. In that meeting scrum team and scrum master overviews specifications to be fulfilled for the related sprint's subprocesses. All this subprocesses should be in comply with the order given in product backlog list. They do not work on a low priority process before a process which has higher priority.

Project team may deploy 4 up to 25 persons taken from product backlog. Chosen specifications and functions are transferred into a list which called "sprint backlog". Project team does not evaluate the status of product backlog until the new sprint backlog meeting but they focus only on related sprint backlog list under that sprint.

A sprint backlog task should be completed within max 3 days of development.
Scrum team should set meetings on a daily basis. This meeting is called Scrum. Scrum master attends to these meetings. Each team members must attend to scrum meetings. Stakeholders could also join scrum meetings as audience. They do not have the right to have a talk in meetings. Scrum meeting is held standing and takes max 15minutes.

Does given above explanation make real what matters for you? For me , no.

Kind regards
Boris

The main purpose of any framework or methodology as you describe is to provide people a common vocabulary to use with working together, and some guidelines on how this vocabulary is used.

Generally speaking, the larger the size of any software development team, the less efficient it becomes.

If an organization is working on a software development project which is very large and required a lot of interaction, it is useful to have a common vocabulary and some workflow using that vocabulary so each person is singing from the same sheet of music.

It is not important if we call that framework "Agile Development" or "Scrum" or "Fast and Furious". The name and the details are less important than the fact people have a common vocabulary and workflow.

This is why most developers these days use git integrated into their desktop development environment, like Visual Studio Code (VSC) to develop software. Git also provides a common vocabulary and a workflow framework; but in a different way than a formalized process like scrum.

Everyone has a choice in life and controls their own destiny. If you want to work in such an environment as Scrum, then that's your choice, right?

If you are working for an organization who wants you to work in a Scrum framework and it does not make sense to you", then go to work elsewhere, right?

Life is too short to worry about such nonsense, in my opinion.

That's probably a part of the issue. Developing software requires a lot of experience and for those who do not develop software, it can be very strange to understand all the dynamics involved.

As I mentioned, the more people involved, the more complex and less efficient software development becomes. Better to work independently or in a very small team when developing software, if you want to be happy have less stress, and in turn be more healthy.

Everyone has a choice. The tough part is often making the right choice for each individual.

Actually, @baris35, I read your post twice and did not understand what you are trying to say in your post, especially since you are not "in the software field" as you mentioned.

Thank you Neo,
I really appreciate your long answer. Thank you for the time you dedicated for my question.
I had no education on software engineering for that reason I always feel the lack of experience in this field.

Interestingly, the definition of scrum on scrum.org describes it

as a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems

Which means, technically, you can apply it to any product development process, not just software development.

In my little experience in the software industry, I've observed that organisations that claim to follow scrum, don't follow it exactly by the book. It's difficult, or more rightly, the organisations tailor the process to suit their needs.

Does given above explanation make real what matters for you? For me , no.

IMHO, rather than shunning the entire idea, it can be beneficial to take parts of it that actually works for you (your team) and custom fit to suit the teams' needs.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.