4 ms·

My consistent observation over 30 years experience has been that there are alawys three methodologies in effect: 1. The paper methodology that everybody comple

My consistent observation over 30 years experience has been that there are alawys three methodologies in effect: 1. The paper methodology that everybody completely ignores - this is Scrum or waterfall or rational or whatever they call it 2. The management ideology that management actually insists on and bases your pay on - the ticketing system (nowadays it's JIRA, but there's always been something similar). In theory it's driven by the paper methodology but in practice it's somewhat random. 3. The support methodology that everybody follows - drop everything and work on this emergency because Somebody Important mentioned it. This is what your reputation is built around, and is always independent of the other two methodologies.

RaiausderDose 4y ago
Point 3 is very true. In my company at the time, they had a million rules and processes, but everybody had to drop everything because the son of an influential client could not get toy cars (!) into the new enterprise retail procurement system because of some incorrect logistical data. Normally you would get a ticket, analyze etc. But he was the loudest/most influential, so everything else was unimportant. No Jira, nothing, just one angry email. Fix it for him alone, NOW! Billion-dollar company, thousands of clients but a dude with 20 toy cars won. The issue was resolved (we removed the validation rules that were implemented before because "this is the filter for incorrect data, and we want to clear our data by restricting them") and everything went back to normal. Jiras, process and so on.
- commandlinefan 4y ago
  > everything else was unimportant, no Jira, nothing Well, until review time - then, "why didn't you make any progress on your Jira tickets?"
  - klodolph 4y ago
    One of the reasons why I would just open a Jira ticket anyway, process be damned. If I’m suspending work on a P1 because of this ticket, I’m gonna mark this ticket at least a P1. If management wants me to complete it within X hours, then I can find the priority level that matches the X-hour turnaround time.
    - commandlinefan 4y ago
      I usually do. I once worked for one company that was so dysfunctional that they implemented a rule that made it impossible to open a ticket and assign it to yourself to prohibit that.
    - tharkun__ 4y ago
      I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours). I don't see why. It's really not that hard in most places to create one. Even in large and bureaucratic ones. I always found that tickets are protection. When you're being asked to "drop everything for X", my first thought is to create a ticket for my own protection. At the least I can track the fact that I had to spend N hours on this thing X and I can refer back to it. At best I can document the stupidity of the whole thing w/ the ticket contents. If you're in a place like my sibling where they ban creating a ticket yourself and assigning yourself: run. That's so stupid for so many reason that it's not even funny any longer
      - klodolph 4y ago
        Yes, agreed. I think many developers have a vague understanding of how companies work and how their role fits into the company at large. I know a lot of developers who want to focus only on solving technical problems, want to be given the freedom to make technical problems, and want to have the other problems solved by everyone else. If you’re focusing on technical problems, a ticketing system is a burden imposed on you by management. If your priority is the success of your entire team rather than the success of your own technical decisions, then you’d understand that visibility of your work, your thought process, how you justify decisions, is all critical knowledge that a ticketing system serves to record and disseminate. I can’t count the number of times where I found a reference to a bug in a piece of code like: // Release gadget early to avoid starving froopy pipeline, // see bug #12345. And the ticket turned out to be super damn enlightening. You get to go back in time and relive, vicariously, a debugging session from two years ago by a team member who left the team.
        4y ago
  - makestuff 4y ago
    Then in your retro meeting the manager/TPM/etc. talks about how we need a better process which results in nothing changing apart from more tickets to create.
  - twblalock 4y ago
    In those cases you open the ticket and assign it to yourself, "for tracking purposes."
switch007 4y ago
On point 3, also you have a plethora of PMs who are insistent they are important and can bend the will of Somebody Important and definitely aren’t just relaying those “drop everything” requests and are actually a proper job of being a PM…
strangattractor 4y ago
I would also add that management often subverts the methodology by using them as a form of metrics. In my experience with Agile/Scrum they started to expect design and implementation in 2 weeks cycles which is unrealistic for large projects. This ultimately ended up in an inability to execute and complete projects that needed long term thinking and planning.
twblalock 4y ago
Development methodologies sort of work -- they don't work perfectly, but nothing really does. Most teams practice some sort of pseudo-version of methodology #1 while they do the practical work of methodology #2. That doesn't mean methodology #1 is useless. Agile/scrum really did have an impact on the industry, and the proof of that is how hard it is to find people who still advocate for the kind of waterfall methodology that was once accepted by pretty much everyone. The annoying thing about development methodologies is meeting people who don't understand that the map is not the territory and insist that a perfect application of a methodology is absolutely necessary. They drive everyone else crazy with buzzwords and process. Most people are fine with a sort-of agile process that takes reality and business value into account.
- wpietri 4y ago
  As somebody who was very involved in the Agile movement early on (2000-2008 or so), I don't think Agile deserves the credit here. What I think actually happened was that the rise of the internet made faster release cycles both possible and necessary. Scrum rode that wave, saying that they had the solution. But most Scrum implementations I've seen are not what I'd call conscious, proactive process change. It's just a new set of labels for accelerated versions of the old behaviors (waterfall or code-and-fix or a mix), plus a revenue stream for consultants and a certification scam for everybody else. I wrote more about that a long time ago, and still stand by it: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...
- computerdork 4y ago
  I completely agree with this. Yeah, it's not like they don't work at all, it's that they work to some degree. And, yeah, I think a lot of devs would agree that the traditional waterfall is not as good a process as agile. You could say that it's an antiprocess, whose basic idea is that the old inflexible waterfall with its overly structured teams is inefficient. Yes, small, tight-knit teams working closely together and iterating quickly is much more productive, creative and rewarding way to work. ... although, in my humble opinion, the one thing that agile really needs to stress more (that is key in the waterfall) is requirements. A (couple of) dedicated rounds of requirements where you talk with users (and stakeholders) saves a ton of dev time - agile does have requirements, but at least in my experience, devs seems to gloss over it.
raverbashing 4y ago
I can't complain too much about Scrum when some people take CMMI seriously (Of course those are deeply in managerial self-pleasing and probably would make a hello world project cost a million dollars, still...)
wpietri 4y ago
And I think #2 and #3 is why #1 is true. Or put differently, my experience in changing processes in many places has convinced me that unspoken management dynamics are what really matter, and that most managers will resent any process change that makes the actual management dynamics obvious. For example, one way to classify process changes is when they make problems obvious. E.g., a release-early, release-often approach makes problems visible early on. And I've had great luck with them on teams that are actually trying to succeed, because faster feedback means faster learning. But most organizations reject that because actual success doesn't matter nearly as much as managerial appearance of success. Many managers thus hate fast-feedback processes because they would rather hide negative information, even if that makes long-term success much less likely. But they like the appearance of success that comes with using the latest buzzwords. This results in the common pattern of the manager who talks Agile but whose projects are in effect waterfall. One book really helpful to me here looks at the default ideology of current management: https://www.amazon.com/Confronting-Managerialism-Business-Economic-Controversies-ebook/dp/B09LQSSM77/ref=sr_1_1?keywords=confronting+managerialism&qid=1670614278&sr=8-1 https://www.amazon.com/Confronting-Managerialism-Business-Ec...
- nradov 4y ago
  In many enterprise software markets, customers legitimately hate frequent releases. Each new release may force them to retrain employees, do their own compatibility testing with third-party systems, and possibly even go through some sort of expensive legal compliance process. It's a good discipline to always keep the main repo branch in a fully releasable state, but only push out actual releases on a slower schedule.
  - quickthrower2 4y ago
    It depends what you release. A bug fix, an extra plugin etc. is not going to disrupt the user as much ad a UI overhaul. Feature flags and great communication with customers and empathy means you can have frequent releases without annoying the customer. It should be strictly better than slow releases. You can emulate a quarterly release of 1000 changes at once if you want that. Or you could say release fixes and small feature continuously and big features are timed with the customer/training/support functions. They might even be beta/optin at first. Getting the code out fast always and then providing ways to avoid dumping confusing features on people seems better to me.
mruniverse 4y ago
Number 3 seems about right. My Vulcan brain thinks that something like number 1 must the answer, but my lizard brain knows that the food pellets drop when I follow number 3. Back in the day, our CEO's neighbor mentioned that our site didn't work well on Microsoft's WebTV. WebTV appeared on our list of supported platforms.
RandyRanderson 4y ago
Every person working in IT management should be forced to read and agree to these terms before starting work.

RaiausderDose 4y ago

Point 3 is very true. In my company at the time, they had a million rules and processes, but everybody had to drop everything because the son of an influential client could not get toy cars (!) into the new enterprise retail procurement system because of some incorrect logistical data. Normally you would get a ticket, analyze etc. But he was the loudest/most influential, so everything else was unimportant. No Jira, nothing, just one angry email. Fix it for him alone, NOW! Billion-dollar company, thousands of clients but a dude with 20 toy cars won. The issue was resolved (we removed the validation rules that were implemented before because "this is the filter for incorrect data, and we want to clear our data by restricting them") and everything went back to normal. Jiras, process and so on.

commandlinefan 4y ago
> everything else was unimportant, no Jira, nothing Well, until review time - then, "why didn't you make any progress on your Jira tickets?"
- klodolph 4y ago
  One of the reasons why I would just open a Jira ticket anyway, process be damned. If I’m suspending work on a P1 because of this ticket, I’m gonna mark this ticket at least a P1. If management wants me to complete it within X hours, then I can find the priority level that matches the X-hour turnaround time.
  - commandlinefan 4y ago
    I usually do. I once worked for one company that was so dysfunctional that they implemented a rule that made it impossible to open a ticket and assign it to yourself to prohibit that.
  - tharkun__ 4y ago
    I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours). I don't see why. It's really not that hard in most places to create one. Even in large and bureaucratic ones. I always found that tickets are protection. When you're being asked to "drop everything for X", my first thought is to create a ticket for my own protection. At the least I can track the fact that I had to spend N hours on this thing X and I can refer back to it. At best I can document the stupidity of the whole thing w/ the ticket contents. If you're in a place like my sibling where they ban creating a ticket yourself and assigning yourself: run. That's so stupid for so many reason that it's not even funny any longer
    - klodolph 4y ago
      Yes, agreed. I think many developers have a vague understanding of how companies work and how their role fits into the company at large. I know a lot of developers who want to focus only on solving technical problems, want to be given the freedom to make technical problems, and want to have the other problems solved by everyone else. If you’re focusing on technical problems, a ticketing system is a burden imposed on you by management. If your priority is the success of your entire team rather than the success of your own technical decisions, then you’d understand that visibility of your work, your thought process, how you justify decisions, is all critical knowledge that a ticketing system serves to record and disseminate. I can’t count the number of times where I found a reference to a bug in a piece of code like: // Release gadget early to avoid starving froopy pipeline, // see bug #12345. And the ticket turned out to be super damn enlightening. You get to go back in time and relive, vicariously, a debugging session from two years ago by a team member who left the team.
      - 4y ago
- makestuff 4y ago
  Then in your retro meeting the manager/TPM/etc. talks about how we need a better process which results in nothing changing apart from more tickets to create.
- twblalock 4y ago
  In those cases you open the ticket and assign it to yourself, "for tracking purposes."

switch007 4y ago

On point 3, also you have a plethora of PMs who are insistent they are important and can bend the will of Somebody Important and definitely aren’t just relaying those “drop everything” requests and are actually a proper job of being a PM…

strangattractor 4y ago

I would also add that management often subverts the methodology by using them as a form of metrics. In my experience with Agile/Scrum they started to expect design and implementation in 2 weeks cycles which is unrealistic for large projects. This ultimately ended up in an inability to execute and complete projects that needed long term thinking and planning.

twblalock 4y ago

Development methodologies sort of work -- they don't work perfectly, but nothing really does. Most teams practice some sort of pseudo-version of methodology #1 while they do the practical work of methodology #2. That doesn't mean methodology #1 is useless. Agile/scrum really did have an impact on the industry, and the proof of that is how hard it is to find people who still advocate for the kind of waterfall methodology that was once accepted by pretty much everyone. The annoying thing about development methodologies is meeting people who don't understand that the map is not the territory and insist that a perfect application of a methodology is absolutely necessary. They drive everyone else crazy with buzzwords and process. Most people are fine with a sort-of agile process that takes reality and business value into account.

wpietri 4y ago
As somebody who was very involved in the Agile movement early on (2000-2008 or so), I don't think Agile deserves the credit here. What I think actually happened was that the rise of the internet made faster release cycles both possible and necessary. Scrum rode that wave, saying that they had the solution. But most Scrum implementations I've seen are not what I'd call conscious, proactive process change. It's just a new set of labels for accelerated versions of the old behaviors (waterfall or code-and-fix or a mix), plus a revenue stream for consultants and a certification scam for everybody else. I wrote more about that a long time ago, and still stand by it: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...
computerdork 4y ago
I completely agree with this. Yeah, it's not like they don't work at all, it's that they work to some degree. And, yeah, I think a lot of devs would agree that the traditional waterfall is not as good a process as agile. You could say that it's an antiprocess, whose basic idea is that the old inflexible waterfall with its overly structured teams is inefficient. Yes, small, tight-knit teams working closely together and iterating quickly is much more productive, creative and rewarding way to work. ... although, in my humble opinion, the one thing that agile really needs to stress more (that is key in the waterfall) is requirements. A (couple of) dedicated rounds of requirements where you talk with users (and stakeholders) saves a ton of dev time - agile does have requirements, but at least in my experience, devs seems to gloss over it.

raverbashing 4y ago

I can't complain too much about Scrum when some people take CMMI seriously (Of course those are deeply in managerial self-pleasing and probably would make a hello world project cost a million dollars, still...)

wpietri 4y ago

And I think #2 and #3 is why #1 is true. Or put differently, my experience in changing processes in many places has convinced me that unspoken management dynamics are what really matter, and that most managers will resent any process change that makes the actual management dynamics obvious. For example, one way to classify process changes is when they make problems obvious. E.g., a release-early, release-often approach makes problems visible early on. And I've had great luck with them on teams that are actually trying to succeed, because faster feedback means faster learning. But most organizations reject that because actual success doesn't matter nearly as much as managerial appearance of success. Many managers thus hate fast-feedback processes because they would rather hide negative information, even if that makes long-term success much less likely. But they like the appearance of success that comes with using the latest buzzwords. This results in the common pattern of the manager who talks Agile but whose projects are in effect waterfall. One book really helpful to me here looks at the default ideology of current management: https://www.amazon.com/Confronting-Managerialism-Business-Economic-Controversies-ebook/dp/B09LQSSM77/ref=sr_1_1?keywords=confronting+managerialism&qid=1670614278&sr=8-1 https://www.amazon.com/Confronting-Managerialism-Business-Ec...

nradov 4y ago
In many enterprise software markets, customers legitimately hate frequent releases. Each new release may force them to retrain employees, do their own compatibility testing with third-party systems, and possibly even go through some sort of expensive legal compliance process. It's a good discipline to always keep the main repo branch in a fully releasable state, but only push out actual releases on a slower schedule.
- quickthrower2 4y ago
  It depends what you release. A bug fix, an extra plugin etc. is not going to disrupt the user as much ad a UI overhaul. Feature flags and great communication with customers and empathy means you can have frequent releases without annoying the customer. It should be strictly better than slow releases. You can emulate a quarterly release of 1000 changes at once if you want that. Or you could say release fixes and small feature continuously and big features are timed with the customer/training/support functions. They might even be beta/optin at first. Getting the code out fast always and then providing ways to avoid dumping confusing features on people seems better to me.

mruniverse 4y ago

Number 3 seems about right. My Vulcan brain thinks that something like number 1 must the answer, but my lizard brain knows that the food pellets drop when I follow number 3. Back in the day, our CEO's neighbor mentioned that our site didn't work well on Microsoft's WebTV. WebTV appeared on our list of supported platforms.

RandyRanderson 4y ago

Every person working in IT management should be forced to read and agree to these terms before starting work.