3 ms·
"You separate the business from the development. You need a product guy, interested in features that will move the product fwd. He is called the product owner.
by psranga 18y ago
"You separate the business from the development. You need a product guy, interested in features that will move the product fwd. He is called the product owner. He keeps a file (an excel works best) - a product backlog - with all the features, called user stories. They are organized by priority. The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers."
"break them into atomic tasks": I didn't think this sort of hyper-specialization would work in a fast-paced environment. It seems to treat developers as just English-to-C++ translators.
My experience has been that specifying in great detail HOW to do things (as SCRUM does for s/w development) doesn't work as well as specifying WHAT to do and letting people figure out how to do it, but holding them accountable for results. The latter style will naturally result in the evolution of automated systems such as regressions, quantitative user feedback, beta progam etc to ensure that the work got done and quality is maintained.
One should have some structure and avoid reinventing the wheel, but I'm skeptical of detailed recipes like this.
- vladimiroane 18y agoWhen all the developers are the founders your approach will work. If you have a different dev team it is very very difficult to make your team so dedicated as you are. I think we have such a team but still having a system to put all the user stories on the same page and see how the team is moving helps a lot. If you reduce Agile to hyper specialization you loose a lot. It helped us a lot by: - defining what Done means - setting goals so we can release something new every 2 weeks - measuring our activity: what doesn't get measured doesn't get managed etc And it is not about telling people how to do things. They decide how to do it, how long it takes etc... So I think you either got that wrong or I explained it badly!
- psranga 18y agoWhat I meant is that the SCRUM inventors are telling you in great detail how to run the technical side of a software business. Not that it's telling the developer how to implement something.
- vladimiroane 18y agoNot true. They give some principles and you have to decide how to use them. The same with GTD: you can use a pen and paper or an iPhone. How you do it depends on you.
- gruseom 18y agoMy experience has been that specifying in great detail HOW to do things (as SCRUM does for s/w development) doesn't work as well as specifying WHAT to do and letting people figure out how to do it, but holding them accountable for results. This description of Scrum is so wrong that it couldn't get wronger. Scrum says: the product owner says what they want, the team decides how much they can deliver in a month, then they go off and do it however the hell they choose. After a month they come back and demonstrate what they got done, in the form of working software and only working software. The stakeholders then get to decide whether they like the progress that's been made and whether or not to continue for another month. Nobody gets to interrupt the team while they're working and nobody gets to tell the team how to do their work. That's the heart of Scrum. You can see it's much closer to the opposite of how you described it. But then I noticed that you were merely responding to this, which is obviously where the wrong idea came from: The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers This is risible. If that's what they're calling Scrum, I fully share your skepticism. It's the essence of the failed approach that Scrum was a reaction against.