5 ms·

Level -1 reminds me some companies I've known, except s/CMM/scrum/g, which leads me to a theory[1] about scrum that's formed in my mind that I haven't heard art

Level -1 reminds me some companies I've known, except s/CMM/scrum/g, which leads me to a theory[1] about scrum that's formed in my mind that I haven't heard articulated elsewhere -- I'd be curious to hear reactions: If you're an intrinsically motivated software professional, you're likely motivated by a number of different factors: creating a great product, love of solving problems, writing elegant code, the fun of building new things, making users happy, etc... (exact levels those matter vary by person.) You're probably not intrinsically motivated by things like hitting sprint goals, achieving a certain velocity, meeting OKRs, etc... (Did you enroll in CS classes thinking "I'm so looking forward to hitting sprint targets!"?) Thus, all of these tend to amount to various forms of extrinsic motivation. A problem with scrum, IMHO, is that it places these extrinsic factors front and center. Yes, the other things may still matter, but the stuff you focus on and talk about week after week are the various scrum related ephemera. (One may include OKRs, which you may not discuss as often but which may represent another extrinsic factor looming in the background.) There's some evidence to suggest that extrinsic motivation may dampen one's intrinsic motivation, and so a pet theory of mine is that, to the extent scrum does that, it has a certain deflationary effect on the overall morale of an engineering organization. It might be subtle, depending on the particular org and how scrum is implemented[2]. I didn't even notice it until I went to a place that didn't use scrum. [1] I'm not strongly committed to this idea. It's just something rolling around my brain. [2] Obviously, some orgs are better than others. I'm open to the idea that the above is more a reflection of "scrum done badly" than scrum itself.

dragonwriter 7y ago
> A problem with scrum, IMHO, is that it places these extrinsic factors front and center OKRs are orthogonal to Scrum, Velocity is a measure that doesn't have specific targets in Scrum but instead is used to evaluate trials of process changes so that decisions to accept or reject them aren't arbitrary and subjective; sprint goals are the only of the things you enumerate that are actual goals in Scrum. And, yes, removing them as extrinsic motivation (and, often, a source of unproductive stress and otherwise and impediment to velocity) is a motivation for more flow-based agile methods that don't use pre-planned increments. Though, your description is, definitely, what lots of organizations do when they are “doing Agile” with some bastardization of Scrum.
- msluyter 7y ago
  OKRs are orthogonal to Scrum True... I wasn't clear about that, but I was including it as another of these extrinsic goals.
commandlinefan 7y ago
> extrinsic motivation may dampen one's intrinsic motivation Software project management practices are, nearly by definition, warmed-over Taylorist management principles that worked pretty well to weed out the people in factory assembly lines who weren’t working to their peak efficiency. They’re explicitly dehumanizing, but they also don’t even make sense when you can’t even measure efficiency. The upshot is that their application creates a prison guard/prisoner mentality, so it shouldn’t be surprising when the targets start to adopt a prison-yard mentality.
swiley 7y ago
For me scrum is more about formalizing communication, motivation is always an internal thing.
rahimnathwani 7y ago
OKRs are simply a way of writing down what you're trying to achieve, and how you'll evaluate progress/success. You characterise them as an extrinsic motivator, but that's only true if you don't care about the goals. If that's the case, you're probably setting the wrong goals, but setting the wrong goals isn't inherent to OKRs.
- erikerikson 7y ago
  Any metric or goal statement is a heuristic/simplification/compression of the solution. As such, they're never perfect. They are, on the other hand, easier. Just like bike shedding, this can distract the mind and shift focus from 100% on value generation to something less. The engineers on a project need to look at and know every detail so something that tries to eliminate the details of a project can distract them from that. Please respect that this can be hard for engineers to struggle against, particularly if they are deep in a complex space of consideration. That is the frame in which you want them. Please note that I am not saying that frame is better or more right. Keeping perspective and context is also deeply important and making sure that the investment of time, attention, and energy is directed efficiently keeps the doors open and the business afloat. Most engineers deeply understand and respect this. At the same time many of us have seen tools like metrics and top level goals used like cudgels to accomplish the opposite. In a more subtle pattern, the mental frame engineers need to accomplish their task is banished by continuous pushing of the business managerial frame to a reduced productivity in the task and increased difficulty in accomplishing it. Intrinsically motivated engineers hope for better and the grandparent was expressing as much.
hinkley 7y ago
Scrum is always done badly. It gives management too much time to think and they use that time to stop developers from doing any thinking for them, by not giving them any time to think. I’ve made some pretty deep changes to ailing projects in the past and got to enjoy the fruits of that labor. On this project things were pretty bad to start. So bad that I regret turning down another offer that arrived a week after I started. It took me two years to get the project to where I’d hoped it would be Day 1. It made me feel like I was off my game. Yes, the team is quite a bit bigger than I’m used to, but this is not my first rodeo. I should be more efficient at it now, both personally and at recruiting others (an individual contributor can only cancel out so much new chaos). I’d been blaming lack of success on a health issue that has only recently been resolved. And quite a lot of my collaborators had gone to greener pastures before the worst manager left (people still behaved like he was here for almost two years). But the other difference is Scrum is already everywhere I go. Twisted by management to stop developers from thinking too hard and focused on just pumping out features. See, typically I would introduce Agile practices one at a time at either teachable moments or when nobody was looking. I’d do them one at a time and boil the frog slowly. Hell, through unspoken collusion I got a full Kanban process into a program at a very old classical Waterfall company, including WIP limits. We did not, to my recollection, utter the word "Kanban" once. We never missed a deadline by more than 10%. Each milestone we were usually the second team done. When everyone thinks they’re Agile, what they usually are is Lean. There’s not much room to romance them toward better processes, because they’re not really into improvement. The most mature team I worked on was also the first full Scrum team. I had to bring up the same issue in retro three times before any action would be taken. That’s two months of knowing about a problem before I was sanctioned to do anything about it. It was excruciating. I was so grateful when the layoffs happened. Most generous severance package I’d ever witnessed. And of course I was in the first round, I was a boat rocker. [edit: a couple words]
dreamcompiler 7y ago
A friend who is an agile advocate calls this "weaponized agile." The goal is not to produce a product, but to be able to boast "we're doing agile."
- kevstev 7y ago
  A lot of this happens when people lose sight of the goals of doing agile, and instead become focused (you might even say obsessed) with just the rituals involved- IE the daily standup, the burndown chart, etc. These also tend to be the organizations in my experience where things tend to devolve quickly- standups take an hour, hard decisions aren't made in grooming, managers will go over the previous day's major fire and then beat up people over the fact that the burndown chart hasn't moved... They get to put down on their resume that they are doing the trendy thing though...
- deleted 7y ago
  [deleted]
FZ1 7y ago
The think I don't like about scrum is that they teach that you literally don't need to know a single thing about the underlying business - in fact, that is discouraged - following the process to the letter is what counts. It is sold as a one-size-fits-everything process model, which can be run by non-programmers with zero experience who took a few workshops and got a scrum "certification". It applies to any business - now including finance, accounting, and more ... So I'd say by definition, a scrum company can achieve level -1 or 0 at best. It fits the Level 0 description PERFECTLY. An actual formalized process which could be optimized would have to be set by subject matter experts after some deliberation. And would be designed to make an impact on product and quality. Scrum can never achieve this - because the fundamental idea is that you can manage any business with the same established process - it will fix all of them ... no matter what the problem is ...
IpV8 7y ago
I think you're on to something here. I certainly value a lot of freedom and need the challenge of solving big problems myself. I get demoralized when some scrum master is breaking everything down into tiny tickets and only doling me pre-thought out bits of implementation work. Lets assume for a second that you're right and focusing on sprint targets is bad. How else can we solve the issues that Scrum solves well? Management knowing what their team is working on, Management being able to prioritize features, Not losing developers to time sinks only to surface weeks later without any significant value add. etc. etc. I've found some success with setting 2-week goals as large items. Give a good engineer clear requirements for an entire business goal that will take roughly 2 weeks to solve, and then give them huge liberties of how to implement. Though do the same for bad engineers and you'll get comically disastrous results...
- marcosdumay 7y ago
  > Though do the same for bad engineers and you'll get comically disastrous results... Is there any way to manage bad engineers that does not end in comically disastrous results?
  - IpV8 7y ago
    Hah, too true. I find giving them smaller, well defined tasks and checking in frequently helps erk some productivity out of them. Also having lots of check-ins and pair-debugging sessions opens the door for a lot of mentoring opportunities. If their still bad, send 'em to tech support or QA! (only kind-of kidding)

dragonwriter 7y ago

> A problem with scrum, IMHO, is that it places these extrinsic factors front and center OKRs are orthogonal to Scrum, Velocity is a measure that doesn't have specific targets in Scrum but instead is used to evaluate trials of process changes so that decisions to accept or reject them aren't arbitrary and subjective; sprint goals are the only of the things you enumerate that are actual goals in Scrum. And, yes, removing them as extrinsic motivation (and, often, a source of unproductive stress and otherwise and impediment to velocity) is a motivation for more flow-based agile methods that don't use pre-planned increments. Though, your description is, definitely, what lots of organizations do when they are “doing Agile” with some bastardization of Scrum.

msluyter 7y ago
OKRs are orthogonal to Scrum True... I wasn't clear about that, but I was including it as another of these extrinsic goals.

commandlinefan 7y ago

> extrinsic motivation may dampen one's intrinsic motivation Software project management practices are, nearly by definition, warmed-over Taylorist management principles that worked pretty well to weed out the people in factory assembly lines who weren’t working to their peak efficiency. They’re explicitly dehumanizing, but they also don’t even make sense when you can’t even measure efficiency. The upshot is that their application creates a prison guard/prisoner mentality, so it shouldn’t be surprising when the targets start to adopt a prison-yard mentality.

swiley 7y ago

For me scrum is more about formalizing communication, motivation is always an internal thing.

rahimnathwani 7y ago

OKRs are simply a way of writing down what you're trying to achieve, and how you'll evaluate progress/success. You characterise them as an extrinsic motivator, but that's only true if you don't care about the goals. If that's the case, you're probably setting the wrong goals, but setting the wrong goals isn't inherent to OKRs.

erikerikson 7y ago
Any metric or goal statement is a heuristic/simplification/compression of the solution. As such, they're never perfect. They are, on the other hand, easier. Just like bike shedding, this can distract the mind and shift focus from 100% on value generation to something less. The engineers on a project need to look at and know every detail so something that tries to eliminate the details of a project can distract them from that. Please respect that this can be hard for engineers to struggle against, particularly if they are deep in a complex space of consideration. That is the frame in which you want them. Please note that I am not saying that frame is better or more right. Keeping perspective and context is also deeply important and making sure that the investment of time, attention, and energy is directed efficiently keeps the doors open and the business afloat. Most engineers deeply understand and respect this. At the same time many of us have seen tools like metrics and top level goals used like cudgels to accomplish the opposite. In a more subtle pattern, the mental frame engineers need to accomplish their task is banished by continuous pushing of the business managerial frame to a reduced productivity in the task and increased difficulty in accomplishing it. Intrinsically motivated engineers hope for better and the grandparent was expressing as much.

hinkley 7y ago

Scrum is always done badly. It gives management too much time to think and they use that time to stop developers from doing any thinking for them, by not giving them any time to think. I’ve made some pretty deep changes to ailing projects in the past and got to enjoy the fruits of that labor. On this project things were pretty bad to start. So bad that I regret turning down another offer that arrived a week after I started. It took me two years to get the project to where I’d hoped it would be Day 1. It made me feel like I was off my game. Yes, the team is quite a bit bigger than I’m used to, but this is not my first rodeo. I should be more efficient at it now, both personally and at recruiting others (an individual contributor can only cancel out so much new chaos). I’d been blaming lack of success on a health issue that has only recently been resolved. And quite a lot of my collaborators had gone to greener pastures before the worst manager left (people still behaved like he was here for almost two years). But the other difference is Scrum is already everywhere I go. Twisted by management to stop developers from thinking too hard and focused on just pumping out features. See, typically I would introduce Agile practices one at a time at either teachable moments or when nobody was looking. I’d do them one at a time and boil the frog slowly. Hell, through unspoken collusion I got a full Kanban process into a program at a very old classical Waterfall company, including WIP limits. We did not, to my recollection, utter the word "Kanban" once. We never missed a deadline by more than 10%. Each milestone we were usually the second team done. When everyone thinks they’re Agile, what they usually are is Lean. There’s not much room to romance them toward better processes, because they’re not really into improvement. The most mature team I worked on was also the first full Scrum team. I had to bring up the same issue in retro three times before any action would be taken. That’s two months of knowing about a problem before I was sanctioned to do anything about it. It was excruciating. I was so grateful when the layoffs happened. Most generous severance package I’d ever witnessed. And of course I was in the first round, I was a boat rocker. [edit: a couple words]

dreamcompiler 7y ago

A friend who is an agile advocate calls this "weaponized agile." The goal is not to produce a product, but to be able to boast "we're doing agile."

kevstev 7y ago
A lot of this happens when people lose sight of the goals of doing agile, and instead become focused (you might even say obsessed) with just the rituals involved- IE the daily standup, the burndown chart, etc. These also tend to be the organizations in my experience where things tend to devolve quickly- standups take an hour, hard decisions aren't made in grooming, managers will go over the previous day's major fire and then beat up people over the fact that the burndown chart hasn't moved... They get to put down on their resume that they are doing the trendy thing though...
deleted 7y ago
[deleted]

FZ1 7y ago

The think I don't like about scrum is that they teach that you literally don't need to know a single thing about the underlying business - in fact, that is discouraged - following the process to the letter is what counts. It is sold as a one-size-fits-everything process model, which can be run by non-programmers with zero experience who took a few workshops and got a scrum "certification". It applies to any business - now including finance, accounting, and more ... So I'd say by definition, a scrum company can achieve level -1 or 0 at best. It fits the Level 0 description PERFECTLY. An actual formalized process which could be optimized would have to be set by subject matter experts after some deliberation. And would be designed to make an impact on product and quality. Scrum can never achieve this - because the fundamental idea is that you can manage any business with the same established process - it will fix all of them ... no matter what the problem is ...

IpV8 7y ago

I think you're on to something here. I certainly value a lot of freedom and need the challenge of solving big problems myself. I get demoralized when some scrum master is breaking everything down into tiny tickets and only doling me pre-thought out bits of implementation work. Lets assume for a second that you're right and focusing on sprint targets is bad. How else can we solve the issues that Scrum solves well? Management knowing what their team is working on, Management being able to prioritize features, Not losing developers to time sinks only to surface weeks later without any significant value add. etc. etc. I've found some success with setting 2-week goals as large items. Give a good engineer clear requirements for an entire business goal that will take roughly 2 weeks to solve, and then give them huge liberties of how to implement. Though do the same for bad engineers and you'll get comically disastrous results...

marcosdumay 7y ago
> Though do the same for bad engineers and you'll get comically disastrous results... Is there any way to manage bad engineers that does not end in comically disastrous results?
- IpV8 7y ago
  Hah, too true. I find giving them smaller, well defined tasks and checking in frequently helps erk some productivity out of them. Also having lots of check-ins and pair-debugging sessions opens the door for a lot of mentoring opportunities. If their still bad, send 'em to tech support or QA! (only kind-of kidding)