I’m living in a corporate agile environment. I read another rant recently that had one point that I really identified with. In tired if being the squeaky wheel thats always having to complain about broken things that will (and have) bitten us in the ass in the long-term. It can make me feel like a shitty person having to bring up architectural issues over and over again.
From this posting, what stuck with me was the whole anti-engineering point. It’s true, we are devaluing intellectualism and thought. Sometimes it’s good to spend a week or so thinking about a problem. This is what engineering is all about. I did not get into programming to be a sweat shop worker spending all my time refactoring code that wasn’t designed in order to add minor feature B worth 3 points.
It’s well known that creative people lose their creativity if asked to explain themselves while they are working
Not well-known to me :) I guess it makes intuitive sense. But I’d like to hear more about this bit. Anyone know the sources or references for this factoid?
Author of the linked essay. I’ll look for those studies.
One of the more interesting paradoxes here is that the best way to learn something is to teach it to someone else. And, of course, mathematics is a field where every claim requires formal justification (meaning, proof) and the field doesn’t suffer for that. It’s how math works: something isn’t accepted as true unless it’s rigorously proven.
So it may be that there’s a social status effect. Ask your employees to justify time, and they become less capable, because you’re putting them in a low-status context. The brain tends to shut down in low-status mode, for the sake of survival (don’t think, just get through this). On the other hand, teaching is a high-status context, so people who are teaching a subject are going to learn it very well.
I can back it up with logic instead of just studies. I’m an introspective person who works at such an organization that routinely forces employees to justify their activities. So, I noticed the problem early on. Let’s look at it from a business role perspective. You have an engineer working in isolation on a set of work with occasional interactions necessary to get it, update people on progress, and eventually turn it in. You have a salesperson or customer-facing role who spends time considering questions/objections people will have, devising answers to them, tracking progress of engineering work vs customers' expectations, and interacting with customers. A company that challenges its own engineers repeatedly to prove value of their work is forcing them to do both jobs I just described. They have to do sales and damage control on their own work for the management. It’s enough extra effort it’s usually a separate job in the company at the customer level but these fools think engineers can do same thing with zero cost? Ha!
In the example at my company, we’re not thinking about the job we’re doing. We’re considering what management will say at each stage: how concept sounds; whether we’re executing on it efficiently; whether we look like we’re busy enough. It’s impossible to extract full productivity of the mind if it’s focused on something other than the task at hand. That’s a lot of other stuff to consider while trying to do a job. So, logically, this management style wastes workers mental effort. Uncertainty, scrutiny, and personal attacks combined also stress a lot of people out by default. So, they’re likely to be wasting effort and stressed. Really undermines creativity.
I wrote the linked essay.
There are many cases where I wrote something and my views moderated. I used to evangelize open allocation. I still think that it’s an ideal for a creative workplace environment, but I’ve grown older and recognized that it’s not always practical. You couldn’t have an open allocation trading floor.
My views on Scrum have not moderated. If anything, I’m more convinced that I was right the whole time. Pro-Scrum engineers tend to have a mistaken view that it provides real protection against management. If it did, it might have value. A prioritized backlog does help to introduce sanity. In terms of providing protection from management, it doesn’t. You can’t actually say to a manager, “We’re not doing this because our process precludes it.” I’m sure that Scrum has caused more people to get fired than it has prevented firings. Of course, what we’ve seen in software in the past 5 years is that management has co-opted Agile and Scrum as excuses for micromanagement and brutality.
All of this said, I don’t that killing Scrum will solve the core problems: business-driven engineering, low status for programmers, and the flooding of the labor market with unskilled replacement programmers (due to the proliferation of boot camps, and abuse of the H1-B program) who will work cheaply and take abuse. Like all fads, it will die at some point. As for the cultural change that it represents, I’m not as sure. Programming is one bad turn away from reverting to the status of being just another shitty office job. Winter is coming, and it’s time to start planning for it, and I think that many people who are strong enough to get out of the technology industry will do so.
I will say, it does depend on the environment. I’ve seen guys in our German office say exactly “We’re not doing this because our process precludes it.”, and amazingly, it worked. “Sorry, we’re not taking this task because it is not well-defined or prioritized in our backlog.” The problem is it requires huge management and upper-management buy-in, which is very very hard to do, and especially hard to do in countries where workers rights are not a fundamental part of your environment. But in my experience, when you get it right, I enjoy SCRUM.
I’m curious about your perspective on ‘business-driven engineering’. I have always thought that engineering is naturally a function of business. I’ve felt that engineering is there to serve the interests of the business level. Often times at small companies engineers who have solid business skills can do both jobs, but the split is still there.
What does engineering independent of business concerns look like to you?
[Comment removed by author]
The hub-and-spoke office seems like a good idea. What you want is a mixture of spaces. You want open spaces for when people choose to use them, and you want private or semi-private offices where the doors are usually open but sometimes closed.
Really? Another one of these. Come on. My team uses SCRUM and it works great for us. It’s not going to work for everyone, and SCRUM and especially Agile are not just one thing. Different teams/companies implement it in different ways, and some of those implementations are flat out bad. So yeah those people are going to have bad results.