4 ms·

I think the main issue with sprints is that people start feeling like robots. This hampers creativity and drive immensely. I've been in ste software industry fo

I think the main issue with sprints is that people start feeling like robots. This hampers creativity and drive immensely. I've been in ste software industry for a good 15+ years and I have never observed the opposite. People start doing pointless busywork like ticket engineerinf instead of being enthusiastic about what they do and working towards that. I've had the displeasure of witnessing several teams die once Scrum was forced on them or they decided to switch themselves.

Sosh101 3y ago
I have experienced this too.
Cthulhu_ 3y ago
That was one of my early experiences with scrum too. That said, I get it; from a higher up management position point of view, scrum gives you stability and predictability, which is what you build businesses with. Unfortunately, most companies are like this. But there should be space for creativity and originality as well. Since this article is about Google, back when they were still considered a great place to work, one major factor was their "20% time"; they acknowledge that most of the work is boring, so they gave you a day a week to work on more creative endeavours. Every software company should do this. Don't make it an occasional hackathon kinda thing, make it part of every sprint or week or month or whichever unit. Give people freedom to create, without expectations. Because if you don't give them that space, they will take it.
- janosdebugs 3y ago
  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 https://www.valvesoftware.com/en/publications
  - datadrivenangel 3y ago
    "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"

Sosh101 3y ago

I have experienced this too.

Cthulhu_ 3y ago

That was one of my early experiences with scrum too. That said, I get it; from a higher up management position point of view, scrum gives you stability and predictability, which is what you build businesses with. Unfortunately, most companies are like this. But there should be space for creativity and originality as well. Since this article is about Google, back when they were still considered a great place to work, one major factor was their "20% time"; they acknowledge that most of the work is boring, so they gave you a day a week to work on more creative endeavours. Every software company should do this. Don't make it an occasional hackathon kinda thing, make it part of every sprint or week or month or whichever unit. Give people freedom to create, without expectations. Because if you don't give them that space, they will take it.

janosdebugs 3y ago
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 https://www.valvesoftware.com/en/publications
- datadrivenangel 3y ago
  "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"