Tim Gregory

It seems as if the Scrum folks really don’t like anyone asking questions about the real-world implementation of Scrum…

Firstly, we use Scrum every day at 24.com. It’s changed our development teams, and has had a significantly positive effect on our business.
I regard myself as a Scrum advocate, and enthusiastically recommend Scrum to teams that have not tried it.
We have been using Scrum for about 2 years now, and I regard our Scrum teams and processes as mature and stable.
I am a member of the Scrum Practitioners forum on LinkedIn, along with 8000+ others.
I’ve been watching one of the threads with some intererest – it is titled “Who says they are doing Scrum But?“.
For those unfamiliar with the term, “Scrum But” (or “Scrumbutt”) refers to the commonly heard expression “oh yes, we’re doing Scrum, but we (insert some tweak to or deviation from the process here)”

The debate on LinkedIn has been swinging back and forth, and participants seem to be divided into a few basic camps :

1. True believers – there is a Scrum answer to everything, and if you you can’t make the process work in your environment, then you are not trying hard enough, you have no discipline, and you need to go read some books or watch a video. Or maybe pay for some Scrum coaching / training / certification. Don’t like discussion with the Pragmatists or the Critics. Prefer to speak to other True Believers at Scrum Gatherings, and to dish out “try harder” advice to Strugglers.
2. Pragmatists – adopt the term Scrum, but are happy to inspect and tweak their processes for their environment. Sometimes they are unable to make the sweeping structural changes that would enable all the elements of Scrum. Sometimes they can enhance the performance of Scrum for their environment. Seem unperturbed by the True Believers or the Strugglers. Mildly interested in what the Critics have to say. Happy to share real-world experience.
3. Strugglers – these are teams that are trying to adopt Scrum, but haven’t really grasped the principles. Their processes are not working, they have entire sprints failing, and the promised productivity increases are not being realised. Typically, these teams have tweaked Scrum in a way that breaks the process completely, like not actually having shipping software at the end of a sprint, or doing twice-weekly standups, or not bothering with retrospectives. Looking for answers, but don’t know who they should listen to. Like what they hear from the True Believers, but don’t seem to be able to actually follow good advice, regardless of where it comes from.
4. Critics – these are the most dangerous of the lot.. these are people who understand the Scrum process well, have used it in production environments, have used Lean and Agile principles outside of the Scrum framework, and have worked with both disfunctional and high-performing teams. They have a few bones to pick with the Scrum process, and they want to do it publicly
5. Indifferent masses – These are the 8000+ people in the LinkedIn group who have some interest in Scrum, or perhaps they use it sucessfully. Don’t really care about the discussion. Just want to be surrounded by lots of Certified Scrum people

I’m being deliberately provocative, but this is still a fair summary of the landscape.

I was completely astounded to see a post today from a member of the Board of Directors at the Scrum Alliance threatening to leave the group and the discussion because he was tired of seeing debate and challenge around the Scrum process.
Part of the reason put forward was the time-pressures of the upcoming Scrum Gatherings (i.e. gatherings of True Believers).
In his post to the group, it was suggested that the name of the group should more appropriately be Scrum Debaters or Scrum Challengers rather than Scrum Practicioners.

Amazing… any discussion, debate, and criticism amongst people who are actually evaluating, implementing and using Scrum is now too much to bear??

So I looked a little further afield to see what was being said online about Scrum, and whether I was alone in thinking that it was a very lightweight framework, and needed significant input to make it workable.

And I found a gem of a post that perfectly and lucidly pulls together some of my criticisms of Scrum called It’s time for Scrum to evolve. It’s built around a series of points raised on the Scrumdevelopment Yahoo! Group by Uncle Bob Martin, and repeated here:

1. No technical practices. Scrum is great at giving project management advice, but provides no technical help for the developer. Any good implementation of Scrum needs to borrow technical practices from some other method like XP. The suite of technical practices that should be added probably include: TDD, Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.
2. 30 day sprints are too long. Most scrum teams have either shrunk them to 2
   weeks or perform some kind of midpoint check at the two week mark. I know of some teams that have two 2-week “iterations” inside a single 4-week “sprint”.
   The difference being that they use the sprint for reporting upwards, but use the iterations for internal feedback and control.
3. The tendency of the scrum master to arrogate project management powers. This is not a problem with Scrum out of the box so much as it is a problem with the way scrum sometimes evolves. Perhaps it is related to the unfortunate use of the word “master”. Perhaps the XP term “Coach” might be a better word to use. In any case, good implementation of scrum do not necessarily correlate scrum masters and project managers.
4. The C in CSM (Certified Scrum Master) is unfortunate. Again, this is not so much about scrum out of the box as it is about the scrum community. That letter C has gotten far too significant for it’s intention. It is true that the people in a scrum team need to be trained. One of the things they should be trained about is the role of the scrum master. The problem with the C is that it changes the notion of scrum master from a role into a person. It is the person who has the C. In an ideal case, the members of the scrum team will rotate through the scrum master role the same way the members of an XP team rotate through the coach role. This rotation is never perfect, and sometimes the role sticks to one or two people more than others. But the idea was never to raise up a particular person with a rank. We never wanted that C emblazoned on their chests.
5. Scrum provides insufficient guidance regarding the structure of the backlog. We’ve learned, over the years, that backlogs are hierarchical entities
   consisting of epics, themes, stories, etc. We’ve learned how to estimate them statistically. We’ve learned how and when to break the higher level entities
   down into lower level entities. Epics->Themes->Stories->Tasks.
6. Scrum carries an anti-management undercurrent that is counter-productive. Scrum over-emphasizes the role of the team as self-managing. Self-organizing and self-managing teams are a good thing. But there is a limit to how much a team can self-X. Teams still need to be managed by someone who is responsible to the business. Scrum does not describe this with enough balance.
7. Automated Testing. Although this could be considered a derivative of point 1, I thought it worth calling out as a separate point because it is so
   fundamental. Scrum doesn’t mention this, yet it is the foundation of every agile effort. Agile teams work in short cycles because feedback only works well
   in short cycles. But short cycles aren’t enough. You also need objective measurement of progress. The most reliable way to know how much a team has
   gotten done is to run automated tests and count the tests that pass.
8. Multiple teams. Scrum has little to say about the coordination of multiple teams. This is not a failing unique to scrum. Agile itself is virtually silent
   on this issue. Scrum talked about the vague notion of a “Scrum of Scrums” but that idea really hasn’t played out all that well. Scrum-in-the-large remains in
   the domain of certain consultants who claim to have an answer. There is no real consensus on the issue.

Bravo. Nicely put Bob. And I’ll add my own to the list -

• Managing multiple stakeholders

Large organisations rarely have a single person who is true Product Owner and has executive decision-making powers.
An individual with this power is likely to be far too senior to be co-located with the development team and dedicated to the Product Owner role.
And even when there is a dedicated Product Owner, that person is still usually not a technical manager, and unlikely to ensure that good engineering practices are adhered to or that technical maintenance is performed (system upgrades etc.)
So just by having a technical manager involved you already have more than one person who has a stake in the backlog.
I haven’t even got onto the topic of performance management, discipline and reward on the Scrum team.
Scrum is silent on this point, and advocates usually waffle about “self-managed teams”. As if somehow the team is going to create the budget, recruit team members, manage performance and rewards, and discipline / dismiss underperforming team members.
I know that Scrum doesn’t say that team self-management means no managers in the organisation, but the relationship between team managers, Scrum Masters and Product Owners is not clear.

I don’t think Scrum is broken. I don’t want to throw it out or replace it with something else.
But I think the Scrum community should face up to the challenges in the spirit of the Agile movement that created Scrum, and should not be afraid of change.

I welcome your comments below – is Scrum perfect? Does everyone do Scrum-but? Have you tried Scrum and moved to something else that works better for you?