Our wise previous Scrum Master, Dave Taylor, asked on LinkedIn:

Thoughts on teams/orgs that have already tried scrum but not found it useful. I’m always curious to understand which parts they didn’t like or find relevant to them - quite often we’ll discover that it’s things that are not actually Scrum anyway.

It's a great question. Dave taught me a lot about Scrum and was one of the few people I've met that seems to understand it. At least as far as I can tell, as I don't :)

I personally think pretty much all of Scrum is useful. IMO, the one thing I really don't like about Scrum is that it's REALLY REALLY HARD to implement! And the Scrum Guide seems to only lay out a basic foundation, then you're on your own.

Here's the things I've personally found hard to achieve at Pocketworks. It's not that this stuff isn't useful, it's just that it's hard to implement.

DISCLAIMER: I'm not Scrum certified and might not understand some of this stuff!

So, what's so hard about Scrum?

Org Change

It often needs profound changes in attitude and business structure. Doing it properly probably means changing many aspects of your software business. That includes leadership, organisational structure, management styles, recruitment and promotions. This is a LOT to ask.

Cultural Change

To make it worse, if your company doesn't align with the scrum values, you're going to struggle. Cultural change isn't easy. Àgain, it's a lot to ask of a business.

Training

Because the concepts require quite a shift from traditional thinking, they're hard for people to accept, grasp and then live by. So training isn't easy. It requires a mind-shift. Training people on any kind of business process can be hard.

If you don't believe me, look at how many certified Scrum Masters are asked to perform project-management duties. Or look at how many Product Owners don't have the final say. Or how many Scrum development teams are downstream of separate UX/design teams. None of this would be happening if training Scrum was easy.

Cross-functional Teams

Scrum encourages forming teams that can create a shippable increment. This means having a mixture of designers, developers etc on the same team. Many companies find it easier to silo teams into different departments. So you have your iOS team, or your Design Team. These are then dependent on external teams to ship an increment. In some situations, this might mean org restructuring. Not for the faint hearted!

No Hand-overs

It feels logical to introduce things like "Design Sign Off" or "Peer Review". But Scrum encourages us remove stage gates in order to increase speed. That's counter-intuitive sometimes, you'd assume people with similar skills want to sit together. But instead, Scrum advocates usually encourage arranging people around the work.

No Team Heirarchy

Most companies want their Senior Developer, Lead UX or Architect roles. The idea that certain experienced people get the final say. Scrum doesn't recognise or encourage such heirarchy. But if you do that you're basically saying "This person has less autonomy and responsibility than the other". Scrum pushes for self-organising teams, which means they may elect to distribute such responsibilities amongst themselves, but not as mandated by the wider business.

Regular Stakeholder Feedback

Scrum advocates a series of feedback loops. One of these is that end-users and stakeholders should review the software every increment. Getting everyone in a room every few weeks is hard. Basically, people are busy, and they have to prioritise reiewing the software otherwise those reviews don't happen, which ultimatley means you're missing a key ingredient of Scrum.

And imagine this in a bank, where people are used to status reports and hands-off milestone tracking. None of that. If you want to see where stuff is at, go look at it.

Shippable Increments

Similarly, Scrum recommends that every week we have a potentially shippable increment of a product every Sprint. This is really hard because teams then have to take time to figure out how to slice the work up so that they can ship something in the sprint. It's easier just to crack on and hope for the best. So everyone has to appreciate the value of always-shippable.

Product Owner as Final Decision Maker

I've rarely heard about this being the case. The Product Owner is supposed to be a CEO of the product, managing profit and loss, budgets, performance, vision etc. But in reality PO's tend to end up being more like project managers where other teams or executives call the shots.

Terminology

People often Scrum requires things that it doesn't. None of these are part of Scrum...

• Story Points
• Stories
• Velocity
• Demos
• Refinement as-a Meeting (it's ongoing)

Story Points

"5 points is a day's work for our team". You hear this kind of crap all the time. Although points aren't even part of Scrum, it's so annoying how people still do this and associate it with Scrum. I spoke to a CEO last week who said "My team said they can do 1.5 points a day, and I told them they needed to buckle down and do 2 points a day". It's not his fault. It's just hard. I spent ten minutes trying to explain it and he still didn't get it. They're an awesome tool but few can get to grips with them and they end up being misused.

Thoughts welcome.