Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Oct 11, 2010 — Enterprise Agile Planning expert

But Scrum

Enterprise Agile Planning

Most of us have heard of the term ‘Scrum but’ – it refers to agile teams that are trying Scrum processes but are having some challenges. For example, a group that is exhibiting ‘Scrum but’ might say something like ‘We are practicing Scrum, but our sprints are anywhere between 6 and 8 weeks;’ ‘We are practicing Scrum, but we don’t always deliver working code at the end of the iteration.’

Yes, these are bad situations. But let’s look at the flipside – let’s look at ‘But Scrum.’

‘But Scrum’ is when a person/team/organization flips off their ‘thinking bit’ and just burps up whatever Scrum tells them to do. Want some examples?

  • But Scrum says we estimate
    I have personally been around agile teams that don’t estimate all of their items in their backlog. Why? Multitudes of reasons. A couple of examples:
    1. Teams break down their work far enough (day range) where the variance in the estimates would be minuscule.
    2. A team works really well together and can accurately predict how much they can get done, without worrying about points
  • But Scrum says we need self-organizing teams
    Yep, self-organizing teams would be awesome. There is a magic dashboard of work on the wall and people will just naturally float over and create uber teams to crush out work. Most large organizations are still structured in classical, matrixed manner. Telling their IT departments to ‘self-organize’ is irresponsible. Most people multi-task. Is it a problem? Sure. Is it a reality? You betcha. Specialization is an output from our national hiring structure – just look at any job boards for confirmation. Good luck changing that inertia.
  • But Scrum says we need a Scrum Master
    By no means do I have hard numbers to back this up, but look at it this way: If Scrum masters were making agile software development and delivery so much better, then given the rate of CSMs being handed out, we should have some bad bamma jamma software coming out from the majority of organizations. But we don’t. I’m not even going to get into the whole certification battle. Little known fact – Patrick Duffy is a Scrum Master.
  • But Scrum says once we commit, the backlog doesn’t change
    Right, because market events and competition only happen in nice, predictable cycles
  • But Scrum says our teams should be 7, +- 2
    There are plenty of Scrum development teams out there working well with a size over 10 as well as split geographically. A team that works well together is a team that works well together.

Which is worse – ‘Scrum but’ or ‘But Scrum’? They are both horrible. One is giving excuses why you can’t try and change; the other is giving excuses why you can’t change what you are trying. Both are pointless.

The reality is developing a software product is hard. It requires thought, inspection, change, and risk. You have to think.

What other ‘But Scrum’ comments have you heard? Let’s collect them.

The post But Scrum appeared first on VersionOne Blog.

More from the Blog

View more
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Contact Us