13 ms·

Just as a note to the author what you saw the engineers do was SCRUM not agile. Most argue that SCRUM is agile I'm not 100% sure of that. SCRUM was a framework

Just as a note to the author what you saw the engineers do was SCRUM not agile. Most argue that SCRUM is agile I'm not 100% sure of that. SCRUM was a framework that one of the original agile proponents built to make money off developers. It gained popularity not from engineers but from project managers and the like which meant suddenly every project started to use SCRUM. The main reason was that they sold a course which gave a certificate and if there something that a project manager like more than micromanaging it's certification.

dgb23 4y ago
Why do you think that is?
- sirmarksalot 4y ago
  I think the Agile Manifesto is an exercise in subversively asking management for a very reasonable-sounding thing that is completely impossible: autonomy. Every line poses a threat to a well-known corporate best practice, and the natural reaction is to co-opt the message and bring the items in the left column back into the right column. In the case of Scrum, it's that "individuals and interactions over tools and processes" line. Scrum did start out as a popular Agile methodology among developers, but because it was the most prescriptive and process-oriented of the methodologies, it got adopted and twisted by management and turned into a tool to reassert authority. Now it reasserts that tools and processes are, in fact, more important than individuals and interactions, but this time with the "Agile" label. I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning.
  - azangru 4y ago
    > I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning. Don't you find value in keeping the digital record of the work? For example, if you want to keep track of dependencies that a given task has; or want to get back to the description of a given piece of product that was captured in a ticket (a user story, links to designs, references to other documents, etc.) after some time has passed? Notes on a corkboard are transient; tickets in the Jira are permanent. Isn't there value in that? BTW, why do people dislike Jira so much? Apart from it being slow or not allowing assignment of tickets to more than one person?
    - Juliate 4y ago
      There's value in keeping records for projects that last. But there's a slight difference between keeping records for accountability (just do the bare minimum to show that work happened as requested/regulated) and keeping records for documentation/action/archival. The difference shows in the care you take to design and operate those records. As for Jira: 1/ it IS slow 2/ it IS bloated (visually and functionally) 3/ it does work for a very specific limited number of ways to do things - but never yours 4/ when you start to look at the APIs and data model, you start to understand that it's been designed/built by people not having a clue what it was going to be used for, and by who - and it definitely shows. Bugzilla is old, clunky; Trac is... extremely focused; GitHub issues are limited. But I would more happily go back working with any of these and plug into additional tooling rather than with Jira. Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs.
      - dgb23 4y ago
        > Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs. Maybe there is a market for "literate programming merged with project/task management" where the narrative is maintained as a source of truth and individual items can be queried (or compiled) out of it. The narrative could based on some of the ideas in this article even: https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/ https://www.joelonsoftware.com/2000/10/02/painless-functiona...
    - BlargMcLarg 4y ago
      >Apart from it being slow That's exactly why. Bad JIRA implementations can easily incur 5-10 seconds of wait time just loading the page alone. JIRA as a tool allows everything under the sun for management to configure, which makes management do exactly that, configure everything under the sun. It's not unheard of having to tick 15-25 fields + checkboxes + dropdowns (most of which could've been autofilled or cut and made lean) because management likes it that way. I hope I don't have to explain why a crowd largely composed of "I hate doing the same manual work more than once" collectively sighs at this notion. Then you add onto that a workflow which requires one to open JIRA multiple times, multiple stages etc. and these people end up spending a lot of time on something they feel is incredibly inefficient. Great way to tank morale. "But that's a problem with the use of the tool, not the tool itself!" And we've seen this story a thousand times. If tools allow for weird things, weird things happen. Beyond that, I don't really see why people prefer the Atlassian stack which shows similar issues all-over and is a hassle to cobble together, when GitHub and GitLab do these things out of the box. The common complaint is "well GH/GL don't have X and we really need X", when the organization has never tried doing things without X.
  - r_c_a_d 4y ago
    We had that at Symbian in 2006. It was great. As a scrum master I did later use Jira to manage a backlog along with the product owner, but it was just for the two of us: all the stories were written on cards when they were ready to be worked on by the devs. Epics were also written on cards on a big wall... but each of those had an accompanying document / wiki page.
- a_imho 4y ago
  Well, the first point of Agile Manifesto says >Individuals and interactions over processes and tools and I would argue Scrum is a process and a rather heavyweight one. Thinking in terms of Scrum instead of your team/members and their preferences is getting it backwards.
Juliate 4y ago
Indeed, but in the industry, I've seen no company that embraced "agile" without embracing some predefined framework (scrum, kanban, xp) to "apply it". I've yet to find a growing/grown company that still embrace chaos as a start to find and nurture their own agile working methods. It's very much like how companies implement "innovation strategies", being oblivious to the fact that innovation starts with rebellion against the very structure in which it appears. Uncertainty is not something people embrace easily.
azangru 4y ago
Does this quote from the article: > They were all working hard, that was clear, but there was a fatal flaw: no one really knew what the project was ultimately supposed to look like, or exactly what purpose it was supposed to serve. sound like scrum though? No product owner, who would have a vision for what the product's purpose was or what it was supposed to eventually look like. No product backlog outlining a path to get to the vision. No sprint reviews with the product owner and stakeholders to inspect whether the product is on the right track. At least not that I saw in the article while quickly skimming through. What she is describing is some techniques picked from some agile methodologies; but lacking the proper spirit of the game.
- sgt101 4y ago
  no true scotsperson?
  - geodel 4y ago
    Yep, pretty simple really. If it works then only it can be called agile. E.g. we sacrifice goat everytime story is complete and human when an epic is completed successfully. It has worked so well for us. So I am gonna call it Right™ way of doing agile.
    - sgt101 4y ago
      I am happy with that so long as you : a) do not try and make other people kill goats, and b) do not insist on stopping the other team that likes to shave its hair after every show & tell because that works for them.
      - geodel 4y ago
        Well b) is excellent point. Instead of stopping it should be promoted everywhere.
        sgt101 4y ago
Cthulhu_ 4y ago
I agree that SCRUM is a framework built on top of agile, but I think it's a valuable handhold to start off with, because agile itself is too free and open to interpretation. I don't like the huge agile training, certification and consultancy market though, even though I've met some really well-versed project management people that operate in that market.
MattPalmer1086 4y ago
Many developers embraced scrum when it first appeared. It was a lot more developer focused than the pseudo waterfall type practices that existed previously. Can't code until the architect has written the spec. The deadline estimated from a Gantt chart by the PM. No feedback from stakeholders during development or the ability to alter requirements as they become better understood. So usually delivering code late that doesn't actually meet the customer's needs. Scrum was better. I hear it is now horribly abused (I'm out of the game now) and that's a shame. EDIT: I saw the most resistance to Scrum from project managers themselves, who did not understand a world without Gantt charts, or changing requirements as you went along.
- bdefore 4y ago
  Waterfall is a mostly manufactured pejorative by proponents of new processes. In what form it did exist, its practices were far from ubiquitous and mostly limited to government or very large corporations. Scrum arrived to slay a mythical beast.
  - MattPalmer1086 4y ago
    I agree waterfall did not really exist in most places which is why I called it pseudo waterfall. But the plan, code, test cycle, largely fixed requirements and PMs running everything from a Gantt chart existed in many places to a large extent.
    - bdefore 4y ago
      There was definitely the flavors you speak of. Companies suffered from individual pieces more than others and you rolled the dice when you changed jobs. What I anecdotally perceive has changed in the last five years or so is that the no good lying tools that arose from Scrum's popularity have become compelling to upper layers and weaponized against engineering. Burndown charts. Design documents. The bureaucracy that is JIRA (YAGNI IMO). These each chip away at autonomy.
      - 4y ago
kkfx 4y ago
Honestly SCRUM is an abomination, a tentative to adapt a mass-production technique (Toyoda Kanban for mechanical industry of the '900) to R&D/intellectual activities. The abomination is refusing to understand that creative activities can't be done well in constrained setups, while mass-production work very well with a certain rigidity. Toyoda NEVER tried to make Toyota R&D a kanban activity, just the factory part was kanban. Modern neoliberal managers have decided that the same technique they like can scale, while it can't. As a result we see a kind of quality-rise in listing terms, while the final outcome is crapwares monsters no one can understand not master, witch a big batch of side techniques to keep them artificially alive to a certain extent. Classic sw development have flaws, Agile manifesto was a tentative to mitigate them, but have not much to do with SCRUM nor with what we call agile today.
kps 4y ago
Scrum is collectivised micromanagement.
jeffbee 4y ago
It feels like they could have just called Agile "The True Scotsman" to short circuit both sides of this endless repetitive and predictable argument.
jghn 4y ago
One thing I've noticed is POs are almost always from the Product Management side. It makes sense, they both have Product in their name. I think this is part of the problem and that at the scrum team level the PO should be an engineer. The issue is that the granularity of a system that should have product management is often larger than the granularity of a single scrum team. You can have several teams working together on a cohesive product. Yet often each team will have it's own product manager acting as PO. This leads to a lot of unnecessary horse trading and suboptimal results.

dgb23 4y ago

Why do you think that is?

sirmarksalot 4y ago
I think the Agile Manifesto is an exercise in subversively asking management for a very reasonable-sounding thing that is completely impossible: autonomy. Every line poses a threat to a well-known corporate best practice, and the natural reaction is to co-opt the message and bring the items in the left column back into the right column. In the case of Scrum, it's that "individuals and interactions over tools and processes" line. Scrum did start out as a popular Agile methodology among developers, but because it was the most prescriptive and process-oriented of the methodologies, it got adopted and twisted by management and turned into a tool to reassert authority. Now it reasserts that tools and processes are, in fact, more important than individuals and interactions, but this time with the "Agile" label. I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning.
- azangru 4y ago
  > I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning. Don't you find value in keeping the digital record of the work? For example, if you want to keep track of dependencies that a given task has; or want to get back to the description of a given piece of product that was captured in a ticket (a user story, links to designs, references to other documents, etc.) after some time has passed? Notes on a corkboard are transient; tickets in the Jira are permanent. Isn't there value in that? BTW, why do people dislike Jira so much? Apart from it being slow or not allowing assignment of tickets to more than one person?
  - Juliate 4y ago
    There's value in keeping records for projects that last. But there's a slight difference between keeping records for accountability (just do the bare minimum to show that work happened as requested/regulated) and keeping records for documentation/action/archival. The difference shows in the care you take to design and operate those records. As for Jira: 1/ it IS slow 2/ it IS bloated (visually and functionally) 3/ it does work for a very specific limited number of ways to do things - but never yours 4/ when you start to look at the APIs and data model, you start to understand that it's been designed/built by people not having a clue what it was going to be used for, and by who - and it definitely shows. Bugzilla is old, clunky; Trac is... extremely focused; GitHub issues are limited. But I would more happily go back working with any of these and plug into additional tooling rather than with Jira. Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs.
    - dgb23 4y ago
      > Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs. Maybe there is a market for "literate programming merged with project/task management" where the narrative is maintained as a source of truth and individual items can be queried (or compiled) out of it. The narrative could based on some of the ideas in this article even: https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/ https://www.joelonsoftware.com/2000/10/02/painless-functiona...
  - BlargMcLarg 4y ago
    >Apart from it being slow That's exactly why. Bad JIRA implementations can easily incur 5-10 seconds of wait time just loading the page alone. JIRA as a tool allows everything under the sun for management to configure, which makes management do exactly that, configure everything under the sun. It's not unheard of having to tick 15-25 fields + checkboxes + dropdowns (most of which could've been autofilled or cut and made lean) because management likes it that way. I hope I don't have to explain why a crowd largely composed of "I hate doing the same manual work more than once" collectively sighs at this notion. Then you add onto that a workflow which requires one to open JIRA multiple times, multiple stages etc. and these people end up spending a lot of time on something they feel is incredibly inefficient. Great way to tank morale. "But that's a problem with the use of the tool, not the tool itself!" And we've seen this story a thousand times. If tools allow for weird things, weird things happen. Beyond that, I don't really see why people prefer the Atlassian stack which shows similar issues all-over and is a hassle to cobble together, when GitHub and GitLab do these things out of the box. The common complaint is "well GH/GL don't have X and we really need X", when the organization has never tried doing things without X.
- r_c_a_d 4y ago
  We had that at Symbian in 2006. It was great. As a scrum master I did later use Jira to manage a backlog along with the product owner, but it was just for the two of us: all the stories were written on cards when they were ready to be worked on by the devs. Epics were also written on cards on a big wall... but each of those had an accompanying document / wiki page.
a_imho 4y ago
Well, the first point of Agile Manifesto says >Individuals and interactions over processes and tools and I would argue Scrum is a process and a rather heavyweight one. Thinking in terms of Scrum instead of your team/members and their preferences is getting it backwards.

Juliate 4y ago

Indeed, but in the industry, I've seen no company that embraced "agile" without embracing some predefined framework (scrum, kanban, xp) to "apply it". I've yet to find a growing/grown company that still embrace chaos as a start to find and nurture their own agile working methods. It's very much like how companies implement "innovation strategies", being oblivious to the fact that innovation starts with rebellion against the very structure in which it appears. Uncertainty is not something people embrace easily.

azangru 4y ago

Does this quote from the article: > They were all working hard, that was clear, but there was a fatal flaw: no one really knew what the project was ultimately supposed to look like, or exactly what purpose it was supposed to serve. sound like scrum though? No product owner, who would have a vision for what the product's purpose was or what it was supposed to eventually look like. No product backlog outlining a path to get to the vision. No sprint reviews with the product owner and stakeholders to inspect whether the product is on the right track. At least not that I saw in the article while quickly skimming through. What she is describing is some techniques picked from some agile methodologies; but lacking the proper spirit of the game.

sgt101 4y ago
no true scotsperson?
- geodel 4y ago
  Yep, pretty simple really. If it works then only it can be called agile. E.g. we sacrifice goat everytime story is complete and human when an epic is completed successfully. It has worked so well for us. So I am gonna call it Right™ way of doing agile.
  - sgt101 4y ago
    I am happy with that so long as you : a) do not try and make other people kill goats, and b) do not insist on stopping the other team that likes to shave its hair after every show & tell because that works for them.
    - geodel 4y ago
      Well b) is excellent point. Instead of stopping it should be promoted everywhere.
      - sgt101 4y ago

Cthulhu_ 4y ago

I agree that SCRUM is a framework built on top of agile, but I think it's a valuable handhold to start off with, because agile itself is too free and open to interpretation. I don't like the huge agile training, certification and consultancy market though, even though I've met some really well-versed project management people that operate in that market.

MattPalmer1086 4y ago

Many developers embraced scrum when it first appeared. It was a lot more developer focused than the pseudo waterfall type practices that existed previously. Can't code until the architect has written the spec. The deadline estimated from a Gantt chart by the PM. No feedback from stakeholders during development or the ability to alter requirements as they become better understood. So usually delivering code late that doesn't actually meet the customer's needs. Scrum was better. I hear it is now horribly abused (I'm out of the game now) and that's a shame. EDIT: I saw the most resistance to Scrum from project managers themselves, who did not understand a world without Gantt charts, or changing requirements as you went along.

bdefore 4y ago
Waterfall is a mostly manufactured pejorative by proponents of new processes. In what form it did exist, its practices were far from ubiquitous and mostly limited to government or very large corporations. Scrum arrived to slay a mythical beast.
- MattPalmer1086 4y ago
  I agree waterfall did not really exist in most places which is why I called it pseudo waterfall. But the plan, code, test cycle, largely fixed requirements and PMs running everything from a Gantt chart existed in many places to a large extent.
  - bdefore 4y ago
    There was definitely the flavors you speak of. Companies suffered from individual pieces more than others and you rolled the dice when you changed jobs. What I anecdotally perceive has changed in the last five years or so is that the no good lying tools that arose from Scrum's popularity have become compelling to upper layers and weaponized against engineering. Burndown charts. Design documents. The bureaucracy that is JIRA (YAGNI IMO). These each chip away at autonomy.
    - 4y ago

kkfx 4y ago

Honestly SCRUM is an abomination, a tentative to adapt a mass-production technique (Toyoda Kanban for mechanical industry of the '900) to R&D/intellectual activities. The abomination is refusing to understand that creative activities can't be done well in constrained setups, while mass-production work very well with a certain rigidity. Toyoda NEVER tried to make Toyota R&D a kanban activity, just the factory part was kanban. Modern neoliberal managers have decided that the same technique they like can scale, while it can't. As a result we see a kind of quality-rise in listing terms, while the final outcome is crapwares monsters no one can understand not master, witch a big batch of side techniques to keep them artificially alive to a certain extent. Classic sw development have flaws, Agile manifesto was a tentative to mitigate them, but have not much to do with SCRUM nor with what we call agile today.

kps 4y ago

Scrum is collectivised micromanagement.

jeffbee 4y ago

It feels like they could have just called Agile "The True Scotsman" to short circuit both sides of this endless repetitive and predictable argument.

jghn 4y ago

One thing I've noticed is POs are almost always from the Product Management side. It makes sense, they both have Product in their name. I think this is part of the problem and that at the scrum team level the PO should be an engineer. The issue is that the granularity of a system that should have product management is often larger than the granularity of a single scrum team. You can have several teams working together on a cohesive product. Yet often each team will have it's own product manager acting as PO. This leads to a lot of unnecessary horse trading and suboptimal results.