![]() ![]() Chances are someone will bring it up and you can start asking the team questions to drill down to what you want them to arrive at. If you’re doing regular retros at the end of your sprints, and they’re not bringing it up as a “what went well” and “what didn’t go so well” kinda thing maybe suggest doing something like a Radar discussion and set the spokes up to talk about aspects of how the team works or collaborates, or where they’re seeing problems in delivering working software. *this may be out of your team’s control depending how your company handles this, but coordination is still the team’s responsibility.Īs for how to suss this out and get the team to discuss these things, you can avoid even having to directly bring it up to them or create a potentially awkward environment by just tricking them into talking about it. Some people may worry about it more than others sprint to sprint, but they’re all responsible for it. Quality and deployments* are the team’s responsibility just the same as coding the functionality just the same as architecting solutions. If the team wants to be agile and wants to own their work, they need to understand that they own all of the work. This might be a bit complex and you may have to introduce these concepts lightly depending how your team reacts to things, but the sense I get is this: Hoping they pick up the above topics on their own but could be wishful thinking.Ĭhoose one of the above topics and be blunt that I want to do a retrospective to improve just that process and build action points to achieve an ideal scenario.Īny suggestions would be so much appreciated!!! They need to answer why it needs to improve? What would be the ideal scenario? First steps to achieve it? Each group presents to the team their plan. ![]() Ideas so far: Split them into groups, each group chooses a topic or process they think it could improve. I wanted to design a retrospective to analyze the 2 above topics but not sure how to do it. Devs are stating PO should also serve as a release manager to avoid this kind of situations. Seems devs from different teams don’t communicate with each other. Sometimes 2 teams are releasing at the same time different things. It is also frequent that frontend is waiting for a dependency from backend for a long time and then don’t have time to test. ![]() We have a shared QA with another team that is focused only on regressions and automation testing. I noticed 2 big issues:ĭevs don’t want to do QA work and usually take forever to close their tasks because only testing is missing and “their real job is already done”. I’m a recent scrum master and joined my team around 2 months ago. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |