Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't think the 20% is a good solution because it requires engineers to compartmentalize. If the 20% is more interesting than the 80%, how are they going to do good work on the 80%? Plus, show me a manager that's happy to let an engineer take a few sprints of accrued 20% time off from the normal work.

On the flip side, you can get most people to care about the engineering work they are doing if you don't burden them with unnecessary red tape. A good example for how this can work is how Valve [1] supposedly works: true multidisciplinary teams that are empowered to organize and work on a project as they see fit. This was the only way I saw teams work truly efficiently.

If management needs to know exactly when a project is finished, they just need to agree on a deadline with the team. Scrum isn't there to provide that, nor did I ever see it work. However, I have seen a lot of wishful thinking and make-believe metrics such as managers making up a project to be "5000 story points" out of thin air (based on 1-2% of the project being spec'ed out, even less being completed) and then doing deadline calculations based on that.

[1]: Valve handbook for new employees, page 16, https://www.valvesoftware.com/en/publications



"we estimate that this project is 5000 story points"

"5000 story points Bob? What do you figure, is that a medium or a large t-shirt?, 2 or 3 quarters?"

"... Medium, but you know we don't like to acknowledge that quarters are 2500 story points... Agile, you know?"

"Oh I get it Bob"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: