Organizational debt tends to be incredibly hard to clear out. For one thing, you can’t do anything about it unless you’re in charge. You have to be at or near the top to have any effect. Further, while the CEO theoretically has access to the whole company, most people are afraid or unlikely to give the whole picture with regard to what they know.
The people who feel the pain of organizational debt generally have the least power and are least inclined to speak up.
With technical debt, there’s at least a hope of acknowledging that it exists. Prioritizing and delegating the process of fixing it– especially the unglamorous parts– is a tough game to play, but at least there are objective metrics. With org debt, you almost invariably have people who benefit from the suboptimal arrangement, who have quite a bit of power, and will guard it. This may be a coarse simplification but “The problem has its act together”.
One of the worst bad-faith argument tactics is phony existential risk: taking an issue to the CEO and presenting it as a company-killer (e.g. “we won’t be able to scale, and our competitors will humiliate us, unless we use <pet NoSQL invented in 2013>”). And one of the worst org-debt patterns is the glamorized emergency (or the permanent emergency mode called “Agile” or “Scrum”, a management philosophy that dishonestly promotes crunch-time behaviors and “sprinting” as sustainable). Emergencies concentrate power by necessity, but those who’ve been temporarily empowered by them rarely want to give that power up in peace time.
I work at an organization that uses Agile, and I don’t find the atmosphere to be emergency-like. Maybe we only say we use Agile but are actually using our own modification of it, but could you elaborate on what you dislike about it?
(BTW, I do know we break with agile in regards to stand-up meetings: though we call them stand-ups, we actually sit at them.)
Here’s a Quora post that I wrote on the topic. I should probably make it into a blog post so it’s not behind a login-wall. My takedown of Agile and Scrum.
Jasmine Adamson and Russell Wark’s answers are also great.
The TL;DR: “Agile” is toxic micromanagement, packaged and re-sold as something new and innovative. The structure it creates is detrimental and insulting to senior developers and useless for juniors (who need to be mentored, not controlled).
That was a very interesting post, but I’d have to disagree with your overall assessment of scrum/Agile. I’ve worked in corporate software development for the past 4 years, doing scrum all of that time. What I’ve found is that the experience of working on a scrum team can vary wildly depending on the people involved.
I’ve been on teams that had the dysfunctions you described, but I’ve also been on teams (like my current one) that functioned extremely well. The difference wasn’t the official practices, but whether every individual felt like they had the freedom to do what they thought was best (as long as they informed others).
My current team consists of four senior developers, one senior QA, and one product manager. We get a serious amount of work done while working at a sustainable pace and maintaining good engineering quality.
All that said, I’ve been encouraging switching more towards Lean/Kanban style than Scrum, since I think it fits the problem better.
Organizational debt tends to be incredibly hard to clear out. For one thing, you can’t do anything about it unless you’re in charge. You have to be at or near the top to have any effect. Further, while the CEO theoretically has access to the whole company, most people are afraid or unlikely to give the whole picture with regard to what they know.
The people who feel the pain of organizational debt generally have the least power and are least inclined to speak up.
With technical debt, there’s at least a hope of acknowledging that it exists. Prioritizing and delegating the process of fixing it– especially the unglamorous parts– is a tough game to play, but at least there are objective metrics. With org debt, you almost invariably have people who benefit from the suboptimal arrangement, who have quite a bit of power, and will guard it. This may be a coarse simplification but “The problem has its act together”.
One of the worst bad-faith argument tactics is phony existential risk: taking an issue to the CEO and presenting it as a company-killer (e.g. “we won’t be able to scale, and our competitors will humiliate us, unless we use <pet NoSQL invented in 2013>”). And one of the worst org-debt patterns is the glamorized emergency (or the permanent emergency mode called “Agile” or “Scrum”, a management philosophy that dishonestly promotes crunch-time behaviors and “sprinting” as sustainable). Emergencies concentrate power by necessity, but those who’ve been temporarily empowered by them rarely want to give that power up in peace time.
I work at an organization that uses Agile, and I don’t find the atmosphere to be emergency-like. Maybe we only say we use Agile but are actually using our own modification of it, but could you elaborate on what you dislike about it?
(BTW, I do know we break with agile in regards to stand-up meetings: though we call them stand-ups, we actually sit at them.)
Here’s a Quora post that I wrote on the topic. I should probably make it into a blog post so it’s not behind a login-wall. My takedown of Agile and Scrum.
Jasmine Adamson and Russell Wark’s answers are also great.
The TL;DR: “Agile” is toxic micromanagement, packaged and re-sold as something new and innovative. The structure it creates is detrimental and insulting to senior developers and useless for juniors (who need to be mentored, not controlled).
That was a very interesting post, but I’d have to disagree with your overall assessment of scrum/Agile. I’ve worked in corporate software development for the past 4 years, doing scrum all of that time. What I’ve found is that the experience of working on a scrum team can vary wildly depending on the people involved.
I’ve been on teams that had the dysfunctions you described, but I’ve also been on teams (like my current one) that functioned extremely well. The difference wasn’t the official practices, but whether every individual felt like they had the freedom to do what they thought was best (as long as they informed others).
My current team consists of four senior developers, one senior QA, and one product manager. We get a serious amount of work done while working at a sustainable pace and maintaining good engineering quality.
All that said, I’ve been encouraging switching more towards Lean/Kanban style than Scrum, since I think it fits the problem better.