Our Scrum Master Amanda Jefferson answers questions about the Development Team responsibilities, work, and processes in terms of the Scrum Master role.

The Director is of the opinion that the lower priority products do not need to have a Product Owner role.

In my opinion, it would be good to have a Product Owner in smaller projects as well. This will help the Scrum Development team. It can prioritize the tasks for the development team in the best way possible according to customer expectations, the business value of the tasks, etc. In my opinion, this is very important regardless of the volume of the product.

The director insists that, as he has many years of experience in managing people, he wants to be the CEO of the largest team, to set tasks on a daily basis, and to request reports from every member of the team.

In my opinion, this will not affect the team well. In order for the modest to work successfully, internal self-responsibility for the distribution and execution of tasks on time is very important. The whole team should work together and be focused on the end goal. The main factor is to help each other, not someone to tell them exactly what to do and ask them to report on each activity. A good development team alone can inspect product progress and take action to improve on their own if they need it. It is the task of the Scrum Master role to positively influence people's self-organization.

The director tells you that a project manager has been appointed for each product by the client, who, in case of urgent requests, will assign each team member a priority for the day.

Generally, a Product Owner of a team can take a position on the priority of tasks - who to leave in the background, if the team lacks capacity, which to shift in order, etc. And Scrum Master determines with the team whether they have the opportunity for additional tasks without jeopardizing what has already been planned or whether the Product Owner will need to prioritize them. I would turn to him so that this can be discussed adequately and that the best decision for the team can be made. It is very important not to overload in many additional tasks. In principle, the team itself should be able to judge which member of the team, what task to take, not someone to tell them that.

One of the senior programmers of the teams tells everyone that since the team is big and he has a lot of experience, he will officially accept the role of Team Lead. She adds that she will choose technology, offer a way of working for each member of the team, and monitor the progress of tasks.

In my opinion, sharing experiences is never wrong, unless it is intrusive. However, each team member has an individual approach to work. In my opinion, it would be a good idea to discuss this with the team and the Product Owner before being appointed to such a position. Experience should not be the only factor in promotion.

A newly recruited employee from your organization tells you that since he is a beginner and still in trial, he prefers not to interfere in team decisions and does not want to take responsibility for product work.

It is understandable because the employee does not have enough experience. But in my opinion, the opposite should be done, and we should try to implement the new team member as much as possible in discussions between the team members. This will allow him to gain experience and confidence for the future. We must encourage him to take responsibility for his actions and the product.

You understand that most of your team members have already spoken with your HR manager and have been granted permission to work outside the office.

This is not a bad idea and can facilitate the workflow at times. But I do not find it good that this has not been discussed with the team leaders. If something like this is implemented in a team, it would be well worth discussing with everyone. And also test with one or 2 members of the team for a period of time to see if this way of work would adversely affect workflow and communication.

A member of the Development Team is pleased to announce that, outside of office hours, he has written a large collection of code that he can easily add to the product, and through it can speed up much of his tasks and some of those of the rest of the team.

It is not bad that every member of the team has the right to contribute ideas that would improve and facilitate ongoing work processes. I would like to test its code to see how this would affect the overall workflow. I may want to try it out as a pilot project with one or two team members.

The development team offers you the idea that you set an estimated time for task completion, and that they focus on their work and spend their time on tasks. They shared this with the Product Owner role, and he was quite pleased.

That would not be a particularly good idea. The development team is the developers themselves, that is, they know best what their time is and what they need. In my opinion, it will not be very productive for me to set deadlines because there can always be changes and some difficulties at work. And that would additionally lead to unnecessary tension between the team if the deadline I set was too short for the product.

The teams of the three parallel products being developed by your organization have decided to reorganize. Their desire is to be divided into teams according to their profession and qualification. One team will be programmers, the second will be designers, and the third will be quality control. They have suggested you as an activity coordinator.

In my opinion, this is not a good idea. The thing is, people, come from different products. Each product has a different code that they are already used to working with. If people are grouped according to their qualifications, this will lead to great confusion and confusion of different information.

The development team shares the opinion that User Story contains too little information and wants more details.

This is very good feedback. The tasks submitted to the development team must be accurate and clear, but they must also contain all the information they need to get started. I would contact the product of the aberrant so that this user story could be redone.

The Product Owner has asked one of the team members not to temporarily report problems and defects on the product publicly in your defect recording system, but to correct them themselves.

This is the wrong approach. In my opinion, the best thing to do in this situation is to discuss the defects with the other team members. This will allow you to come up with the fastest, most appropriate solution to remedy the problem and then resolve it. If a person writes the code and tests it himself, then the quality cannot be guaranteed.

Read more Scrum Team questions and answers (FAQ) related to the Scrum teamwork processes and interaction.