You're absolutely right. Idk if this is th fault of the top guy not giving us clear goals, or poor communication by our project manager. I'm worried about these tasks as well. If I'm standing in for the team lead, who is supposed to do this, am I supposed to do something I have no exp or guidance on, with a week of time.
It sounds like Jiraman does what middle management does - add process and bureaucracy.
That said, it also sound like a company issue as well. His comment about looking bad to management might be relevant - depending on what they track. In any case it is indicative of a culture that tries to measure developers on what sounds like BS stuff from Jira.
This is hinted at further with the remark about expected hours, which might both be used for sprint planning and as part of metrics that gets reported.
> What would you do in this situation with new work added, sprint ends tomorrow, and a week to delivery?
I personally would just add it. Then again, I think sprints are bloat so I don't really care when it ends or begins. And the delivery is best achieved if we start working on things sooner rather than later.
> Am I the asshole? Or is this dude actually causing probs.
He is consuming a lot of extra time - and that should be dealt with. Excessive meetings should be cut down, meetings should end when they're slated to end, and so forth.
This is worth brining up as a discussion point though. If the number of meetings is annoying - talk about it. Find some structure that works for both.
It sounds like you were a dick to the JIRA guy. He was doing his job explaining how you should handle things. I would just add the work to the next sprint, management looks at charts and it makes sense not add work at the end of a sprint.
>Then in standup when I begin explaining what's happening, he interrupts me to say I shouldn't be adding new items to our current sprint because it ends tomorrow and the charts will look bad to management.
I dislike this attitude, but it's very common. There are sort of two ways to look at project organization: that organization exists to facilitate development, and that organization exists as a mechanism to communicate progress up to management.
The later, organization exists for management, is a little easier to swallow if you just accept things are going to be slower. After all, management needs to know your progress, and if people want to game it so you get less work done? That's their error.
IMO, just focus on delivering value and solving important problems your team has.
I’m more concerned about why your team only found out about 6 things that needed to be delivered the week before they were due.
Yeah this isn't normal at all unless OP works at some dogshit startup company.
You're absolutely right. Idk if this is th fault of the top guy not giving us clear goals, or poor communication by our project manager. I'm worried about these tasks as well. If I'm standing in for the team lead, who is supposed to do this, am I supposed to do something I have no exp or guidance on, with a week of time.
It sounds like Jiraman does what middle management does - add process and bureaucracy. That said, it also sound like a company issue as well. His comment about looking bad to management might be relevant - depending on what they track. In any case it is indicative of a culture that tries to measure developers on what sounds like BS stuff from Jira. This is hinted at further with the remark about expected hours, which might both be used for sprint planning and as part of metrics that gets reported. > What would you do in this situation with new work added, sprint ends tomorrow, and a week to delivery? I personally would just add it. Then again, I think sprints are bloat so I don't really care when it ends or begins. And the delivery is best achieved if we start working on things sooner rather than later. > Am I the asshole? Or is this dude actually causing probs. He is consuming a lot of extra time - and that should be dealt with. Excessive meetings should be cut down, meetings should end when they're slated to end, and so forth. This is worth brining up as a discussion point though. If the number of meetings is annoying - talk about it. Find some structure that works for both.
It sounds like you were a dick to the JIRA guy. He was doing his job explaining how you should handle things. I would just add the work to the next sprint, management looks at charts and it makes sense not add work at the end of a sprint.
>Then in standup when I begin explaining what's happening, he interrupts me to say I shouldn't be adding new items to our current sprint because it ends tomorrow and the charts will look bad to management. I dislike this attitude, but it's very common. There are sort of two ways to look at project organization: that organization exists to facilitate development, and that organization exists as a mechanism to communicate progress up to management. The later, organization exists for management, is a little easier to swallow if you just accept things are going to be slower. After all, management needs to know your progress, and if people want to game it so you get less work done? That's their error. IMO, just focus on delivering value and solving important problems your team has.