23
I don't see any problems with raising concerns that you are aware of yet don't directly impact you. There may be ramifications to your relationship with coworkers if they see that as breaking some level of trust with you, but there's nothing from the process side that would prevent someone from raising a concern or issue on behalf of someone else.
The ...
13
Choose your battles carefully
You mention you are new to the team and new to the organization. It will take some time before the team fully trusts you and your judgement. If that has already happened then you have more arguing power to support your point of view. If you are still very new, then have patience and wait a while. It's also very important to ...
11
I agree. These people are asking you – privately – to speak for them anonymously, and you also feel that it is an issue worth raising. Therefore, after carefully considering (perhaps, with them) exactly what is the issue and what might be done about it, I would recommend that you do raise the issue "as though it were yours."
Now, you also have a separate ...
9
I have seen highly effective teams full of junior developers and disastrous teams full of senior developers.
Rather than focusing on seniority and experience, I recommend:
Hiring highly collaborative people
Looking for a good mix of personality types (starters, completer-finishers, etc.)
Hiring people with good leadership skills - willing to step up and ...
8
In my experience a retrospective meeting is a meeting where the team comes together in an informal setting to discuss how the team is working and what changes are needed for the team to improve, this can be on working together or independently.
Examples that happened at the company I work for are: "not having the product owner on the planning meeting ...
6
Stop Abusing Velocity
I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated.
So, you know the company is doing the wrong thing and following an anti-pattern, and yet you're expecting a different outcome. That isn't reasonable....
5
Don't raise it as a problem, instead raise it as a possible improvement.
A lot of the discomfort in retrospectives comes about when there is a focus on identifying issues. This can result in blame or embarrassment for team members. I recommend you carefully shift the focus away from identifying issues and make it more about ways the team can get better. ...
4
This shouldn't be about following the Scrum Guide or doing Scrum, but effective practices. Scrum is a framework that has been demonstrated as useful for a good number of teams and organizations in a variety of contexts. It's not the only way to build and deliver complex products or services.
In this particular case, the problem appears to be that planning ...
3
The fact that the retrospective seemed to take "too long" suggests either that the team found a lot of room for improvement in what they had done or that they didn't make effective use of the time during the retrospective. If it's the former then that seems to be a strong argument to complete the retrospective before planning. Take a look at the outputs of ...
2
Bogdan has answered this well and to expand on one point, I do feel the argument to flip the two meetings should be based on findings from previous retrospectives. Gather feedback from the team beforehand and collate your reviews and lessons learned from the previous sprint release(s). If the complaint is that the meeting runs for 2 hours, do a mini-meeting ...
2
When I first got my CSM, the course instructor specifically said that grooming was being replaced with refinement because of the child exploitation angle. I was indifferent but understood the reason for the change. For the last two years I have been working on application development projects for the Child Welfare department of my state. Grooming is ...
2
the answer is: maybe.
In an old Team, the PO and I had personal problems for months. On a retro day, we clashed again, in a bad way. Cant remember what it was about that day.
The Team thought we should talk about it, but neither the PO nor I where in the mood for talking about it. Being forced to talk about just made it worse. During that retro, the PO said:...
2
The short answer is YES, you should.
The long answer is:
The purpose of the retrospective meeting is to improve the team in any way (processes, communication, etc.)
This is usually done in the following way:
by stating what the team is doing well, so they can continue to do it
by stating what the team is doing wrong, so they can stop doing it
by stating ...
2
Scrum promotes an iterative, incremental, and adaptive approach to releases. In effect, what you are asking is if you are taking this approach and the answer is probably, possibly, and likely not. I'll explain:
Iterative: By working in sprints, you are working in iterations, which allows you to frequently review your progress and adjust plans as required. I ...
1
I think you're overthinking this. Do you want to know what agile is?
Agile is two things. First, the Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value ...
1
Your boss also erred by telling the team that their product was going to be scrapped without apparently giving them the promise that they wouldn't be. Therefore, for what should be perfectly obvious reasons, the developers stopped caring about a product that the company no longer cares about, and put their job searches into high gear. Very soon you won't ...
1
You should definitely be careful. Velocity is a subjective measurement. As teams stabilize, it usually reflects productivity with some degree of accuracy. However, it is not productivity and it can move independently of productivity.
That said, it is possible that the team is right - their estimates are just more accurate now. If that is true, they may ...
1
Let me qualify my answer a little bit with this: I do not know if there are any theoretical constructs with Scrum that dictates team make-up so I am answering in a more general way around teams.
I like a lot the bullets that @Barnaby Golden (+1) provided in his answer; however, they are hard to identify during selection process and those things sort of ...
1
So... here is what I used to teach when I talked about Story Points in my CSM classes (I don’t talk about it in my CSMs anymore, unless under request). An estimate with story points carry a “confidence interval” around it - which means, its level of precision. And that’s THE reason why we use Fibonacci numbers. You see, we can imagine the estimate is ...
Only top voted, non community-wiki answers of a minimum length are eligible
