Many people – or maybe it’s just a few loud people – use the language of hatred to discuss topics around Agile, Scrum, XP, TDD, … all those things that have grown up around the Agile Manifesto. Here are a few paraphrased examples:

  • Scrum is a religion
  • TDD doesn’t work
  • Unit tests are a bad idea
  • Scrum meetings are bullshit
  • Everyone in Agile is just in it for the money

It goes on and on. And not only is it irritating, it’s not helpful. Literally not helpful. These statements do not help anyone in any way. Sometimes – I choose to believe – the author is trying to warn his readers away from some particular bad things. The bad things could be real:

  • Doing Scrum things as a matter of faith, not thinking, is a bad idea. Doing them thoughtfully can be quite useful.
  • TDD is a tool, and like all tools, it does not fit every situation. In addition, like every tool, it needs to be used with some skill.
  • Unit tests can be misused in some situations and have drawbacks in many.
  • Bullshit meetings are bullshit. It happens that Scrum does not specify any bullshit meetings, but people have them anyway.
  • Most everyone here is working for a living. Most everyone is trying to deliver the best value they can, because success in business means delivering value, and because most people want to deliver value anyway.

Yes, bunky, there are abuses

Let’s get that out of the way right here. There are abuses. There are companies, or managers, who use Agile/Scrum/XP in an over-controlling fashion.

There are people writing under the Agile/Scrum/XP banner whose ideas are not as good as they might be: some might even be really bad ideas.

There are people selling or pushing Agile/Scrum/XP who do not understand their subject very well. They will misinform people, or push their ideas where they should not be pushed.

There are vendors selling tools that are too much, or too rigid. There are companies who impose these tools on their teams – often again in an over-controlling way.

Yes, there are bad things out there.

Should we therefore simply say “Agile/Scrum/XP is bullshit” and steer people away from it?

I think not, unless we also tell them a better place to go.

Yes, there are some great teams out there

You might be fortunate enough to be on a team that is really delivering great value. You might be delivering well above the level of the best Agile/Scrum/XP teams out there. We’ll explore below what it would mean to be doing that, but if your team is better than Agile/Scrum/XP, by all means stick with it.

But if your company is trying to impose Agile/Scrum/XP on your wonderful team, there are only three possible reasons:

  • Your company is an idiot. If this is the case, your issue isn’t Agile/Scrum/XP, it is your company. As Martin Fowler said, “Change your company, or change your company.”
  • Your company doesn’t know how much great value your team is providing. Well, that’s interesting, isn’t it? Whose fault is that? My guess: you. You’re not doing a good job of showing what you’re doing and how great it is.
  • You’re not delivering value after all. You might be a bunch of great guys, hammering out great code, but not the code your company values. Again, this is your problem – and Agile/Scrum/XP might help after all.

Are they pushing you toward Agile/Scrum/XP? Well, they’re idiots, or you’re bad communicators, or you really aren’t producing value. All these are problems inside your company, not with Agile/Scrum/XP.

What are the “bullshit” ideas anyway?

Let’s start with Scrum. Scrum is bloody simple and I don’t think its ideas are bullshit. Here’s today’s description of Scrum:

Product Owner

Scrum has a role called Product Owner. Product Owner is an empowered individual, accountable to the business, responsible for producing the best possible ROI from the construction of a product. The product is built by the Dev Team, facilitated by the ScrumMaster.

Scrum is bullshit! Our product owner is just an order taker. Comes in with a list from above, tells us to do it.

What part of “empowered” and “responsible” did you not understand? Why are you bitching to me about what Scrum says, when your organization isn’t even doing the first bloody thing on the list?

Scrum is bullshit! Our product owner has full control and she just pushes us into doing things. She doesn’t collaborate at all!

What part of “best possible ROI” did you not understand? Your PO can’t get the best possible ROI by pushing and demanding. She needs to work actively with the team. The Scrum model is that the PO brings in needs and the team collaborates to produce solutions. Why are you bitching about what Scrum says, when you haven’t sorted out the rudiments of it yet?

Product Increment

Scrum specifies that the team will work in an iterative cycle of a week or two, producing a product increment at the end of each cycle. The product increment is to be “potentially shippable”. In essence, this means that the only thing holding back shipping is lack of some desired feature. In all other respects, the product is ready to go. It is integrated. It works without unshippable defects. It is well designed. It is well tested. It is documented so that people could use it.

Everything in the product increment is ready to go. All it lacks is one or more features, which you’ll put in in the upcoming Sprints.

Sprint is a bullshit name! We’re in it for the long haul, we can’t be Sprinting all the time.

Yes, it’s a bullshit name. I suppose it was intended to be inspiring. Call it iteration if you wish. Call it cycle. But ‘king do it! Are you producing a solid, truly ready increment every couple of weeks? If so, good. If not, maybe you have something more important to think about than the name of the two week interval in which you aren’t doing your job.

Scrum is bullshit! In our domain (the Real World, we call it) we can’t possibly get a Product Increment in only two weeks!

Well, now, sweetie, let’s talk about that. Is Scrum bullshit, or is your development practice just not up to snuff? Since I’ve been working in the real world for a half century now and living in it for three-quarters of a century, I’ve seen a lot of development efforts. And one of the things I’ve seen is that every single one of them could learn to ship a solid increment every couple of weeks.

Or, who knows? Maybe you have discovered an area where it’s just not possible to build anything in two weeks. That would surprise me, but I enjoy surprises. Maybe you shouldn’t do Scrum. It’s possible. That doesn’t make Scrum bullshit. I don’t like peaches. That doesn’t make peaches bullshit.

Sprint Planning

So anyway, as I was about to say before you so rudely interrupted, since we’re going to build something every couple of weeks, we need to figure out every couple of weeks what we’re going to build. So the Team sits down, led by the Product Owner, to go over the Product Backlog (a list of things we might do), and selects things to do in the Sprint. (We call the things we select the Sprint Backlog.)

There are two aspects to Sprint Planning, and only two. The Product Owner explains the items that are candidates for inclusion in the Sprint Backlog, and the Dev Team figures out how many to do and how to do them.

Scrum is bullshit! Our product owner dumps a list of stuff on us and demands that we do it all.

What part of “the Dev Team figures out how many to do” did you not understand? Don’t come whining to me about Scrum when you aren’t even doing it. You have a problem with your Product Owner, not with Scrum. Fix that.

And don’t even start with Scrum is bullshit! Our PO tells us exactly how to do things. What part of “and how to do them” did you not understand?

The relationship between Product Owner and Dev Team is one of collaboration. The PO is accountable for getting the best ROI. You don’t get the best ROI by demanding, nor by over-specifying. You get it by using the full power of the whole team to figure out what to do and how to do it. If that’s not happening, it’s not that Scrum is bullshit, it’s that you’re not doing Scrum at all well.

Daily Scrum

Every day, the Dev Team meets and discusses how things are going, producing an understanding of what the upcoming day will hold. They consider what everyone did yesterday, what they plan to do today, and what’s in the way. If things are in the way, they spawn a separate task to get it out of the way. The meeting is time-boxed to 15 minutes and is centered around the developers. Outsiders are welcome to listen but are not expected to say anything.

Scrum is bullshit! Our Daily Scrum takes 45 minutes as we hash through every stupid thing that happened. And that’s after the manager makes a bunch of announcements.

What part of 15 minute time box did you not understand? What part of outsiders not expected to say anything did you not understand? The Daily Scrum is time-boxed, and only Devs speak so that the Devs can figure out their plan for the day. If you go beyond that in your meeting, that’s your choice. If you find it productive, great. If not, don’t come running to Scrum all crying.

Sprint Review

At the end of the two-week Sprint, team and stakeholders meet to review the completed Product Increment and talk about what might be done in the upcoming Sprints. This is a good time to make sure everyone who’s interested knows what happened, and that the team and Product Owner get early feedback on what stakeholders think.

Scrum is bullshit! In our review, the PO looks at what we have done and rejects half of it. Then we just argue over whether we did what the PO said or not.

Um, “completed Product Increment”? Scrum is telling you that you do not have clear acceptance criteria for your work. If you had, you wouldn’t be trying to get things reviewed that aren’t even done. With clear acceptance criteria, the PO might now want something new but wouldn’t be saying the old stuff wasn’t what was asked for.

[Redacted, I’m tired of typing that. I’ll just say !! from now on.] When we get to the review, it turns out even though we tried to do maybe ten things only two of them are done and the rest aren’t quite ready. So we just carry over the work, but the meeting is useless.

Hm, “completed Product Increment” again. Scrum is telling you that you are starting too many things and finishing too few. One usual solution to this are to work on only one or two items at a time, finishing them, then work on one or two more. That way, things tend to be either done or not done, not “almost done”.

If you’ll work that way, you may still discover that you took on too much work. If you take on ten things and finish eight and don’t start – or barely start – two others, Scrum is informing you about the team’s capacity. Take on eight next time.

!! We try to take on the right amount of work, but our manager pushes us to take on more. Then we don’t get it all done and get hassled because we “promised”.

I’m almost sure I said “the Dev Team figures out how many to do”. Scrum doesn’t want the Product Owner or manager demanding things that can’t be accomplished. That’s not good management and not good planning.

!! We get pressure to take on more and more. We get things done but the code isn’t good and there are bugs coming back. The more we work, the slower we go.

There’s that “Dev Team figures out how many to do” and “completed Product Increment” stuff again. Scrum people talk about a “Definition of Done”. The DoD states the team’s common understanding of when to call a backlog item “done”. Typically this means, at least, that it’s well-tested, contains no known defects, and is well-crafted. If bugs are coming back, that might suggest that the code isn’t well tested. If you’re slowing down, the code is not well-designed. Do the work right so you don’t have to do it over.