The scrum master is putting pressure on me to prepare specific weekly tickets, which seems more like a pace-driven need than a value-based one. I need time to compile requirements and align with the roadmap and strategy, while the scrum master focuses on ensuring every developer remains occupied. To find a balance, I believe in stepping back and putting value first. I’m unable to plan ahead or manage their products due to my busy routine trying to satisfy her requests. The scrum master is pressurizing me to expedite tickets, leaving little time for alignment.
So, how would you respond to the scrum master’s demands to keep moving quickly?
It’s acceptable to take your time if you are having trouble putting together well-thought-out stories that offer the appropriate value.
Make use of the additional ability to fix bugs, technical debt, and other things that won’t take as much of your time to build.
As the product, you decide what needs to be worked on. Unlike your SM. That you. They are there to conduct ceremonies, remove obstacles, and provide reports.
Thanks for your input @NaomiNwosu. This seems very reasonable. I appreciate your perspective on this matter. It’s always helpful to have different viewpoints to consider.
Indeed. I totally agree with you @MartyRoss. In order to provide greater value over the long run, you should feel comfortable slowing down in the short term. Instead of taking offense at this, SMs and EMs ought to be supportive of it.
I’ve had an SM that was very demanding and combative, just like you, OP. I tried to comply with their requests, as I felt under pressure. I wouldn’t try so hard to satisfy someone who is unreasonable in their demands if I could go back in time and talk to the less experienced version of myself. Tell them your goal: to take your time building up a value-based backlog with calm assurance. Provide options for the team to write and pick up tech debt or bug reports, evaluate your current design and discovery work and find methods to contribute to backlog building, take some self-guided learning time, etc., if they are still hankering after more busywork.
Setting and maintaining boundaries (I won’t engage in pointless busywork to ease the SM’s needless concern) is important. It is her responsibility, not yours, to calm down if she panics. To minimize the harm, spend some time educating your manager, EM, and dependable PM colleagues about the circumstances. This will help you assemble a defense team in case she persists in her efforts.
Could you please explain the issue to her? So that you are not the only source of work, does the engineering team not have any tech debt or improvement suggestions of their own that they can ticket and work on? This way, the responsibility of addressing all the issues won’t solely fall on you. Additionally, involving the engineering team in identifying and resolving tech debt or suggesting improvements can promote a collaborative and efficient work environment.
We occasionally struggle with this issue: we need to feed the beast, but we also need time for planning and reflection. In a similar vein, we have encouraged the developers to submit tickets and locate some independent work—tech debt-type stuff. By allocating time for planning and reflection, we can ensure a more strategic approach to feeding the beast. Additionally, encouraging developers to submit tickets and work on independent tasks helps address any lingering technical debt, allowing for smoother progress in the long run.
We’re still a long way from there, but I believe it’s great that your SM is striving to maintain momentum. Maintaining momentum is crucial for any team’s success. It shows dedication and a drive to continuously improve. However, it’s important to find a balance between keeping up with the demands of the work and allowing time for strategic thinking and long-term planning. This will ensure that the team not only meets immediate goals but also sets a strong foundation for future growth and success.
@HannahBorges, without a doubt, I will bring this up soon. She will threaten to take my time if the development team doesn’t stay busy because they are a shared resource.
The issue is that I have to assign work to several developers who focus on different aspects of the product, and I am unable to guarantee each of them recurrent volume for each sprint.
Try to concentrate more on the issue than the remedy in your tickets. Utilize the engineering team to work together to find a solution. You can stay focused and keep the crew occupied by doing this. By emphasizing the issue rather than the remedy in your tickets, you enable the engineering team to fully understand and analyze the problem at hand. This collaborative approach allows them to leverage their expertise and brainstorm innovative solutions collectively. As a result, not only will this keep the crew engaged and motivated, but it will also foster a sense of teamwork and ownership in finding the most effective solution.
Sadly, the way things are structured at work prevents the development and design teams from working together to find a solution. It has a lot of design, and the developer executes. They don’t have the time or resources to be as organized and cooperative as I would like because they are all shared resources.
We are currently trying to resolve this. One potential solution we are exploring is implementing a project management tool that can streamline communication and collaboration between the development and design teams. Additionally, we are considering allocating dedicated resources specifically for these teams to ensure they have the necessary time and support to work together effectively.
@MartyRoss, Consider introducing spike tickets gradually. in order for you to gradually alter it. This approach will help ensure a smooth transition and minimize any potential disruptions. By gradually introducing spike tickets, you can assess their impact on the team’s workflow and make any necessary adjustments along the way. This incremental implementation will allow everyone to adapt to the changes more effectively and maintain productivity levels.
We have a bit of that happening @AnthonySmith. It does help but also often bumps tickets substantially because of priorities shifting. I’d love to find better direct collaboration between dev and design. One possible solution could be implementing a streamlined communication channel specifically for developers and designers to collaborate effectively. This would not only enhance the efficiency of the development process but also ensure that priorities are aligned from the beginning, minimizing any potential disruptions or delays in ticket handling. Additionally, establishing regular meetings or brainstorming sessions where both teams can openly discuss and share ideas could further foster direct collaboration and improve overall project outcomes.
Does this person know what you sell and does he/she attend your ceremonies? Based on my observations, SM/AC just visit your team and explain the theoretical concepts that can be challenging to implement in real-world scenarios. Yes, it would be great to implement those in a perfect world, but it is not the reality we live in. Delivery delays can be caused by a variety of factors, including pipeline problems, illness, and bug production.
However, if you believe it occurs frequently, you might test a lower capacity in the upcoming sprint planning, acting as a “buffer”. And find out where that space is. By doing so, you can identify any bottlenecks or inefficiencies in your current workflow and make necessary adjustments to improve overall delivery time. Additionally, regularly monitoring and analyzing data related to delivery delays can help you pinpoint specific areas that require attention and optimization, allowing for a more streamlined and efficient process in the long run.
Agree with @DanCoelho. In addition, if you use Jira at work, you may monitor sprint burndown to become more evidence-based. Checking which tickets need more time to work on, test, or review is possible. The ticket estimate might have been off as well. By keeping an eye on the sprint burndown, you can identify any potential bottlenecks or issues that may arise during the sprint. This allows you to make necessary adjustments and allocate resources accordingly, ensuring a smoother and more efficient workflow. Additionally, monitoring the sprint burndown can help in improving future estimations and enhancing overall project planning and delivery.
Excellent stuff. To see how that happens, I’d like to temporarily turn down the volume. By lowering the volume, I can better observe the intricate details of the material. This will allow me to fully appreciate and understand how it is being presented.
I would try to determine the source of the actual pressure. Her manager probably wants to maintain the velocity at a specific pace or a nice-looking burndown chart. Have a “come to Jesus” moment with her and explain to her why she needs to understand your position, just as you so beautifully articulated to us. You don’t create tickets. It takes a lot of talking, thinking, and comprehending to do your work. Life will be alright if they take care of the tech debt and enhance its functioning as it stands. It is important to emphasize to her that creating tickets is not the sole measure of productivity. By explaining the intricacies of your work and the value it brings, she will hopefully gain a better understanding of the importance of addressing tech debt and improving functionality. Additionally, highlighting the potential long-term benefits of these actions can help alleviate any concerns about prioritizing them over immediate ticket creation.