I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
So, did you use Scrum before when you were driving the projects? Or is Scrum something that was introduced recently?
I like to have 3 persons. A Scrum Master, a Product Owner, and a Project Lead.
The Scrum Master deals with the process. They schedule meetings, keep the teams on track during the meetings, remove impediments, drive plannings, demos, retrospectives, etc.
The Product Owner is the business owner of the project. They are able to answer questions or go find answers to the questions.
The Project Lead is a technical leader, who understands the details of the project.
I wrote some notes on this model in an article on my company's tech blog. You can find it here ; take a look, and let me know what you think and/or if I can clarify it. I wrote this a long while ago, but I think it is still valid and I have had very good luck with it.
In general, I recommend bringing problems related to the process at the retrospective, and not hold any punches. That is what retrospectives are for. Scrum is very flexible, and if the people involved understand it, you can change it to satisfy your team's needs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So, did you use Scrum before when you were driving the projects? Or is Scrum something that was introduced recently?
I like to have 3 persons. A Scrum Master, a Product Owner, and a Project Lead.
The Scrum Master deals with the process. They schedule meetings, keep the teams on track during the meetings, remove impediments, drive plannings, demos, retrospectives, etc.
The Product Owner is the business owner of the project. They are able to answer questions or go find answers to the questions.
The Project Lead is a technical leader, who understands the details of the project.
I wrote some notes on this model in an article on my company's tech blog. You can find it here ; take a look, and let me know what you think and/or if I can clarify it. I wrote this a long while ago, but I think it is still valid and I have had very good luck with it.
In general, I recommend bringing problems related to the process at the retrospective, and not hold any punches. That is what retrospectives are for. Scrum is very flexible, and if the people involved understand it, you can change it to satisfy your team's needs.