Mixing
Incorrect scrum meeting format not allowing for enough participation from developers
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I recently starting working on a project team for a company that is transitioning to Agile methodologies, and that means daily scrum meetings. The scrum masters, however, tend to hold their meeting format by going over task names and asking for progress so they can document it themselves. This leads to a lot of lengthy discussions on those tasks during the scrum between management employees sorting out details about that task while the developers sit and listen. These meetings go over the allotted half hour every single time.
To my best knowledge, the scrum meeting is supposed to be a brisk, 15 minute meeting where each developer answers the following questions:
- What did I do yesterday?
- What will I do today?
- Am I experiencing any blockers?
This should set a progress benchmark for and amongst the developers.
However, these meetings seem to be geared toward bookkeeping for management purposes, and do not give adequate room for developers to set benchmarks amongst each other as the scrum meeting format encourages. Instead, the meeting is conducted by the scrum master listing issue numbers for the task names with the following question:
- What's the progress on this?
This is generally followed by a discussion which starts as clarification between the scrum master and developer, then ends up as a discussion between management employees trying to sort out details about the relevant story. Because of this, and the nature of multiple developers being assigned to the same task while only one reports on the progress of the task, not all developers are able to participate in the meeting.
Notes to consider before my question:
- I have experienced this issue on multiple teams within my project.
- None of the tasks that my colleagues or I receive on this project are assigned through the issue docs. They are all sent by email, without a reference to an issue number that the scrum master simply lists off during the meeting.
- I am working as a contractor, so I do not have the same leverage as a full time employee of this company would.
My question is, how/who do I approach raising this issue to the project team?
I do not want the scrum master or anyone in management to feel like I am essentially telling them how to do their job, but I also feel that this change needs to happen, as these meetings are very inefficient and ineffective for the developers and multiple members of the development team have expressed similar concerns.
software-industry meetings scrum agile
asked 28 mins ago
TCFP
1141
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
I recently starting working on a project team for a company that is transitioning to Agile methodologies, and that means daily scrum meetings. The scrum masters, however, tend to hold their meeting format by going over task names and asking for progress so they can document it themselves. This leads to a lot of lengthy discussions on those tasks during the scrum between management employees sorting out details about that task while the developers sit and listen. These meetings go over the allotted half hour every single time.
To my best knowledge, the scrum meeting is supposed to be a brisk, 15 minute meeting where each developer answers the following questions:
- What did I do yesterday?
- What will I do today?
- Am I experiencing any blockers?
This should set a progress benchmark for and amongst the developers.
However, these meetings seem to be geared toward bookkeeping for management purposes, and do not give adequate room for developers to set benchmarks amongst each other as the scrum meeting format encourages. Instead, the meeting is conducted by the scrum master listing issue numbers for the task names with the following question:
- What's the progress on this?
This is generally followed by a discussion which starts as clarification between the scrum master and developer, then ends up as a discussion between management employees trying to sort out details about the relevant story. Because of this, and the nature of multiple developers being assigned to the same task while only one reports on the progress of the task, not all developers are able to participate in the meeting.
Notes to consider before my question:
- I have experienced this issue on multiple teams within my project.
- None of the tasks that my colleagues or I receive on this project are assigned through the issue docs. They are all sent by email, without a reference to an issue number that the scrum master simply lists off during the meeting.
- I am working as a contractor, so I do not have the same leverage as a full time employee of this company would.
My question is, how/who do I approach raising this issue to the project team?
I do not want the scrum master or anyone in management to feel like I am essentially telling them how to do their job, but I also feel that this change needs to happen, as these meetings are very inefficient and ineffective for the developers and multiple members of the development team have expressed similar concerns.
software-industry meetings scrum agile
asked 28 mins ago
TCFP
1141
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Don't have the time for a full answer, so, a comment: Do you do sprint retrospectives? This seems to be the natural place to bring this up, but it would have to be done incrementally.
– rath
22 mins ago
Also, assigning tasks in an ad-hoc manner is a lot worse in my opinion, and transitioning to a ticket mentality would be my priority. Something like if it's not on $task-tracker, it doesn't exist would be nice
– rath
21 mins ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I recently starting working on a project team for a company that is transitioning to Agile methodologies, and that means daily scrum meetings. The scrum masters, however, tend to hold their meeting format by going over task names and asking for progress so they can document it themselves. This leads to a lot of lengthy discussions on those tasks during the scrum between management employees sorting out details about that task while the developers sit and listen. These meetings go over the allotted half hour every single time.
To my best knowledge, the scrum meeting is supposed to be a brisk, 15 minute meeting where each developer answers the following questions:
- What did I do yesterday?
- What will I do today?
- Am I experiencing any blockers?
This should set a progress benchmark for and amongst the developers.
However, these meetings seem to be geared toward bookkeeping for management purposes, and do not give adequate room for developers to set benchmarks amongst each other as the scrum meeting format encourages. Instead, the meeting is conducted by the scrum master listing issue numbers for the task names with the following question:
- What's the progress on this?
This is generally followed by a discussion which starts as clarification between the scrum master and developer, then ends up as a discussion between management employees trying to sort out details about the relevant story. Because of this, and the nature of multiple developers being assigned to the same task while only one reports on the progress of the task, not all developers are able to participate in the meeting.
Notes to consider before my question:
- I have experienced this issue on multiple teams within my project.
- None of the tasks that my colleagues or I receive on this project are assigned through the issue docs. They are all sent by email, without a reference to an issue number that the scrum master simply lists off during the meeting.
- I am working as a contractor, so I do not have the same leverage as a full time employee of this company would.
My question is, how/who do I approach raising this issue to the project team?
I do not want the scrum master or anyone in management to feel like I am essentially telling them how to do their job, but I also feel that this change needs to happen, as these meetings are very inefficient and ineffective for the developers and multiple members of the development team have expressed similar concerns.
software-industry meetings scrum agile
asked 28 mins ago
TCFP
1141
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I recently starting working on a project team for a company that is transitioning to Agile methodologies, and that means daily scrum meetings. The scrum masters, however, tend to hold their meeting format by going over task names and asking for progress so they can document it themselves. This leads to a lot of lengthy discussions on those tasks during the scrum between management employees sorting out details about that task while the developers sit and listen. These meetings go over the allotted half hour every single time.
To my best knowledge, the scrum meeting is supposed to be a brisk, 15 minute meeting where each developer answers the following questions:
- What did I do yesterday?
- What will I do today?
- Am I experiencing any blockers?
This should set a progress benchmark for and amongst the developers.
However, these meetings seem to be geared toward bookkeeping for management purposes, and do not give adequate room for developers to set benchmarks amongst each other as the scrum meeting format encourages. Instead, the meeting is conducted by the scrum master listing issue numbers for the task names with the following question:
- What's the progress on this?
This is generally followed by a discussion which starts as clarification between the scrum master and developer, then ends up as a discussion between management employees trying to sort out details about the relevant story. Because of this, and the nature of multiple developers being assigned to the same task while only one reports on the progress of the task, not all developers are able to participate in the meeting.
Notes to consider before my question:
- I have experienced this issue on multiple teams within my project.
- None of the tasks that my colleagues or I receive on this project are assigned through the issue docs. They are all sent by email, without a reference to an issue number that the scrum master simply lists off during the meeting.
- I am working as a contractor, so I do not have the same leverage as a full time employee of this company would.
My question is, how/who do I approach raising this issue to the project team?
I do not want the scrum master or anyone in management to feel like I am essentially telling them how to do their job, but I also feel that this change needs to happen, as these meetings are very inefficient and ineffective for the developers and multiple members of the development team have expressed similar concerns.
software-industry meetings scrum agile
software-industry meetings scrum agile
asked 28 mins ago
TCFP
1141
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 28 mins ago
TCFP
1141
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 28 mins ago
TCFP
1141
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 28 mins ago
TCFP
1141
asked 28 mins ago
TCFP
1141
1141
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
TCFP is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Don't have the time for a full answer, so, a comment: Do you do sprint retrospectives? This seems to be the natural place to bring this up, but it would have to be done incrementally.
– rath
22 mins ago
Also, assigning tasks in an ad-hoc manner is a lot worse in my opinion, and transitioning to a ticket mentality would be my priority. Something like if it's not on $task-tracker, it doesn't exist would be nice
– rath
21 mins ago
add a comment |Â
1
Don't have the time for a full answer, so, a comment: Do you do sprint retrospectives? This seems to be the natural place to bring this up, but it would have to be done incrementally.
– rath
22 mins ago
Also, assigning tasks in an ad-hoc manner is a lot worse in my opinion, and transitioning to a ticket mentality would be my priority. Something like if it's not on $task-tracker, it doesn't exist would be nice
– rath
21 mins ago
1
1
Don't have the time for a full answer, so, a comment: Do you do sprint retrospectives? This seems to be the natural place to bring this up, but it would have to be done incrementally.
– rath
22 mins ago
Don't have the time for a full answer, so, a comment: Do you do sprint retrospectives? This seems to be the natural place to bring this up, but it would have to be done incrementally.
– rath
22 mins ago
Also, assigning tasks in an ad-hoc manner is a lot worse in my opinion, and transitioning to a ticket mentality would be my priority. Something like if it's not on $task-tracker, it doesn't exist would be nice
– rath
21 mins ago
Also, assigning tasks in an ad-hoc manner is a lot worse in my opinion, and transitioning to a ticket mentality would be my priority. Something like if it's not on $task-tracker, it doesn't exist would be nice
– rath
21 mins ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
You may be in a situation where you just need to have an honest conversation. This can be done tactfully, but it sounds like there are some fundamental parts of Scrum that they do not understand.
No reason to approach it rudely ("You guys suck at this"), but a tactful sharing that there are better ways ("Can I share a way of doing this that I've seen work really well before?") might be the way to go. Sprint Retrospective is an awesome place to bring it up, since that is supposed to focus on improvements to the team working process anyway.
You also mention the problem that Scrum Masters have to report on task progress. This is, of course, problematic. The fact that people come there with needs directly in conflict with the purpose of the meeting creates a structural conflict that has to be resolved in the system (in other words, it isn't a people problem).
Finally, you said that they are in the process of transitioning. There are two things to consider with that fact. First, a lot of transitioning companies actually look for contractors who have experience because it's a way to inject new ideas into the group. You may find them more welcoming of your experience than you expect. Second, they'll be more open to some ideas than others. If you offer a suggestion and they don't take it, hold onto it for later. I can't count the number of teams I've seen fight an idea tooth and nail only to love the same suggestion a few months later.
answered 51 secs ago
Daniel
93126
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You may be in a situation where you just need to have an honest conversation. This can be done tactfully, but it sounds like there are some fundamental parts of Scrum that they do not understand.
No reason to approach it rudely ("You guys suck at this"), but a tactful sharing that there are better ways ("Can I share a way of doing this that I've seen work really well before?") might be the way to go. Sprint Retrospective is an awesome place to bring it up, since that is supposed to focus on improvements to the team working process anyway.
You also mention the problem that Scrum Masters have to report on task progress. This is, of course, problematic. The fact that people come there with needs directly in conflict with the purpose of the meeting creates a structural conflict that has to be resolved in the system (in other words, it isn't a people problem).
Finally, you said that they are in the process of transitioning. There are two things to consider with that fact. First, a lot of transitioning companies actually look for contractors who have experience because it's a way to inject new ideas into the group. You may find them more welcoming of your experience than you expect. Second, they'll be more open to some ideas than others. If you offer a suggestion and they don't take it, hold onto it for later. I can't count the number of teams I've seen fight an idea tooth and nail only to love the same suggestion a few months later.
answered 51 secs ago
Daniel
93126
add a comment |Â
up vote
0
down vote
You may be in a situation where you just need to have an honest conversation. This can be done tactfully, but it sounds like there are some fundamental parts of Scrum that they do not understand.
No reason to approach it rudely ("You guys suck at this"), but a tactful sharing that there are better ways ("Can I share a way of doing this that I've seen work really well before?") might be the way to go. Sprint Retrospective is an awesome place to bring it up, since that is supposed to focus on improvements to the team working process anyway.
You also mention the problem that Scrum Masters have to report on task progress. This is, of course, problematic. The fact that people come there with needs directly in conflict with the purpose of the meeting creates a structural conflict that has to be resolved in the system (in other words, it isn't a people problem).
Finally, you said that they are in the process of transitioning. There are two things to consider with that fact. First, a lot of transitioning companies actually look for contractors who have experience because it's a way to inject new ideas into the group. You may find them more welcoming of your experience than you expect. Second, they'll be more open to some ideas than others. If you offer a suggestion and they don't take it, hold onto it for later. I can't count the number of teams I've seen fight an idea tooth and nail only to love the same suggestion a few months later.
answered 51 secs ago
Daniel
93126
add a comment |Â
up vote
0
down vote
up vote
0
down vote
You may be in a situation where you just need to have an honest conversation. This can be done tactfully, but it sounds like there are some fundamental parts of Scrum that they do not understand.
No reason to approach it rudely ("You guys suck at this"), but a tactful sharing that there are better ways ("Can I share a way of doing this that I've seen work really well before?") might be the way to go. Sprint Retrospective is an awesome place to bring it up, since that is supposed to focus on improvements to the team working process anyway.
You also mention the problem that Scrum Masters have to report on task progress. This is, of course, problematic. The fact that people come there with needs directly in conflict with the purpose of the meeting creates a structural conflict that has to be resolved in the system (in other words, it isn't a people problem).
Finally, you said that they are in the process of transitioning. There are two things to consider with that fact. First, a lot of transitioning companies actually look for contractors who have experience because it's a way to inject new ideas into the group. You may find them more welcoming of your experience than you expect. Second, they'll be more open to some ideas than others. If you offer a suggestion and they don't take it, hold onto it for later. I can't count the number of teams I've seen fight an idea tooth and nail only to love the same suggestion a few months later.
answered 51 secs ago
Daniel
93126
You may be in a situation where you just need to have an honest conversation. This can be done tactfully, but it sounds like there are some fundamental parts of Scrum that they do not understand.
No reason to approach it rudely ("You guys suck at this"), but a tactful sharing that there are better ways ("Can I share a way of doing this that I've seen work really well before?") might be the way to go. Sprint Retrospective is an awesome place to bring it up, since that is supposed to focus on improvements to the team working process anyway.
You also mention the problem that Scrum Masters have to report on task progress. This is, of course, problematic. The fact that people come there with needs directly in conflict with the purpose of the meeting creates a structural conflict that has to be resolved in the system (in other words, it isn't a people problem).
Finally, you said that they are in the process of transitioning. There are two things to consider with that fact. First, a lot of transitioning companies actually look for contractors who have experience because it's a way to inject new ideas into the group. You may find them more welcoming of your experience than you expect. Second, they'll be more open to some ideas than others. If you offer a suggestion and they don't take it, hold onto it for later. I can't count the number of teams I've seen fight an idea tooth and nail only to love the same suggestion a few months later.
answered 51 secs ago
Daniel
93126
answered 51 secs ago
Daniel
93126
answered 51 secs ago
Daniel
93126
answered 51 secs ago
Daniel
93126
93126
add a comment |Â
add a comment |Â
TCFP is a new contributor. Be nice, and check out our Code of Conduct.
TCFP is a new contributor. Be nice, and check out our Code of Conduct.
TCFP is a new contributor. Be nice, and check out our Code of Conduct.
TCFP is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f120332%2fincorrect-scrum-meeting-format-not-allowing-for-enough-participation-from-develo%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Don't have the time for a full answer, so, a comment: Do you do sprint retrospectives? This seems to be the natural place to bring this up, but it would have to be done incrementally.
– rath
22 mins ago
Also, assigning tasks in an ad-hoc manner is a lot worse in my opinion, and transitioning to a ticket mentality would be my priority. Something like if it's not on $task-tracker, it doesn't exist would be nice
– rath
21 mins ago