5 ms·

> what are the pros and cons of sprints From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorit

> what are the pros and cons of sprints From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities. From the team/developer's POV, I personally feel like it gives me more freedom (I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog) and a good ratio between work variety (I have the opportunity to work on something different every 2 weeks) and work stability/visibility (once the sprint planning is done, the sprint backlog normally won't change for 2 weeks). > what are the pros and cons of daily standups Ensure that everyone in the team is on the same boat. Encourage communication between developers<->developers and developers<->product manager. I often read on HN that daily standups is micromanagement, but I've never felt it that way (in 10 years of doing agile/scrum in different companies, from the developer's POV as well as from the manager's POV). I guess it can vary from company to company and team to team tho.

rdsubhas 6y ago
>> what are the pros and cons of sprints > From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities. Or rather, from the team's PoV — to NOT change priorities for 2 weeks, to not have side channel communications, or random diversions from email or chats, and being able to focus for 2 weeks without getting carried away. I've been in too many companies with an "inverted" org structure, dozens of managers trying to push stuff into a lone programmer (inverted pyramid). Being able to lock down the backlog, focus for 2 weeks, close the door on background requests (perfect reason "we're in the middle of the sprint"), and leave those managers to fight between themselves in the background on how to prioritize the next 2 weeks — it's a good thing.
uxp100 6y ago
> I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog This part always interests me because I've never worked on a team where it actually worked that way, or even made sense to work that way. You get a few people together, a cryptography expert, somebody who knows eMMC really well, everybody kinda knows USB, and one person with much stronger EE skills. And I do go fix a simple bug in the eMMC stack, but for new features its like, well this will take me 10x longer because I'll have to read some long spec. I have no relationship with the hardware folks who I might need to collaborate with. And during this time I guess the EE is having fun, but out of their element implementing Elliptic curve cryptography while the crypto person sits on their hands because they're only still on the team on the assurance that they'd never have to touch their hated SATA driver again? It's not that I don't believe it works, I just wonder how it would work for me.
- ggregoire 6y ago
  Not sure how it could work in your case. I think the main use case for SCRUM is applications development (web, desktop, mobile, whatever). In that context you have a mixed team of backend and frontend developers, or even better (in my opinion) a team of full stack developers. And so, tasks are not gatekeeped behind domain expertise and everyone in the team is able to pick whatever they want. Some developers usually have more experience with some parts of the codebase, but it's a good opportunity for the other developers to get comfortable with it too (which is, by the way, highly encouraged from the company's POV, in case if the only developer who knows that part of the codebase leaves the company).
  - uxp100 6y ago
    I think maybe it has to do with having "product teams." There is no worry that we'd collapse if our EE or crypto experts left, we've got many more, just not on this team. And having one product per team is not typical except for specific "products" I happen to be involved in, for both practical (this software is written much differently than anything else for many reasons) and historical (this team at one point worked on a similar in some ways, completely different in others, product in the past, that was in a different business unit, with a different target platform and a different customer, and when that whole class of products stopped existing, they were moved over here).

rdsubhas 6y ago

>> what are the pros and cons of sprints > From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities. Or rather, from the team's PoV — to NOT change priorities for 2 weeks, to not have side channel communications, or random diversions from email or chats, and being able to focus for 2 weeks without getting carried away. I've been in too many companies with an "inverted" org structure, dozens of managers trying to push stuff into a lone programmer (inverted pyramid). Being able to lock down the backlog, focus for 2 weeks, close the door on background requests (perfect reason "we're in the middle of the sprint"), and leave those managers to fight between themselves in the background on how to prioritize the next 2 weeks — it's a good thing.

uxp100 6y ago

> I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog This part always interests me because I've never worked on a team where it actually worked that way, or even made sense to work that way. You get a few people together, a cryptography expert, somebody who knows eMMC really well, everybody kinda knows USB, and one person with much stronger EE skills. And I do go fix a simple bug in the eMMC stack, but for new features its like, well this will take me 10x longer because I'll have to read some long spec. I have no relationship with the hardware folks who I might need to collaborate with. And during this time I guess the EE is having fun, but out of their element implementing Elliptic curve cryptography while the crypto person sits on their hands because they're only still on the team on the assurance that they'd never have to touch their hated SATA driver again? It's not that I don't believe it works, I just wonder how it would work for me.

ggregoire 6y ago
Not sure how it could work in your case. I think the main use case for SCRUM is applications development (web, desktop, mobile, whatever). In that context you have a mixed team of backend and frontend developers, or even better (in my opinion) a team of full stack developers. And so, tasks are not gatekeeped behind domain expertise and everyone in the team is able to pick whatever they want. Some developers usually have more experience with some parts of the codebase, but it's a good opportunity for the other developers to get comfortable with it too (which is, by the way, highly encouraged from the company's POV, in case if the only developer who knows that part of the codebase leaves the company).
- uxp100 6y ago
  I think maybe it has to do with having "product teams." There is no worry that we'd collapse if our EE or crypto experts left, we've got many more, just not on this team. And having one product per team is not typical except for specific "products" I happen to be involved in, for both practical (this software is written much differently than anything else for many reasons) and historical (this team at one point worked on a similar in some ways, completely different in others, product in the past, that was in a different business unit, with a different target platform and a different customer, and when that whole class of products stopped existing, they were moved over here).