That guy what is the problem.
So.
So.
So.
One of the managers (team size: 2) at our company keeps trying to tell the scrum masters to do our jobs differently. Through email.
Which, first: This is why we have retros, you fuck. I am not changing the group norm in the middle of a sprint because you sent a fucking email. No fucking way, and you go fuck right off.
And, second: Your knowledge of how to lead people and methods is dangerously low. Like, for fucks sake you thought it was revolutionary that when I started I scheduled time to talk to people instead of just grabbing people while they were working.
So.
What my group has decided to do is for each person to create their own subtasks. This is generally the same for each task: Dev, Migrate, Test, blah blah blah who cares. Point is: The norm my team has decided on is for them to be responsible for creating their own subtasks.
Then, I go back through and make sure they were created because I'm cool like that.
What he is asking: SM's to make all the subtasks so that devs and testers can focus on real work.
Why I think it is good for the team to make their subtasks: Ownership. If they make the subtask, they feel like it is theres. And it takes, like, a few seconds per task. Do them all at once and now you know what your tasks are for the sprint. Cool, right?
Subscribe to:
Post Comments (Atom)
How about SM’s take on all the burden of synchronizing their understanding of sub-task structure and adjusting to dev’s preferred structure, so devs and testers can focus on real work?
ReplyDeleteTony: This dude has left me in a testy mood, and I am not sure how to take what you said.
ReplyDeleteI think what you mean is: This dude is a jerk, but what my jerk brain is hearing you say is: William is bad at his job.
Which is right, if either?
What I’m saying is “The way you’re doing it saves devs work... which is what this guy claims he wants.” Sorry to be unclear.
ReplyDeleteI find it way easier just to create a few tasks than to figure out why someone created them for me and what they expect me to do with that structure.
My devs create their own subtasks. MY SM is only there to enact the rituals and clear roadblocks.
ReplyDeleteOh, and in case there’s any doubt: that guy’s a jerk. “Let’s change the rituals for the whole team because I sent an email!” How about let’s don’t.
ReplyDeleteOmg.
ReplyDeleteSame fucking guy sent an email to devs and managers saying: I know some of you are frustrated. Tell me why.
Fuck that guy. They are frustrated because you are shitty.
On. A. Friday?
ReplyDeleteAt four o'clock on a Friday. To my devs
ReplyDeleteThat guy is wrong, and you are right.
ReplyDeleteSubtasks. Are. For. Devs. Wtf.
ReplyDeleteomg, he wrote back.
ReplyDeleteSo So So.
Him: Everyone should do things the same. Garh, SMs should make subtasks.
Me, with politeness: No. At the very least, not this sprint.
Boss's boss: Good conversation, thank you both! How about we say no data entry during planning?
Me, internally: ... who the fuck would do that? Oh, S does that. Of course I wouldn't do that.
Him: The way S handled it was great. You should all standardize across scrums, and do it the way S did it. The difference is hard for devs.
Me: ...
Me, internally: Devs shouldn't be on multiple teams. Hard fucking stop. Subtasks are owned by the team, not by me. I'm not a data entry clerk. I will not change how we do things in the middle of a sprint. I am going to ignore this email, and tell my boss the handle this half wit from now on.
I've been nicer than this is email, but am very much considering saying something like: You are wrong. Stahp.
ReplyDeleteI mean lots of people use task and sub task differently... but sub division of one person's sprint long or less task into sub tasks clearly belongs to that person.
ReplyDeleteStandardized process enforcement, i.e. making sure there are unit tests, is for code review and access controls on commits to master. If needed...
"What problem are we solving?"
ReplyDelete"Who has that problem?"
"Do they think it's a solution?"