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.
> 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.
> 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.
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.
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.
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.
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...
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 ...
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...
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)
I've experienced level 0 and level -1 organizations. This is an only-serious approach to trying to understand dysfunction, and I like it quite a bit.
Managers, product owners, and marketers need to understand how computers work. There's no alternative anymore; folks are savvy enough that snake-oil products with questionable business value are not having the market penetration that they used to. The days of being able to simply mail a CD to folks are long past.
I've worked at both level -1 and level -3 organizations. -3 is usually doomed because the organization is actively self-sabotaging and the money is going to run out quickly unless management identifies the toxic actors and gets rid of them. And that rarely seems to happen.
I thought this was a silly joke at first, but it's actually sort-of an attempt to capture actual organizational anti-patterns. I mean at some level assigning an "immaturity level" is silly. However, characterizing various pathologies of bad organizations is helpful.
I think I've actually worked in organizations that were at level -3. Sometimes this was a reasonable goal taken to an absurd extreme. For example, a reasonable Software Quality Engineering organization's goal would be to find as many bugs as possible in the software product, or in short, to try to "break" the product. Taken to an extreme, the ability of an SQE organization to exaggerate any concern about quality to such an extent that it manages to stop the shipment of the product because of quality concerns, can be construed as a success for that SQE organization. In the case I'm thinking of, the SQE org was basically obstructionist, because they got rewarded for that. It was amazing that we managed ever to ship anything.
20 comments
[ 4.3 ms ] story [ 51.9 ms ] threadIf 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.
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.
True... I wasn't clear about that, but I was including it as another of these extrinsic goals.
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.
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.
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]
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...
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 ...
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...
Is there any way to manage bad engineers that does not end in comically disastrous results?
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)
Managers, product owners, and marketers need to understand how computers work. There's no alternative anymore; folks are savvy enough that snake-oil products with questionable business value are not having the market penetration that they used to. The days of being able to simply mail a CD to folks are long past.
I think I've actually worked in organizations that were at level -3. Sometimes this was a reasonable goal taken to an absurd extreme. For example, a reasonable Software Quality Engineering organization's goal would be to find as many bugs as possible in the software product, or in short, to try to "break" the product. Taken to an extreme, the ability of an SQE organization to exaggerate any concern about quality to such an extent that it manages to stop the shipment of the product because of quality concerns, can be construed as a success for that SQE organization. In the case I'm thinking of, the SQE org was basically obstructionist, because they got rewarded for that. It was amazing that we managed ever to ship anything.