Sonntag, 28. Februar 2016

Unscrum me, please

O: Scrum? Yeah, we tried that once, it did not work for us
P: You must have done something wrong.

This is one of the more typical discussions between a scrum proponent and a scrum opponent that I've ever seen. If P is particularly entreched, he/she might even follow up with

P: Do you want to go back to waterfall?

At this point it is important to tell people that I am all for agile. Rapid prototyping. Continuous delivery, automated testing. Try to give the customer something to look at as early as possible and then go from there.

In comes Scrum. Scrum seems to give some teams really big productivity boosts. And it also sucks the live out of some teams, leaving them burned out and drained. And most common answer Scrum proponents have for the latter teams seems to be

You must have done something wrong.

When you have a team of experienced developers, that maybe even worked well together in the past, and expose them to Scrum and it makes them suffer, you are obviously doing something wrong.

But you also might actually be trying to fit the team to a process that they cannot and do not want to deal with. And the only answer, Scrum has is "These people need to adapt or get a new career". Processes over People, oh, wait, ...

Constant Pressure (now Social)

I did A yesterday. I'm nearly done, I will probably finish today and commit the test cases in the afternoon so that they can go into the nightly. After that I will pick up B.
I'd probably go nuts when I would have to do this five times a week in a daily standup. Hell, my typical plannable workload is in about one to two week chunks. Scrum with its constant decomposition of user stories, its lack of long term commitment to a certain area simply does not cut it for me. I think in longer chunks than the typical scrum user story and I also think in larger terms. Scrum always feels like it takes that away from me.

But that's not the problem: The problem is that I clearly have entire days where I do not get done anything productive. At least not in the terms of a task list. There are days when I am just thinking. Those days are needed, but any process with overly short timeboxes takes them away from me.

Well, for Scrum-Nuts this makes me unsuitable for a Scrum team, because you I am not a team-worker (I think I am). But to them I am not part of the collective that owns the product, I am a Lone Wolf.

Let me give you some data, from a study of the Rhein-Ruhr-Institute of Social Research (RISP). IT workers are more stressed than ever and among the top reasons they give are
  • work becomes too fine-grained and IT workers feel devalued. Employee status is reduced by limiting their influence.
  • prevalence of pseudo-freedom. IT is supposed to offer varied, creative work with self-determined time management. However, many employee do not have influence on the surrounding conditions, resource use, priorization and deadlines. Still they are held accountable for results.

But the situation is even more evil: In Scrum (and many other agile processes), pressure from the management is augmented or replaced by team pressure. "Not to let the team down" is subtle, but perverted way of pushing people past their safe zone to work more. It is weird: What was once thought as a good idea is quite often now a method to take away freedom by social pressure.

Scrum tells you that decisions are shifted away from management and (back) to the team. What --however-- also happens is that decisions are shifted away from (experienced) individuals and to the team. And I think the granularity that pure Scrum demands is just too low.

I: "I did nothing productive today. I basically stared at the wall trying to wrap my head around how to properly design a solution. We need a stable solution because future work depends on it."

Hey, I just came out of a Job interview, where one of the developers told me that it is important for him to know what his fellows are doing right now and if they are doing anything at all. It seems like they had real trouble with lazy people in the past. Now they use Scrum to put team pressure on them. How very motivating.

Scrum can cultivate something called "Checkbox culture". Developers start caring more about finishing the tasks on the task list than they do about actually building a good product. I think that is exactly because the current work environments punish enthusiasts and big thinkers.

Note that in the same interview, the department head told me that they neglected maintenance in the past somewhat. And no, from what I can tell they do have a decent architect/team lead, so they should have somebody to handle the problems. They didn't, they went checkboxing. Well, sounds to me like they have a bad case of Scrum.

No Room for Bigger Thinkers

And since I mention the topic just now, let me quote a Story:
A few years ago I had a team member who preferred to work alone and who preferred to work on very complex items. He saw these tasks as unique opportunities and challenges. He was an excellent engineer. The solutions worked and when you took a closer look they turned out to be excellent solutions. Almost beautiful. However, the person was very introverted and he wasn't able to fully leverage his potential to the rest of the team. In addition the code he created despite being excellent from an engineering perspective as too complicated for the average engineer. The solution was complex, elegant, and still hard to understand as some of the concepts were too abstract for some People.

I've heard this before. Hell, I've been in this role myself. It's the "engineer" part in you. And by pushing all decisions to the team and  continuously monitoring team progress (even if "only" by social pressure), you force us to live way beyond our capabilities. But not only that, you insult us: We are supposed to be deluded (into thinking we are great coders), Cowboys and what not. Tell you what? Scrum yourself!

It's not that we do not write readable, maintainable code. No, we take pride in solving a problem the best way we can. But the problems agile methods put in front of us do not really fit our chunk size. Instead, it seems to pressure good engineers into a working mode they are not comfortable with.

Let me tell you something: My last chunk was "Implement editor REST API serializers for all models and add appropriate test cases". There are 86 models and the API still needs to be designed. To speed up the process, I can do it in lockstep with the user interface designer (which is currently also me, but that's not the point). The whole thing takes at least about a month.

Yeah, the task is decomposable. It's five or six different submodules, split across the different pages associated with the API parts (twelve if you also split of the UI separately, but both are closely linked). This decomposition introduces a load of dependencies, so the only sane way of dealing with it is to assign at least six tasks to the same person (2 persons when we have 12 tasks) to reduce communication overhead. One the way, we might decide that its only 11 tasks, because we can include data from one page into another. It also does not make sense to have the tasks done simultaneously, as this increases the communication overhead. It is as if the task was meant for two people to be done in a row.

I figure this would drive Scrum people nuts. Decompose! No Module/Code Ownership! We pick tasks from the task list according to priority! Truck number!
Unless you do pure Scrum. If you have two week sprints, this task spans at least two sprints. The daily status report of both developers is essentially "still working on it, done with page x, y, and z, we will go on as planned". It's, however, quite easy to integrate the task into continuous delivery, because the whole think is a leaf module that does interact with the rest of the world in well defined locations.

Kai Gilb puts it very well:
Scrum is practiced as a huge cooperative todo list. By not focusing on the critical "how well" attributes of the system, Scrum is reducing sw development to tasks, not needing skillful creative knowledgeable Developers. Developers are told what to code, not asked how to best satisfy a Product Quality need.

Gabriel Steinhardt calls this the McDonaldization of the development team. It is actually a Scrum Antipattern, because teams are supposed to be cross-functional, but the implementation in many cases all but makes this happen.

Lets return back to the RISP study: Another top complaint on the list of work  stress generators is
  • Contradictory requirements and values. Employees cannot work up to their own quality standards, because of time pressure, unplanned additional work, and/or insufficient technological or organizational frameworks.

You are doing it wrong (again)

The default answer for all of these problems is: You are doing it wrong.

  • I feel exhausted by the bi-weekly need to justify myself, replan, and assert my position? You are doing it wrong! 
  • I have the feeling that I am constantly doing stuff I was told to do (by the team, by the product owner). It kills my passion, because I never get around to do things that I feel need doing. You are doing it wrong!
  • The daily scrum makes me feel uncomfortable, because I have the constant feeling that I am too slow. You are doing it wrong!
Yeah. Thank you. But the thing is: If there are so many things that can go wrong, where are my recipes to fix things when off the path? Oh wait ...

Part 2 will follow