Home Home

Process purists and productivity · Picky about methodology

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
May 5, 2014

Recently, I found an old question from 2011 on Programmers.SE. The original poster explained a problem his team has when using Scrum, and asked for advice. From his question, it also appeared that he's not actually using Scrum, but rather Scrumfall.

The very first comment started by: "Sorry you've done it wrong.", explaining then why the original poster is doing it wrong. Later, maple_shaft added:

Going through your history of Scrum related questions on this site, it is clear that your company is doing "no such thing" as Scrum and instead sound like a team of people much more comfortable and familiar with Waterfall development.

Then, I was surprised to read the comment of Karl Bielefeldt:

It's scrum process purists like you guys that turn people off from it. If he didn't recognize he had a problem, he wouldn't have asked the question. Figuring out where you went wrong and taking steps to do better in future iterations is what agile is all about. Individuals and interactions over processes and tools.

Is it?

I'm not calling the first two commenters purists. There is nothing about purism in their comments. Their comments are about understanding the basics of a process, something the original poster seems to be missing.

On the other hand, forcing people to learn a methodology may indeed turn them off from it.

But still...

In Dilbertesque companies, it happens this way:

  1. Somebody reads about Scrum in a magazine. It looks promissing, so the person convinces others that Scrum is now the answer to all their problems: late projects, crushing number of bugs, customer dissatisfaction, etc.

  2. Since nobody cares about the details and nobody want to be labeled purist, the team starts to use some aspects of Scrum they understand, the aspects which are close enough to their current workflow (or the lack of it).

  3. They are calling now themselves a Scrum team. It should be obvious for everyone that they work better than the others, because they have the methodology, the right one, the one every respectable team uses. Since management loves buzzwords and since the team convinces the management that now, everything will be different, expectations rise.

  4. Months pass, and nothing changes. The last project is late, as usual. QA found hundreds of bugs. Management searches for people to blame for the failure.

  5. The team adapts a defensive position. “Frankly, we don't understand either. We used Scrum, so it should work, but it looks like this process is not suited for our company.”

  6. The team eventually admits that Scrum sucks, and that people who invented Scrum and Agile know nothing about real life of a software project. From this moment, it becomes extremely difficult for a new person to convince the team to use Agile. “Nah, we already used it, and got very negative results; don't waste your time for it.”

What turns people off from processes or methodologies is exactly that: the fact that they tried something without knowing anything about it and without understanding the basics, they obviously failed, and considered they failed because the process or methodology is either simply wrong, or just doesn't apply to them.

The “doesn't apply to us”, by the way, is much more common than it should be. I don't know whether it comes from the fact that teams want to think they are special or because they consider themselves disadvantaged. For example, it is not unusual for developers in France to reject processes and methodologies with a pretext that “we are not in USA”. I was unable so far to make them explain why are they considering themselves inferior to american developers. But I digress.

It is essential to understand that a badly understood process brings nothing but additional issues to a team. Both Scrumfall and Scrumbutt have negative consequences; in the best case, those consequences are insignificant and are barely noticeable, but I've never seen a project which benefited from Scrumfall or Scrumbutt. Therefore, we (consultants, blog writers, book writers, speakers, members of Programmers.SE community) should prevent developers from using something they not understand at a basic level.

This means that whenever a person asks a specific question about one aspect of Scrum while showing that he doesn't understand Scrum, the only valid answer should be: “Listen, dude, you don't understand the basics; let's me explain them first, and maybe then we'll talk about the details later.”

If it turns the person off from Scrum, so be it. At least, this person wouldn't blame Scrum for being the cause of a failed project.

To avoid being an actual pain in the ass purist, I use the following graduation:

  1. At the very bottom, there are the basics, the fundamentals of a process or a methodology. Without those fundamentals, the process doesn't exist per se, or should be called differently.

    Delivering working software at the end of an iteration is fundamental for Scrum. Don't talk about Scrum if you was unable to deliver anything for the last eight months.

    Having short iterations is fundamental for any Agile process. Six months iteration is the plain old Waterfall. There is nothing Agile in it, unless you're a turtle.

    Writing tests before writing code is fundamental for Extreme Programming. If your team is fully Agile but writes code, then tests, that's great, but don't tell to people that you're using Extreme Programming.

  2. Then, there is the terminology. It is annoying to speak to a person who doesn't know exactly what is the difference between product backlog and sprint backlog or what grooming is.

    Here, I'm not sure if we should be picky. It will probably be OK to correct the person from time to time when he uses wrong terms, but without being particularly disciplinarian: the person just needs time to familiarize himself with the terms.

  3. Then, there are important things which gravitate around this core. Those are important things, but one may adjust the process to better suit the particular needs of a team, and eventually decide to skip them.

    I would compare this with what code smells. When there is a 100-LOC function popping in my face during a code review, this is obviously a code smell, but it doesn't mean that there is something wrong. It may as well be a perfectly valid function which is particularly readable and maintainable as it is now.

    What are those process smells?

    For example, a team may decide that their daily Scrum meeting will be 45 minutes instead of 15 minutes. That's a weird thing, but there may be good reasons for that.

    Another team may decide that chickens are allowed to speak at any meeting. Weird again, but if it improves transparency and communication and if the team is able to keep the meetings short despite the fact that anyone can talk, I don't see anything wrong with it.

  4. Finally, there are all those things which may sometimes be used together with a process, but which are still a distinct beast. For example, it is not unusual for Agile teams to use Continuous integration, but there is nothing wrong in not using CI in an Agile project.

    I compared the previous point with code smells; this one is closer to habits. .NET development for Windows rimes with Visual Studio; every .NET developer I know uses Visual Studio. This being said, if a developer writes C# code under Windows in a completely different editor, it's not a bad sign; it's not a sign at all.

Given this classification:

  • If the person doesn't know the basics, explain it to him before answering any question.

  • If the person doesn't know the terminology, correct him gently, and wait for him to assimilate the terms.

  • If the person has a strange variant of an aspect which is not at the core of the process, ask him for clarification.

  • Finally, be careful to make the difference between your habits and the process itself: what may seem common sense for you is not common sense for everybody else.