If Skype is an example of Scrum done well, perhaps that explains why Skype has been very unreliable from and end user perspective for 5+ years... the kind of unreliable where more than half of the outgoing calls are met with instant "So-and-so-contact is not available." responses [edit, added: failure responses so quick that you know the contact was never called, and the problem was within your client app or the Skype systems. Different computers in different locations behaved the same.]
Maybe they were missing what I noticed missing from my last Scrum-focused company: view and attention from the higher altitudes.
Scrum makes it easy to break down features and problems into nice little pieces which can be done within one sprint (often in one day). That is a win in many ways, but it doesn't encourage higher level reviews, refactoring, etc. It's the problem of not seeing the forest for the trees.
Of course you can intentionally create epics for these kinds of reviews, but those don't have a good short-term return value for time spent. And so, they get inadvertently or intentionally postponed. Eventually the system is complex and messy, few people understand the system in entirety, and the easiest Scrummy solution is a re-write.
For me, Scrum was a straightjacket, a hundred NOs against my creativity and my attention to broader concerns. There are times when you are implementing a simple ticket, but you keep touching things that need attention... or you see how the entire system has become convoluted, and you see a better way. To do it the right way either means creating new epics and tickets, debating those with product owners who don't understand the value, and generally NOT solving the real problem.
That's not a fault of scrum. If you can't sell the value of refactors on to product, then either you're not making your case or they aren't being reasonable. But you'd have the same problem with any process. We run kanban mostly and we get refactors and tech debt into the backlog pretty regularly. We also reject them pretty regularly when they don't see any viable business cases.
Maybe they were missing what I noticed missing from my last Scrum-focused company: view and attention from the higher altitudes.
Scrum makes it easy to break down features and problems into nice little pieces which can be done within one sprint (often in one day). That is a win in many ways, but it doesn't encourage higher level reviews, refactoring, etc. It's the problem of not seeing the forest for the trees.
Of course you can intentionally create epics for these kinds of reviews, but those don't have a good short-term return value for time spent. And so, they get inadvertently or intentionally postponed. Eventually the system is complex and messy, few people understand the system in entirety, and the easiest Scrummy solution is a re-write.
For me, Scrum was a straightjacket, a hundred NOs against my creativity and my attention to broader concerns. There are times when you are implementing a simple ticket, but you keep touching things that need attention... or you see how the entire system has become convoluted, and you see a better way. To do it the right way either means creating new epics and tickets, debating those with product owners who don't understand the value, and generally NOT solving the real problem.