If my organizational needs are victory for Oceania over the rival nation of Eurasia, is it best that I insist team members adopt Newspeak as a scrum ritual immediately, or should we ease in during a transitional period? Also, what are best practices for revising the plans and achieved tasks of past sprints?
Demanding anything if the dev team is essentially the opposite of scrum, Tony Lower-Basch, as is documenting for its own sake or revising the past. Instead, scrum focuses on empowering the dev team and building shippable product increments.
Well... if no part of the organization except the devs can assert needs in a way to which the devs are obliged to respond, then nobody actually has needs, apart from the need to stay out of the devs way, right?
There's a misunderstanding here. The devs are empowered to decide how to get things done. The Product Owner -- not previously mentioned -- is responsible for making sure the stories in the sprint are the most valuable ones.
The team commits to the sprint and the work; no one outside the team can commit them to getting tasks done.
[ It’s hard to tell whether we’re doing light-hearted satire, where you are earnest in the role of a straight-man, or if you’re really being earnest and would feel hurt if people made jokes. ]
[ I was aiming for satire with a grain of humorous truth about how susceptible the scrum rhetoric is to being hijacked by the kind of techniques Orwell outlined in 1984, but if you’re aiming for a straighter conversation about methodologies that you’re stoked for then I’ll apologize for misjudging, and shift my tone. ]
John Hattan single person shops? That's gonna be hard; be default, scrum wants a dev team + a scrum master + a product owner, without any overlap of roles.
That being said, I'd wager the notion of a sprint may provide value to you -- determining in advance what the next product increment is, doing that in, say, 2 weeks, and then publishing. I'd also bet you're already doing something similar.
Larry Lade A little from column A, and a heap of hope for column B. I'm transitioning into a managerial role, and have the witnessed promise of someone both powerful and so-far trustworthy that, if I show leadership capability, then I'll have the title and money. So, it's like an extended job interview.
And, because I'm not a complete fool, I have exit plans and am working on leverage in case it is necessary.
Alexander Newman Interestingly enough, the name comes from Rugby. The idea is that previous types of software development were more like a relay race -- a software architect takes it for a while, then hands off to a developer, who hands off to a tester, etc. The word scrum was chosen for the notion that everybody is huddled together getting the ball (the product increment) forward together.
William Nichols: I'll be very interested to see how the scrum ideology works out in your particular circumstances.
My experience is that everybody "does it wrong," one way or the other. If it works as promised for the devs, then it makes everybody else miserable. If it works for anybody but the devs, that's at the expense of devs giving up on the dream of (supposedly) benevolent developer-dictatorship.
Tony Lower-Basch Much as I respect your experience, this still suggests a misunderstanding: scrum dev teams are self-organizing, sure, but what they work on is determined by the product owner, who is not a dev and represents the client. The PO is responsible for ensuring business value is delivered.
It’s possible that I’m laboring under a misunderstanding! After all, my experience is embedded in a particular system.
What great power does the PO have, to go along with their great responsibility? Like, if they put business problems on the list of work, and the devs are on track to deliver something technically shiny and cool of their own invention, but it is either not going to be pleasing to the customer, or will be too late to be useful (or both), how does the P.O. ensure that business value is delivered?
Tony Lower-Basch Ideally, that situation should never come about! That is, the PO orders the work, and at the beginning of each sprint the dev team estimates difficulty and figures out what they can commit to this sprint; the work of the dev team comes from this single source that is the produce backlog as maintained by the PO.
Patty Kirsch I don't think there is in scrum, but here's how I'd maybe handle it: Dev 1: task A is easy, one story point. Dev 2: Task A is hard, it's like 8 story points. It belongs way over to the right with task B. Dev 1: No way, task B is way harder than task A. Me: Um. It's Dev 2's turn. Why is it hard? Dev 2: Because it relies on task C, D, and E, and we don't have those scoped out yet! Dev 1: I didn't realize.
So ... I dunno. communication?
That's a cop out, I know. Maybe this: Dev 1: Task A is easy, one story point. Dev 2: No way! That's super hard, like task B. Dev 1: Pfft. Me: Um. ok, it sounds like it'd maybe be easy for dev 1 and hard for dev 2. Let's call it, say, 3 story points and make sure dev 1 takes it. This is just an estimation, and if it turns out harder we can revise the estimate. No problem.
William: Sure, ideally that won't come about. But if it does, it's the POs responsibility to fix it (to ensure that business value is delivered) so it seems natural to ask what power and leverage they have to make that happen, right?
Point being: If it's happened that the dev team is working on something that isn't on the product backlog, not within the sprint, and that the PO -- the voice of the customer -- doesn't care about?
William: That's not what I'm positing. I'm positing that they work on something that is absolutely within the sprint.
They would then decide, themselves, what the best solution to that problem is, right?
What if they decide wrong? Or what if it takes long enough that they miss a deadline that actually matters (delivering a system for taking payments for an event the day after the event, for instance)?
"Disasters will never happen" is not a viable disaster recovery strategy.
The dev team commits to getting done A, B, and C, for sake of argument. A is most important, then B, then C. They think they can get 'em all done in the two week long sprint, and are wrong. Sure. That can -- and should sometimes -- happen.
When you do in scrum s change the scope of the sprint. You don't get extra days, you talk to the PO and remove stuff from the sprint. Maybe you can get A and B done, but C is proving intractible. Maybe you can get a skeleton done of C, and that'll have to be good enough for this sprint -- and should (if we're lucky) make finishing C easier in the future.
That make sense? You, like, communicate constantly and shit.
How much scrum is too much scrum
ReplyDeleteI think that depends on the organization needs, Orion Cooper
ReplyDeleteThat's agile methodology, which is a project management technique, correct?
ReplyDeleteAnd scrum is based on a rugby term, as I recall.
ReplyDeleteThat is all technically true, yes
ReplyDeleteIf my organizational needs are victory for Oceania over the rival nation of Eurasia, is it best that I insist team members adopt Newspeak as a scrum ritual immediately, or should we ease in during a transitional period? Also, what are best practices for revising the plans and achieved tasks of past sprints?
ReplyDeleteDemanding anything if the dev team is essentially the opposite of scrum, Tony Lower-Basch, as is documenting for its own sake or revising the past. Instead, scrum focuses on empowering the dev team and building shippable product increments.
ReplyDeleteOh, so “organizational needs” are a fiction? That makes more sense.
ReplyDeleteI'm not sure where that came from.
ReplyDeleteWell... if no part of the organization except the devs can assert needs in a way to which the devs are obliged to respond, then nobody actually has needs, apart from the need to stay out of the devs way, right?
ReplyDeleteThere's a misunderstanding here. The devs are empowered to decide how to get things done. The Product Owner -- not previously mentioned -- is responsible for making sure the stories in the sprint are the most valuable ones.
ReplyDeleteThe team commits to the sprint and the work; no one outside the team can commit them to getting tasks done.
[ It’s hard to tell whether we’re doing light-hearted satire, where you are earnest in the role of a straight-man, or if you’re really being earnest and would feel hurt if people made jokes. ]
ReplyDeleteIt's hard to know about you, too!
ReplyDelete[ I was aiming for satire with a grain of humorous truth about how susceptible the scrum rhetoric is to being hijacked by the kind of techniques Orwell outlined in 1984, but if you’re aiming for a straighter conversation about methodologies that you’re stoked for then I’ll apologize for misjudging, and shift my tone. ]
ReplyDeleteI also know that I have a year's subscription to HackNPlan, which is an agile tool. And I am too danged lazy to learn how to use it.
ReplyDeleteActually, are there any Agile books that are (1) good for the exceptionally lazy and (2) useful for a one-person shop?
Is this for a job you already have, or for advancement?
ReplyDeleteThis is not about rugby, right?
ReplyDeleteTony Lower-Basch Yeah, a shift is in order. I know how this sounds, but if that's how folks are practicing scrum around you, they are doing it wrong.
ReplyDeleteJohn Hattan single person shops? That's gonna be hard; be default, scrum wants a dev team + a scrum master + a product owner, without any overlap of roles.
ReplyDeleteThat being said, I'd wager the notion of a sprint may provide value to you -- determining in advance what the next product increment is, doing that in, say, 2 weeks, and then publishing. I'd also bet you're already doing something similar.
Larry Lade A little from column A, and a heap of hope for column B. I'm transitioning into a managerial role, and have the witnessed promise of someone both powerful and so-far trustworthy that, if I show leadership capability, then I'll have the title and money. So, it's like an extended job interview.
ReplyDeleteAnd, because I'm not a complete fool, I have exit plans and am working on leverage in case it is necessary.
Alexander Newman Interestingly enough, the name comes from Rugby. The idea is that previous types of software development were more like a relay race -- a software architect takes it for a while, then hands off to a developer, who hands off to a tester, etc. The word scrum was chosen for the notion that everybody is huddled together getting the ball (the product increment) forward together.
ReplyDeleteWilliam Nichols: I'll be very interested to see how the scrum ideology works out in your particular circumstances.
ReplyDeleteMy experience is that everybody "does it wrong," one way or the other. If it works as promised for the devs, then it makes everybody else miserable. If it works for anybody but the devs, that's at the expense of devs giving up on the dream of (supposedly) benevolent developer-dictatorship.
Tony Lower-Basch Much as I respect your experience, this still suggests a misunderstanding: scrum dev teams are self-organizing, sure, but what they work on is determined by the product owner, who is not a dev and represents the client. The PO is responsible for ensuring business value is delivered.
ReplyDeleteIt’s possible that I’m laboring under a misunderstanding! After all, my experience is embedded in a particular system.
ReplyDeleteWhat great power does the PO have, to go along with their great responsibility? Like, if they put business problems on the list of work, and the devs are on track to deliver something technically shiny and cool of their own invention, but it is either not going to be pleasing to the customer, or will be too late to be useful (or both), how does the P.O. ensure that business value is delivered?
Is there some way to do story points or similar estimation that doesn't require coming to a consensus?
ReplyDeleteI haven't been in a software scrum meeting for about ten years!
ReplyDeleteTony Lower-Basch Ideally, that situation should never come about! That is, the PO orders the work, and at the beginning of each sprint the dev team estimates difficulty and figures out what they can commit to this sprint; the work of the dev team comes from this single source that is the produce backlog as maintained by the PO.
ReplyDeletePatty Kirsch I don't think there is in scrum, but here's how I'd maybe handle it:
ReplyDeleteDev 1: task A is easy, one story point.
Dev 2: Task A is hard, it's like 8 story points. It belongs way over to the right with task B.
Dev 1: No way, task B is way harder than task A.
Me: Um. It's Dev 2's turn. Why is it hard?
Dev 2: Because it relies on task C, D, and E, and we don't have those scoped out yet!
Dev 1: I didn't realize.
So ... I dunno. communication?
That's a cop out, I know. Maybe this:
Dev 1: Task A is easy, one story point.
Dev 2: No way! That's super hard, like task B.
Dev 1: Pfft.
Me: Um. ok, it sounds like it'd maybe be easy for dev 1 and hard for dev 2. Let's call it, say, 3 story points and make sure dev 1 takes it. This is just an estimation, and if it turns out harder we can revise the estimate. No problem.
Alexander Newman Whyse that?
ReplyDeleteWilliam: Sure, ideally that won't come about. But if it does, it's the POs responsibility to fix it (to ensure that business value is delivered) so it seems natural to ask what power and leverage they have to make that happen, right?
ReplyDeletePoint being: If it's happened that the dev team is working on something that isn't on the product backlog, not within the sprint, and that the PO -- the voice of the customer -- doesn't care about?
ReplyDeleteThen you've got bigger problems. Huuuuuge.
I'm in a different country and don't work any more. A few days ago was the sixth anniversary of my strokes, and brain damage has down sides.
ReplyDeleteWilliam: That's not what I'm positing. I'm positing that they work on something that is absolutely within the sprint.
ReplyDeleteThey would then decide, themselves, what the best solution to that problem is, right?
What if they decide wrong? Or what if it takes long enough that they miss a deadline that actually matters (delivering a system for taking payments for an event the day after the event, for instance)?
"Disasters will never happen" is not a viable disaster recovery strategy.
Tony Lower-Basch Oh, so that. Yes.
ReplyDeleteThe dev team commits to getting done A, B, and C, for sake of argument. A is most important, then B, then C. They think they can get 'em all done in the two week long sprint, and are wrong. Sure. That can -- and should sometimes -- happen.
When you do in scrum s change the scope of the sprint. You don't get extra days, you talk to the PO and remove stuff from the sprint. Maybe you can get A and B done, but C is proving intractible. Maybe you can get a skeleton done of C, and that'll have to be good enough for this sprint -- and should (if we're lucky) make finishing C easier in the future.
That make sense? You, like, communicate constantly and shit.