3 ms·

A daily SCRUM standup is often described as answering three questions: "What I did yesterday, what I will do today, what impedes me" When I described a daily s

by geebee 7y ago

A daily SCRUM standup is often described as answering three questions: "What I did yesterday, what I will do today, what impedes me" When I described a daily standup to my father and brother, a physician and a university professor, they shuddered a bit. Many people from outside software do. I've heard this described as violent transparency, and if it seems intimidating to people on the outside, that may just mean that we, as software developers, have grown so accustomed to a fundamentally unfair work environment that we no longer question it. Similar to "interviews" that are actually whiteboard exams. Did you know that most job types don't interview this way? Again, my friends who work outside software shudder a bit when they hear about this practice. It sounds awful, because it is kind of awful. Now, in spite of my stated belief that it is awful, I did explain (or at least tried to) why we do it. Software is highly unpredictable, and difficult to estimate. We pick a task, and work on it, and report on it. This, at least at first, was to me the essence of agile. Waterfall wasn't working. It is difficult and, ultimately, unproductive to try to spec out everything in advance. You have to evolve toward a solution, through repeated iteration and constant communication. Not a bad idea. Here's the problem - agile turned out to be a particularly insidious version of waterfall. The point of all this "violent transparency" was that we embraced the essential futility of estimates. We make them at as granular a level as we can get away with, but what we are really doing is reporting in every day on how things are going, and embracing the fundamentally uncertain nature of what we do. Well, these standups turned out to be an irresistible opportunity for micromanagement and a daily application of pressure deadlines. I view agile as the Nitroglycerine of the software development methodologies. At some point, you can't keep saying "it would be safe if they'd just use it more carefully." The inherent instability of nitroglycerin is the flaw. And agile is just too damn unstable. Any dev who things the customer (could be a project manager, a boss, a stakeholder from a different department) is going to "collaborate" if the spec isn't met by the deadline is just shaking a big bottle of nitroglycerine. And at this point, the daily "standup" will be a person patiently waiting for the developer to finish making excuses (which is what these three questions will be interpreted to be), followed by "so are you going to make your new deadline, or will this be pushed back even further). In many ways, if hard deadlines are involved, I prefer standard old waterfall. The original agile manifesto says "customer collaboration over contract negotiation". Indeed! Sounds great. Let's work together with trust, rather than lawyering up at every occasion. Here's the thing - if you're committing to a deadline but the customer (who is often internal, with "litigation" being complaints to the bosses), doesn't commit to a spec, well, your customer is protected by a contract, but you, the dev, are completely exposed. Yes, change is common and must be embraced. If you'd like to change the contract, I'm all ears, but that will require - yes - a renegotiation of the contract, including the deadlines. Otherwise, the agile manifesto, almost seems like it encourages software developers to be pacifists in the middle of a war zone. Look, if a customer is going to hold my feet to the fire on a deadline, I am going to hold the customer to the original spec. Personally, I got out, found a job in software development where deadlines aren't a big part of what I do. Not sure if everyone can get a job like this, but it seems product oriented companies are more likely to work this way than contracted development projects. Deadlines under conditions of uncertainty are a pretty hellacious source of stress for me, feels like a kind of roulette, and while agile in theory had the promise of making it better, the methodology turned out to be nitroglycerine.

brianpgordon 7y ago
Your point about deadlines gets to the heart of the issue I think. Scrum and agile are flawed in many ways, but generally you can bend the methodology to at least mitigate the issues. The one totally unsolvable existential problem, though, is the impedance mismatch between a team trying to be agile and a customer who's almost invariably not. The idea that your team can work on an open-ended basis with the customer to add functionality a piece at a time and dynamically adjust expectations as you gradually pin down the requirements and get a better idea of how much work they'll take, is, unfortunately, a fantasy. Somewhere up the chain, someone is going to want to know how much it's going to cost to get the features they want. The very best you can hope for is to estimate (ha ha) how long the milestone/project will take and then attempt to conduct scrum within that time box. But it's farcical and demoralizing because you end up structuring your sprints with what you know you need to get done instead of just what you think you can reasonably get done. The "agile" nature of it fractures the very first time you get behind your guesstimated schedule. I think the process could work if you win the lottery with a customer who's actually enthusiastic about embracing the uncertainty of agile, or if you work in a type of org that sets its own release schedule. But unfortunately I think those situations are rare and for most of us the fundamental mismatch between agile developers and non-agile stakeholders kill the whole idea.
DharmaPolice 7y ago
>we, as software developers, have grown so accustomed to a fundamentally unfair work environment that we no longer question it. Compared to a physician or a university professor a software developer might have a low level of autonomy (in the sense of free from being micromanaged) but developers do better than the vast majority of employees I suspect. Having to account for your time every day in a standup can get psychologically tiring but there's so many other jobs where it's much worse. I've worked in places where being out of your seat for more than a few minutes (when not on a break) would invite commentary or provoke questions. (This isn't intended to sound like a "You should be grateful because there is a kid starving in Africa" thing, just trying to provide a perspective why I find it hard to feel hard done when so many more people have it worse than me all around me. This doesn't mean we shouldn't all enjoy more autonomy and agency in our work.)

by geebee 7y ago

brianpgordon 7y ago

Your point about deadlines gets to the heart of the issue I think. Scrum and agile are flawed in many ways, but generally you can bend the methodology to at least mitigate the issues. The one totally unsolvable existential problem, though, is the impedance mismatch between a team trying to be agile and a customer who's almost invariably not. The idea that your team can work on an open-ended basis with the customer to add functionality a piece at a time and dynamically adjust expectations as you gradually pin down the requirements and get a better idea of how much work they'll take, is, unfortunately, a fantasy. Somewhere up the chain, someone is going to want to know how much it's going to cost to get the features they want. The very best you can hope for is to estimate (ha ha) how long the milestone/project will take and then attempt to conduct scrum within that time box. But it's farcical and demoralizing because you end up structuring your sprints with what you know you need to get done instead of just what you think you can reasonably get done. The "agile" nature of it fractures the very first time you get behind your guesstimated schedule. I think the process could work if you win the lottery with a customer who's actually enthusiastic about embracing the uncertainty of agile, or if you work in a type of org that sets its own release schedule. But unfortunately I think those situations are rare and for most of us the fundamental mismatch between agile developers and non-agile stakeholders kill the whole idea.

DharmaPolice 7y ago

>we, as software developers, have grown so accustomed to a fundamentally unfair work environment that we no longer question it. Compared to a physician or a university professor a software developer might have a low level of autonomy (in the sense of free from being micromanaged) but developers do better than the vast majority of employees I suspect. Having to account for your time every day in a standup can get psychologically tiring but there's so many other jobs where it's much worse. I've worked in places where being out of your seat for more than a few minutes (when not on a break) would invite commentary or provoke questions. (This isn't intended to sound like a "You should be grateful because there is a kid starving in Africa" thing, just trying to provide a perspective why I find it hard to feel hard done when so many more people have it worse than me all around me. This doesn't mean we shouldn't all enjoy more autonomy and agency in our work.)