This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
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 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:
- Teams break down their work far enough (day range) where the variance in the estimates would be minuscule.
- 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.