3 ms·

One would expect Scrum to disempower developers. After all, it is a management methodology (yes, I know some will protest at this label), and it emphasizes thos

One would expect Scrum to disempower developers. After all, it is a management methodology (yes, I know some will protest at this label), and it emphasizes those things as a result. Any resemblance to software development methodology has long been lost, if it was ever there at all. That said, an entire industry has emerged to sell this methodology, and it is supporting a vast array of jobs: everything from those selling the certifications, to the software used to track developers. There are too many vested interests now, and no company wants to admit that it burned through thousands of dollars, with dubious results, to "train" managers and subscribe to the usual software bundles. I expect the comments here will also have the usual comments about how Scrum is great, and everyone who is critical of it is just doing it wrong.

kaustyap 8y ago
On contrary I found scrum to be empowering for developers at least in my organization. Earlier, we used to have Technical Manager who provided estimate for a feature/project just based on his gut feeling which often was challenging and not feasible. But then developers needed to burn midnight oil to achieve the targeted release date. It often put enormous pressure on highly talented and competitive developers who had to cover up for less skilled developers. Now the development team is empowered to give its own estimation considering all factors. Mind you, in can lead to overestimation, but then we have experienced Technical Lead working also as a scrum master and individual contributor who is there to correct the course. In general scrum will work best when 1. The product owner is from technical background with enormous experience under his belt in product development/architecture. The Product owner does not work alone in silos to create backlog but interacts with development team regularly to refine the backlog. In our case, the product owner is someone with 20+ years of experience who has worked in roles like developer/architect. 2. The scrum master is also highly technical person who has been working on the product for several years. In our team, the same person wears different hats as per the need like scrum master/technical leader/individual contributor. It may not be exactly as per scrum guidelines but worked fine so far for us. Ultimately we need to look for good practices in each methodology and bend it as per our needs.

kaustyap 8y ago

On contrary I found scrum to be empowering for developers at least in my organization. Earlier, we used to have Technical Manager who provided estimate for a feature/project just based on his gut feeling which often was challenging and not feasible. But then developers needed to burn midnight oil to achieve the targeted release date. It often put enormous pressure on highly talented and competitive developers who had to cover up for less skilled developers. Now the development team is empowered to give its own estimation considering all factors. Mind you, in can lead to overestimation, but then we have experienced Technical Lead working also as a scrum master and individual contributor who is there to correct the course. In general scrum will work best when 1. The product owner is from technical background with enormous experience under his belt in product development/architecture. The Product owner does not work alone in silos to create backlog but interacts with development team regularly to refine the backlog. In our case, the product owner is someone with 20+ years of experience who has worked in roles like developer/architect. 2. The scrum master is also highly technical person who has been working on the product for several years. In our team, the same person wears different hats as per the need like scrum master/technical leader/individual contributor. It may not be exactly as per scrum guidelines but worked fine so far for us. Ultimately we need to look for good practices in each methodology and bend it as per our needs.