3 ms·

> 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 w

by 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).

by uxp100 6y ago

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).