Process purists and productivity · Picky about methodology

Re­cent­ly, I found an old ques­tion from 2011 on Pro­gram­mers.SE. The orig­i­nal poster ex­plained a prob­lem his team has when us­ing Scrum, and asked for ad­vice. From his ques­tion, it also ap­peared that he's not ac­tu­al­ly us­ing Scrum, but rather Scrum­fall.

The very first com­ment start­ed by: "Sor­ry you've done it wrong.", ex­plain­ing then why the orig­i­nal poster is do­ing it wrong. Lat­er, maple_shaft added:

Go­ing through your his­to­ry of Scrum re­lat­ed ques­tions on this site, it is clear that your com­pa­ny is do­ing "no such thing" as Scrum and in­stead sound like a team of peo­ple much more com­fort­able and fa­mil­iar with Wa­ter­fall de­vel­op­ment.

Then, I was sur­prised to read the com­ment of Karl Biele­feldt:

It's scrum process purists like you guys that turn peo­ple off from it. If he didn't rec­og­nize he had a prob­lem, he wouldn't have asked the ques­tion. Fig­ur­ing out where you went wrong and tak­ing steps to do bet­ter in fu­ture it­er­a­tions is what ag­ile is all about. In­di­vid­u­als and in­ter­ac­tions over process­es and tools.

Is it?

I'm not call­ing the first two com­menters purists. There is noth­ing about purism in their com­ments. Their com­ments are about un­der­stand­ing the ba­sics of a process, some­thing the orig­i­nal poster seems to be miss­ing.

On the oth­er hand, forc­ing peo­ple to learn a method­ol­o­gy may in­deed turn them off from it.

But still...

In Dil­bertesque com­pa­nies, it hap­pens this way:

1. Some­body reads about Scrum in a mag­a­zine. It looks promiss­ing, so the per­son con­vinces oth­ers that Scrum is now the an­swer to all their prob­lems: late pro­jects, crush­ing num­ber of bugs, cus­tomer dis­sat­is­fac­tion, etc.

2. Since no­body cares about the de­tails and no­body want to be la­beled purist, the team starts to use some as­pects of Scrum they un­der­stand, the as­pects which are close enough to their cur­rent work­flow (or the lack of it).

3. They are call­ing now them­selves a Scrum team. It should be ob­vi­ous for every­one that they work bet­ter than the oth­ers, be­cause they have the method­ol­o­gy, the right one, the one every re­spectable team uses. Since man­age­ment loves buzz­words and since the team con­vinces the man­age­ment that now, every­thing will be dif­fer­ent, ex­pec­ta­tions rise.

4. Months pass, and noth­ing changes. The last pro­ject is late, as usu­al. QA found hun­dreds of bugs. Man­age­ment search­es for peo­ple to blame for the fail­ure.

5. The team adapts a de­fen­sive po­si­tion. “Frankly, we don't un­der­stand ei­ther. We used Scrum, so it should work, but it looks like this process is not suit­ed for our com­pa­ny.”

6. The team even­tu­al­ly ad­mits that Scrum sucks, and that peo­ple who in­vent­ed Scrum and Ag­ile know noth­ing about real life of a soft­ware pro­ject. From this mo­ment, it be­comes ex­treme­ly dif­fi­cult for a new per­son to con­vince the team to use Ag­ile. “Nah, we al­ready used it, and got very neg­a­tive re­sults; don't waste your time for it.”

What turns peo­ple off from process­es or method­olo­gies is ex­act­ly that: the fact that they tried some­thing with­out know­ing any­thing about it and with­out un­der­stand­ing the ba­sics, they ob­vi­ous­ly failed, and con­sid­ered they failed be­cause the process or method­ol­o­gy is ei­ther sim­ply wrong, or just doesn't ap­ply to them.

The “doesn't ap­ply to us”, by the way, is much more com­mon than it should be. I don't know whether it comes from the fact that teams want to think they are spe­cial or be­cause they con­sid­er them­selves dis­ad­van­taged. For ex­am­ple, it is not un­usu­al for de­vel­op­ers in France to re­ject process­es and method­olo­gies with a pre­text that “we are not in USA”. I was un­able so far to make them ex­plain why are they con­sid­er­ing them­selves in­fe­ri­or to amer­i­can de­vel­op­ers. But I di­gress.

It is es­sen­tial to un­der­stand that a bad­ly un­der­stood process brings noth­ing but ad­di­tion­al is­sues to a team. Both Scrum­fall and Scrum­butt have neg­a­tive con­se­quences; in the best case, those con­se­quences are in­signif­i­cant and are bare­ly no­tice­able, but I've nev­er seen a pro­ject which ben­e­fit­ed from Scrum­fall or Scrum­butt. There­fore, we (con­sul­tants, blog writ­ers, book writ­ers, speak­ers, mem­bers of Pro­gram­mers.SE com­mu­ni­ty) should pre­vent de­vel­op­ers from us­ing some­thing they not un­der­stand at a ba­sic lev­el.

This means that when­ev­er a per­son asks a spe­cif­ic ques­tion about one as­pect of Scrum while show­ing that he doesn't un­der­stand Scrum, the only valid an­swer should be: “Lis­ten, dude, you don't un­der­stand the ba­sics; let's me ex­plain them first, and maybe then we'll talk about the de­tails lat­er.”

If it turns the per­son off from Scrum, so be it. At least, this per­son wouldn't blame Scrum for be­ing the cause of a failed pro­ject.

To avoid be­ing an ac­tu­al pain in the ass purist, I use the fol­low­ing grad­u­a­tion:

1. At the very bot­tom, there are the ba­sics, the fun­da­men­tals of a process or a method­ol­o­gy. With­out those fun­da­men­tals, the process doesn't ex­ist per se, or should be called dif­fer­ent­ly.

   De­liv­er­ing work­ing soft­ware at the end of an it­er­a­tion is fun­da­men­tal for Scrum. Don't talk about Scrum if you was un­able to de­liv­er any­thing for the last eight months.

   Hav­ing short it­er­a­tions is fun­da­men­tal for any Ag­ile process. Six months it­er­a­tion is the plain old Wa­ter­fall. There is noth­ing Ag­ile in it, un­less you're a tur­tle.

   Writ­ing tests be­fore writ­ing code is fun­da­men­tal for Ex­treme Pro­gram­ming. If your team is ful­ly Ag­ile but writes code, then tests, that's great, but don't tell to peo­ple that you're us­ing Ex­treme Pro­gram­ming.

2. Then, there is the ter­mi­nol­o­gy. It is an­noy­ing to speak to a per­son who doesn't know ex­act­ly what is the dif­fer­ence be­tween prod­uct back­log and sprint back­log or what groom­ing is.

   Here, I'm not sure if we should be picky. It will prob­a­bly be OK to cor­rect the per­son from time to time when he uses wrong terms, but with­out be­ing par­tic­u­lar­ly dis­ci­pli­nar­i­an: the per­son just needs time to fa­mil­iar­ize him­self with the terms.

3. Then, there are im­por­tant things which grav­i­tate around this core. Those are im­por­tant things, but one may ad­just the process to bet­ter suit the par­tic­u­lar needs of a team, and even­tu­al­ly de­cide to skip them.

   I would com­pare this with what code smells. When there is a 100-LOC func­tion pop­ping in my face dur­ing a code re­view, this is ob­vi­ous­ly a code smell, but it doesn't mean that there is some­thing wrong. It may as well be a per­fect­ly valid func­tion which is par­tic­u­lar­ly read­able and main­tain­able as it is now.

   What are those process smells?

   For ex­am­ple, a team may de­cide that their dai­ly Scrum meet­ing will be 45 min­utes in­stead of 15 min­utes. That's a weird thing, but there may be good rea­sons for that.

   An­oth­er team may de­cide that chick­ens are al­lowed to speak at any meet­ing. Weird again, but if it im­proves trans­paren­cy and com­mu­ni­ca­tion and if the team is able to keep the meet­ings short de­spite the fact that any­one can talk, I don't see any­thing wrong with it.

4. Fi­nal­ly, there are all those things which may some­times be used to­geth­er with a process, but which are still a dis­tinct beast. For ex­am­ple, it is not un­usu­al for Ag­ile teams to use Con­tin­u­ous in­te­gra­tion, but there is noth­ing wrong in not us­ing CI in an Ag­ile pro­ject.

   I com­pared the pre­vi­ous point with code smells; this one is clos­er to habits. .NET de­vel­op­ment for Win­dows rimes with Vi­su­al Stu­dio; every .NET de­vel­op­er I know uses Vi­su­al Stu­dio. This be­ing said, if a de­vel­op­er writes C# code un­der Win­dows in a com­plete­ly dif­fer­ent ed­i­tor, it's not a bad sign; it's not a sign at all.

Giv­en this clas­si­fi­ca­tion:

• If the per­son doesn't know the ba­sics, ex­plain it to him be­fore an­swer­ing any ques­tion.

• If the per­son doesn't know the ter­mi­nol­o­gy, cor­rect him gen­tly, and wait for him to as­sim­i­late the terms.

• If the per­son has a strange vari­ant of an as­pect which is not at the core of the process, ask him for clar­i­fi­ca­tion.

• Fi­nal­ly, be care­ful to make the dif­fer­ence be­tween your habits and the process it­self: what may seem com­mon sense for you is not com­mon sense for every­body else.