6 ms·

The Process Is Not the Product. The New Agile Anti-Manifesto

64 points by mkarliner 6y ago

asplake 6y ago
His third point - “Dialog, not Dictation” - I agree with, but the other two are false dichotomies. Process (or at least the service levels enabled by process) is part of the whole product. Management and leadership are two sides of the same coin - one without the other is empty. I get the frustration. Imposed process smells of poor management. But process and management can’t just be wished away.
- lmm 6y ago
  Process is the means, product is the end. It's better to break the process for the sake of the product than the other way round.
Nursie 6y ago
Eh, jira can be fine so long as you keep it simple and just use it to track pieces of work in progress, bugs etc. By the time you're hiring a jira specialist and talking about workflows and restricted state transitions, something has probably gone very wrong though. Also worth remembering, as we rail against this stuff - good people don't need to be encumbered by that much process to produce good things, especially in small groups. But not everyone is that good, and groups don't always stay small. Not that that means that adding process is always right, but it is another factor to keep in mind.
- lumost 6y ago
  The biggest culprit I've seen for this kind of bloat is reporting requirements. Senior leadership is often perceived as wanting to see burndown charts and other numerical progress indicators. These reports are then presented to leadership, and then leadership reacts to seeing the burndown as flat, have a giant spike at the end, or go the opposite direction. Good leadership will of course ask for corrective actions, as clearly one of their teams is struggling, and then the team/manager will come up with more complex workflows to help clarify progress. In practice I've found a 2-3 sentence update for each project on what's been achieved for any given project on the team and what's happening next is more than sufficient. Bonus points for capturing the highlights and action items from the retro. You'll still get questions/kudos for progress, but its easier to discuss the root causes without reaching for the "process change" tool.
  - nyulmalac 6y ago
    I agree with your approach. I always try to avoid to give such KPI toward management. They fall in love with it and then it leads to just KPI limbo... It can be faked, or manipulated to obfuscate reality... Another funny story : Once our department head was really angry because we wanted to open our Jira board inside the company. :D He afraid of that others would see that not everything is awesome... And it will have negative consequences. Ok this fear is also strengthened by the clueless upper management who has no idea how sw dev is done...
- SideburnsOfDoom 6y ago
  > Eh, jira can be fine It can, but it (almost always) isn't. Previous discussion: https://news.ycombinator.com/item?id=25590846 https://news.ycombinator.com/item?id=25590846
- nyulmalac 6y ago
  Haha thanks for this comment, this reminds me to that Jira madness I have seen at one group I worked with. (Classical non-sw company). The management have read books about how the software should be developed, designed a nice process, and created a complicated workflow, with numerous different kind of statuses and so on. All this for internal tool development... I was laughing inside. So what happened? The in-progress - review - test (and what else where there I can’t recall) was completed by the developer in a few seconds. :D And after 3 year and some management change, they improved significantly by reduced workflow. To be honest I am proud of them. In my experience enforcing complicated processes only improves the creativity how to avoid them... Don’t missunderstand me, I’m not against processes, but I believe in keep it simple and stupid.
avereveard 6y ago
Project management is fine, needed even, you don't need and probably don't want to be in the countless client meeting where everything is bickering and bike shedding, and you don't want engineering to be the one coordinating the countless administrative task and being generally distracted by paperwork Management is fine as long as it's a cog in the production chain; you can generally know if your management is healthy if the IT/Dev budget comes from the IT/Dev leads and if the contracting work requires IT/Dev signoff. I get it, most places around see management as the steering committee, and quickly become disfunctional as their focus shifts in justifying their own budget, but that's because IT/Devs are a century behind in establishing their profession as specialists like lawyers and doctors and often find themselves in blue collar type positions, not from a specific property of having "management" Just look at hospitals and lawyer firms, you'll find seniors doctors and lawyers at the top, and accountants in their own dept, and not the other way around.
- satyrnein 6y ago
  Hospitals have hospital administrators at the top, which are not doctors. Law firms do have lawyers on top, but they are basically like small consulting shops. (Small tech consulting shops similarly have tech people on top.) In most companies, though, legal is just a department like any other.
  - marcosdumay 6y ago
    > Hospitals have hospital administrators at the top I really don't understand how this does not create an endless stream of problems (or, quite likely, it does, but they are well hidden). But keep in mind that the power of hospital administrators is severely restricted compared to software development managers (what is really reasonable, by the way). It's a general rule for all kinds of engineering that one can not deliver quality if the management isn't composed of good engineers. You can deliver all kinds of stuff, but not quality.
    - satyrnein 6y ago
      Andy Jassy ran AWS without being an engineer. I'm sure there are downsides, but I think many engineers are biased against managers in a way that doesn't match the reality.
gamesbrainiac 6y ago
My main issue is with Scrum. The problem is that there is no balance. Scrum started off as a way for software consultancies to make sure that the their clients could not ask for new features without repercussions. In other words, story points helped to make sure that if they wanted changes, and more stuff, then they would need to pay for it. You do not have this balance within a company, because there is constant pressure to increase velocity. This is why there is so much burnout within the industry. There is constant pressure to do more and to do it faster. To the OP's point, there are so many scam Agile coaches out there, who can't write a fizzbuzz function. I've met many of them. You know what the worst part is? They think they're adding value by just pushing people constantly.
- deleted 6y ago
  [deleted]
- tharkun__ 6y ago
  Not really no. In fact consulting companies struggle with agile and story points because virtually no client wants to pay for a number of story points. They will pay for 'man hours' though. As for the pressure to deliver more. That is not new either. Before Story points and velocity they would pressure teams and individuals into estimating lower. "come on that can't take 100 man hours to do. The other team is doing something very similar and thhey say they can do it in 50". That is actually worse if you ask me that story points which are not absolute time units and instead relative sizes. So if one team says the story has 8 SP and another says 5 SP but one team's velocity is 16 while the other team has a velocity of 10 then both teams are saying it takes half the sprint. And the above is exactly what you are saying about bad agile coaches and people finding ways to abuse Agile (which they will probably do with any methodoly you invent even if you do make it less bad than what came before). Case in point about Story points actually being better than man hour estimates. But people still try to abuse them. Now the good part about it is with story points, if you as the Scrum Master fail to convince upper management that no you can't increase velocity into infinity you can simple increase your estimates and your velocity magically goes up. But nobody can come in and say anything against it as long as you still actually deliver because you didn't increase an absolute estimate in hours. You just suddenly have a velocity of 16 like the other team instead of 10 but you still delivered the same actual output.
fabbari 6y ago
I have to push back against the 'process' too often to care to count. The idea of the self managed team shatters against the rocks of: there is no card on the board for this so I can't do it, which produces boards filled with cards that have no user value in them. We twist ourselves in knots explaining that 'yeah, implementing the CI/CD pipeline brings value to the user because we are faster at delivering software'. It boils down to the idea that the 'user stories' are just metric collection tools, so if you haven't delivered a story, you implicitly have done nothing. And the 'placeholders for a conversation' have become mini requirement docs, because we don't trust our development team to pick up a card and investigate, communicate and plan their work. So refinement meetings become long debates on the minutia of the story, litanies of acceptance criteria that read like contract agreements of years past. You begin to see hierarchical structure form in supposed teams of peers, where someone will casually ask: "Hey X - can you put a story on the board with this?" "Agile" is no longer a adjective of how our practices are, but a label on a set of processes that some board has certified as such. PS: Can anyone tell me why when I write in my iPad all my comments look like code blocks? I know it's annoying too others, but not as much as it is to me!
- m463 6y ago
  you are indenting two or more characters, which in hn markdown means format as code indented 1 (blanks squeezed out) indented 2 indented 3
  - fabbari 6y ago
    So it's my damned writing style to start paragraphs with spaces that's biting me in the rear! I tend to do that to format a bit the content, but it seems to collide with the markdown. Thanks for the heads up, will make sure I won't be doing that on HN comments.
    - m463 6y ago
      formality and computers don't always mix. Just like wearing a tie is dangerous when you're adding a cooling fan to your cpu. :)
Aeolun 6y ago
I could take this more seriously as a new agile manifesto if it wasn’t published on Medium. These kind of things have to stand on their own.
- mkarliner 6y ago
  I have to agree. But I've been too lazy with my personal blog to make an impact. Hopefully the medium (lower case) shouldn't affect the message.
sz4kerto 6y ago
Jira. Please stop crapping on it. It's a tool that's too flexible so many people can't resist abusing it. It's you, not it. For us, it's primarily a documentation tool. It has great integrations. If someone makes a complex pull request, the text that tells me what it does is the Jira issue. Yes, it could be the PR description, but Jira is much easier to link to, search, etc. 2 years later when someone looks at the git commit, they can go to Jira and read through the whole context, who created it, who commented on it, etc. Just use the damn thing to solve problems you actually have. Jira, Java, Windows, JavaScript, Kubernetes, etc. can be used in various ways, and because most people aren't excellent at what they do, flexible tools will result in lot of crappy output just because so many people can use them. If Jira/etc. destroys your project then it's absolutely your fault.
- flohofwoe 6y ago
  The problem with JIRA is that it attracts and encourages "bureaucracy creep" in typical "big companies". Right after you're switching to JIRA it's fine. But soon the manager types are discovering JIRA as their favourite surveillance toy, and add this little extra step to a bug life cycle, or add this little field here to check when a bug has been resolved. Then that manager leaves and the next one comes in, and "improves" JIRA workflows again. Repeat that 5 times, and your organization has created a monster. I've never seen that with other less flexible bug tracking tools.
  - SideburnsOfDoom 6y ago
    > Repeat that 5 times, and your organization has created a monster. Yes, this. Jira is cancer: > Any problem gets solved with "more JIRA " which stops working when the remaining problems are caused by too much JIRA. And yet they keep trying, because it gives "control". JIRA is a like metastatic tumour that will grow until it kills the host. https://news.ycombinator.com/item?id=25590846 https://news.ycombinator.com/item?id=25590846
- lmm 6y ago
  If everyone uses a tool wrong, it's not a problem with the people, it's a problem with the tool. Jira makes a lot of bad design decisions. Virtually everything it does has no undo. Different issue types behave almost, but not quite, the same, and have far too many different fields that end up meaning almost but not quite the same thing, so denormalisation and inconsistency are rampant. It's a micromanagement-first system: everything you want to do has to be explicitly enabled by a manager, and if you want to do something a manager didn't think of, too bad. And its performance is awful.
languagehacker 6y ago
Thanks, I hate it.
marcosdumay 6y ago
Well, you mean those? > Individuals and interactions over processes and tools > Customer collaboration over contract negotiation
- mkarliner 6y ago
  Yep. I still believe in those values. We just need to get back to them, and not buy Agile courses :-)
  - marcosdumay 6y ago
    The Agile training and consulting (not software development consulting, but those management consultings) industry sold so much snake oil that they killed an entire industry. The funny thing is that there is nothing either agile (small "a") or Agile (large "A") on anything they sold.
deleted 6y ago
[deleted]
chris_f 6y ago
A lot of other professions build complex things, even sometimes involving large teams across different departments. Do they all have their different industry frameworks/methodologies (like Agile), or is that unique to software?
- PragmaticPulp 6y ago
  In my experience, other industries or even technology fields tend to be more deliberate and methodical, regardless of what framework is being used. I’ve seen Agile used with great effect in other domains, and I’ve also seen plenty of operations that didn’t use any brand-name framework at all because they simply sat down and mapped out the flow of their planning, delivery, and feedback loops. The unique thing about software is that it feels like we can move faster, deploy quicker, and correct mistakes easier than something like a construction site or a hardware project that has multi-month turnaround times for each build. Software feels so malleable and quick to change that we’ve developed an attitude that it’s better to ship something quick, look for failures, and then correct where necessary. Most of the time it works, because if you’re not the company shipping as fast as possible then your competitors might catch that market share before you have a chance to ship your well-designed product. There are always exceptions, of course, but software is the field where I see the most hatred of process in general. The other domains I work in may not love the process, but they’re not at war with process and management like the software developers I’ve worked with (and been).
- dbrueck 6y ago
  Wondering out loud: does any other human creation have the same level of complexity as computer software?
  - username90 6y ago
    If building materials and factory production lines was basically free and instant you'd see a ton of strange and complex creations be done by mechanical engineers or other people working in physical space. Instead of the current sleek cars you'd get abominations with things sticking out everywhere to save engineering hours etc, and nobody would know how they really work.
darkerside 6y ago
This reminds me of what they say about democracy, that it's the worst form of government besides all the other ones. Or programming languages. There's the ones people complain about and the ones nobody users. Process isn't fun, and yes there are times when it gets in the way. But if you don't have one, you still do. It's just not formalized and probably powered by force of personality instead of the needs of the business. Hopefully those are aligned. The powerful think everything is working great, and for them, it is. As long as the business is aligned with their needs, this works. But it doesn't scale to when you have many different stakeholders with conflicting needs.
projectileboy 6y ago
Everyone loves these rants about bad process. I do too. But they always sound childish when they don’t explain how we’re supposed to set direction and coordinate work across 12 teams all working on the same product. And most of us work in enterprise-y environments where this is unavoidable.
diydsp 6y ago
Recently I had a client obsessed with the "Jira" version of the world, ignoring the real world. E.g. product wasn't meeting a spec but the spec was irrelevant. But they committed to it in writing/database so we obsessed to improve that useless spec at great cost to customer needs... To be fair, not just the tool's fault, but the tool does influence perception by looking "official," having "permissions," and inducing sunk cost fallacy by foregrounding how long things are taking. E.g. "We can't admit this spec is useless now... we've put so much time into it, just look at Jira!"
kragen 6y ago
https://archive.fo/lJlrY https://archive.fo/lJlrY
rodolphoarruda 6y ago
"The process is not the product" I found it more interesting and productive to provoke discussions around another perspective: "The product is not the business". It's so common to see people think that just because their product sounds nice and compelling to its intended market/niche, it doesn't mean the same team would be able to sell it and maintain it in an ongoing basis, let alone evolve it. The reality of business operations is too cruel.
stunt 6y ago
Agile works but where companies fail miserably is the implementation. Especially many of those that go with Scrum (or its flavors). They treat Scrum Master as a person instead of a role within the team. So they assign a non-engineer to an engineering team permanently that has some influence on the way of working without ever guiding the team to be self managed agile team.
- Viliam1234 6y ago
  Most companies implement ScrumBut https://www.scrum.org/resources/what-scrumbut https://www.scrum.org/resources/what-scrumbut For example: Scrum, but retrospectives are a waste of time so we don't do them here (or keep them as short as possible, because no one cares about your feedback anyway); and you can estimate the story points, but the management has already decided that the deadline for these features is one month, so your choice is really which ones you want to implement during the first two weeks, and which ones during the second two weeks, now go ahead and do your little Scrum poker ritual. Meanwhile, on the Scrum training they tell you that the retrospective is the most important part of the Scrum; that everything else can be dropped if necessary but you must keep the retrospective at all cost. Then you get the certificate, and then the management tells you "that's nice, but we do it differently here". Management wants the buzzwords, and perhaps some of the rituals, but not any actual change. You are free to do Scrum, as long as you only select the parts convenient for them, and remove everything inconvenient for them. The same would happen with any other methodology.
- paulmooreparks 6y ago
  Agile, and Scrum in particular, is a lot like Communism and faith healing. When it doesn't work, its adherents claim the failure was due to not implementing it correctly or not believing in it enough.
  - lmm 6y ago
    There's no such thing as a process that works when you don't actually follow it. Most critics of Agile are like recipe reviewers: "I ran out of sugar so I substituted goats' milk, and that sounds like a lot of flour so I used half as much. Tasted awful, 1/5."
brayhite 6y ago
I sympathize with the anti-management sentiment overall, but I’ve yet to see anyone address alternatives to designating someone, new hire or otherwise, as a “manager”. This article doesn’t really touch on it other than to say “do a bunch of things right and folks can self-manage”, which is a retort to a narrow use-case for management. Not all managers are intended to be people managers, nor do they want to be. I can’t help but think the management vs non-management paradigm is 50% due to anti-management stereotype, and 50% due to actually toxic management practices. And I imagine half or less of that latter 50% are toxic because of a bad manager. Everything else is likely due to overbearing leadership, poor company goals, a bad process that management would too like to change but can’t, etc etc. Generally, I agree with the article’s sentiment. Don’t force a process, find what works for your employees. Get company buy-in. Set clear rules and goals. Hold folks accountable, and tell them to hold you accountable too.
anotherhue 6y ago
I used to think Jira was the problem, then at my current (small) company I became the Jira admin. Excellent, I thought. I will finally get to use this tool properly, set it up sensibly, and put to rest all the horrible experiences that are too common. I've been deep in the bowels, custom issue types, custom workflows, if it was accessible I've been in there. After six months of trying I believe it is unsalvageable. Adherents seem to suffer from a form of Stockholm-syndrome. * We have a small team, < 30 people, probably < 2000 issues. It is unacceptably slow. Performance is a joke and it keeps getting worse. No we don't have a dozen integrations. * Next-gen projects. Think Python2->3 confusion but for your entire company/workflow. Madness, short-sighted, and ultimately solely for the benefit of Atlassian, not the users. * "Premium" mode required to provide features that should be basic. Twice the price. No option to enable "Premium" on a per-user basis. So thousands of dollars for one PM to use a Gantt chart. * Pricing. I don't want to pay a full seat/month to allow a marketing person to put a ticket on an engineering backlog. Yes, they could go via a person but if you're going to mandate human mediation then why do we have the damn tool in the first place? This makes it exclusionary. * UI Design keeps getting worse. Necessary information is hidden at every possible opportunity. It's like they saw the Google whitespace focused redesigns from a few years back and felt personally threatened. * I refuse to accept that the cost of switching tools is too high, I've switched my teams over to Basecamp and we not longer feel like we are fighting our tools to do our jobs. * If you work somewhere where this level of process is required (medicine, military...) then Jira is not the right tool. If you don't need this level of process, then Jira is not the right tool. It is simply not the right tool.
ymbeld 6y ago
> Informing everyone, right down to the janitors (and all respect to janitors) where we are going and why. But it isn’t a coincidence that you chose to single out the janitors as those who are “down”.
ojciecczas 6y ago
Nah.

64 points by mkarliner 6y ago

His third point - “Dialog, not Dictation” - I agree with, but the other two are false dichotomies. Process (or at least the service levels enabled by process) is part of the whole product. Management and leadership are two sides of the same coin - one without the other is empty. I get the frustration. Imposed process smells of poor management. But process and management can’t just be wished away.

lmm 6y ago
Process is the means, product is the end. It's better to break the process for the sake of the product than the other way round.

Nursie 6y ago

Eh, jira can be fine so long as you keep it simple and just use it to track pieces of work in progress, bugs etc. By the time you're hiring a jira specialist and talking about workflows and restricted state transitions, something has probably gone very wrong though. Also worth remembering, as we rail against this stuff - good people don't need to be encumbered by that much process to produce good things, especially in small groups. But not everyone is that good, and groups don't always stay small. Not that that means that adding process is always right, but it is another factor to keep in mind.

lumost 6y ago
The biggest culprit I've seen for this kind of bloat is reporting requirements. Senior leadership is often perceived as wanting to see burndown charts and other numerical progress indicators. These reports are then presented to leadership, and then leadership reacts to seeing the burndown as flat, have a giant spike at the end, or go the opposite direction. Good leadership will of course ask for corrective actions, as clearly one of their teams is struggling, and then the team/manager will come up with more complex workflows to help clarify progress. In practice I've found a 2-3 sentence update for each project on what's been achieved for any given project on the team and what's happening next is more than sufficient. Bonus points for capturing the highlights and action items from the retro. You'll still get questions/kudos for progress, but its easier to discuss the root causes without reaching for the "process change" tool.
- nyulmalac 6y ago
  I agree with your approach. I always try to avoid to give such KPI toward management. They fall in love with it and then it leads to just KPI limbo... It can be faked, or manipulated to obfuscate reality... Another funny story : Once our department head was really angry because we wanted to open our Jira board inside the company. :D He afraid of that others would see that not everything is awesome... And it will have negative consequences. Ok this fear is also strengthened by the clueless upper management who has no idea how sw dev is done...
SideburnsOfDoom 6y ago
> Eh, jira can be fine It can, but it (almost always) isn't. Previous discussion: https://news.ycombinator.com/item?id=25590846 https://news.ycombinator.com/item?id=25590846
nyulmalac 6y ago
Haha thanks for this comment, this reminds me to that Jira madness I have seen at one group I worked with. (Classical non-sw company). The management have read books about how the software should be developed, designed a nice process, and created a complicated workflow, with numerous different kind of statuses and so on. All this for internal tool development... I was laughing inside. So what happened? The in-progress - review - test (and what else where there I can’t recall) was completed by the developer in a few seconds. :D And after 3 year and some management change, they improved significantly by reduced workflow. To be honest I am proud of them. In my experience enforcing complicated processes only improves the creativity how to avoid them... Don’t missunderstand me, I’m not against processes, but I believe in keep it simple and stupid.

avereveard 6y ago

Project management is fine, needed even, you don't need and probably don't want to be in the countless client meeting where everything is bickering and bike shedding, and you don't want engineering to be the one coordinating the countless administrative task and being generally distracted by paperwork Management is fine as long as it's a cog in the production chain; you can generally know if your management is healthy if the IT/Dev budget comes from the IT/Dev leads and if the contracting work requires IT/Dev signoff. I get it, most places around see management as the steering committee, and quickly become disfunctional as their focus shifts in justifying their own budget, but that's because IT/Devs are a century behind in establishing their profession as specialists like lawyers and doctors and often find themselves in blue collar type positions, not from a specific property of having "management" Just look at hospitals and lawyer firms, you'll find seniors doctors and lawyers at the top, and accountants in their own dept, and not the other way around.

satyrnein 6y ago
Hospitals have hospital administrators at the top, which are not doctors. Law firms do have lawyers on top, but they are basically like small consulting shops. (Small tech consulting shops similarly have tech people on top.) In most companies, though, legal is just a department like any other.
- marcosdumay 6y ago
  > Hospitals have hospital administrators at the top I really don't understand how this does not create an endless stream of problems (or, quite likely, it does, but they are well hidden). But keep in mind that the power of hospital administrators is severely restricted compared to software development managers (what is really reasonable, by the way). It's a general rule for all kinds of engineering that one can not deliver quality if the management isn't composed of good engineers. You can deliver all kinds of stuff, but not quality.
  - satyrnein 6y ago
    Andy Jassy ran AWS without being an engineer. I'm sure there are downsides, but I think many engineers are biased against managers in a way that doesn't match the reality.

gamesbrainiac 6y ago

My main issue is with Scrum. The problem is that there is no balance. Scrum started off as a way for software consultancies to make sure that the their clients could not ask for new features without repercussions. In other words, story points helped to make sure that if they wanted changes, and more stuff, then they would need to pay for it. You do not have this balance within a company, because there is constant pressure to increase velocity. This is why there is so much burnout within the industry. There is constant pressure to do more and to do it faster. To the OP's point, there are so many scam Agile coaches out there, who can't write a fizzbuzz function. I've met many of them. You know what the worst part is? They think they're adding value by just pushing people constantly.

deleted 6y ago
[deleted]
tharkun__ 6y ago
Not really no. In fact consulting companies struggle with agile and story points because virtually no client wants to pay for a number of story points. They will pay for 'man hours' though. As for the pressure to deliver more. That is not new either. Before Story points and velocity they would pressure teams and individuals into estimating lower. "come on that can't take 100 man hours to do. The other team is doing something very similar and thhey say they can do it in 50". That is actually worse if you ask me that story points which are not absolute time units and instead relative sizes. So if one team says the story has 8 SP and another says 5 SP but one team's velocity is 16 while the other team has a velocity of 10 then both teams are saying it takes half the sprint. And the above is exactly what you are saying about bad agile coaches and people finding ways to abuse Agile (which they will probably do with any methodoly you invent even if you do make it less bad than what came before). Case in point about Story points actually being better than man hour estimates. But people still try to abuse them. Now the good part about it is with story points, if you as the Scrum Master fail to convince upper management that no you can't increase velocity into infinity you can simple increase your estimates and your velocity magically goes up. But nobody can come in and say anything against it as long as you still actually deliver because you didn't increase an absolute estimate in hours. You just suddenly have a velocity of 16 like the other team instead of 10 but you still delivered the same actual output.

fabbari 6y ago

I have to push back against the 'process' too often to care to count. The idea of the self managed team shatters against the rocks of: there is no card on the board for this so I can't do it, which produces boards filled with cards that have no user value in them. We twist ourselves in knots explaining that 'yeah, implementing the CI/CD pipeline brings value to the user because we are faster at delivering software'. It boils down to the idea that the 'user stories' are just metric collection tools, so if you haven't delivered a story, you implicitly have done nothing. And the 'placeholders for a conversation' have become mini requirement docs, because we don't trust our development team to pick up a card and investigate, communicate and plan their work. So refinement meetings become long debates on the minutia of the story, litanies of acceptance criteria that read like contract agreements of years past. You begin to see hierarchical structure form in supposed teams of peers, where someone will casually ask: "Hey X - can you put a story on the board with this?" "Agile" is no longer a adjective of how our practices are, but a label on a set of processes that some board has certified as such. PS: Can anyone tell me why when I write in my iPad all my comments look like code blocks? I know it's annoying too others, but not as much as it is to me!

m463 6y ago
you are indenting two or more characters, which in hn markdown means format as code indented 1 (blanks squeezed out) indented 2 indented 3
- fabbari 6y ago
  So it's my damned writing style to start paragraphs with spaces that's biting me in the rear! I tend to do that to format a bit the content, but it seems to collide with the markdown. Thanks for the heads up, will make sure I won't be doing that on HN comments.
  - m463 6y ago
    formality and computers don't always mix. Just like wearing a tie is dangerous when you're adding a cooling fan to your cpu. :)

Aeolun 6y ago

I could take this more seriously as a new agile manifesto if it wasn’t published on Medium. These kind of things have to stand on their own.

mkarliner 6y ago
I have to agree. But I've been too lazy with my personal blog to make an impact. Hopefully the medium (lower case) shouldn't affect the message.

sz4kerto 6y ago

Jira. Please stop crapping on it. It's a tool that's too flexible so many people can't resist abusing it. It's you, not it. For us, it's primarily a documentation tool. It has great integrations. If someone makes a complex pull request, the text that tells me what it does is the Jira issue. Yes, it could be the PR description, but Jira is much easier to link to, search, etc. 2 years later when someone looks at the git commit, they can go to Jira and read through the whole context, who created it, who commented on it, etc. Just use the damn thing to solve problems you actually have. Jira, Java, Windows, JavaScript, Kubernetes, etc. can be used in various ways, and because most people aren't excellent at what they do, flexible tools will result in lot of crappy output just because so many people can use them. If Jira/etc. destroys your project then it's absolutely your fault.

flohofwoe 6y ago
The problem with JIRA is that it attracts and encourages "bureaucracy creep" in typical "big companies". Right after you're switching to JIRA it's fine. But soon the manager types are discovering JIRA as their favourite surveillance toy, and add this little extra step to a bug life cycle, or add this little field here to check when a bug has been resolved. Then that manager leaves and the next one comes in, and "improves" JIRA workflows again. Repeat that 5 times, and your organization has created a monster. I've never seen that with other less flexible bug tracking tools.
- SideburnsOfDoom 6y ago
  > Repeat that 5 times, and your organization has created a monster. Yes, this. Jira is cancer: > Any problem gets solved with "more JIRA " which stops working when the remaining problems are caused by too much JIRA. And yet they keep trying, because it gives "control". JIRA is a like metastatic tumour that will grow until it kills the host. https://news.ycombinator.com/item?id=25590846 https://news.ycombinator.com/item?id=25590846
lmm 6y ago
If everyone uses a tool wrong, it's not a problem with the people, it's a problem with the tool. Jira makes a lot of bad design decisions. Virtually everything it does has no undo. Different issue types behave almost, but not quite, the same, and have far too many different fields that end up meaning almost but not quite the same thing, so denormalisation and inconsistency are rampant. It's a micromanagement-first system: everything you want to do has to be explicitly enabled by a manager, and if you want to do something a manager didn't think of, too bad. And its performance is awful.

languagehacker 6y ago

Thanks, I hate it.

marcosdumay 6y ago

Well, you mean those? > Individuals and interactions over processes and tools > Customer collaboration over contract negotiation

mkarliner 6y ago
Yep. I still believe in those values. We just need to get back to them, and not buy Agile courses :-)
- marcosdumay 6y ago
  The Agile training and consulting (not software development consulting, but those management consultings) industry sold so much snake oil that they killed an entire industry. The funny thing is that there is nothing either agile (small "a") or Agile (large "A") on anything they sold.

deleted 6y ago

[deleted]

chris_f 6y ago

A lot of other professions build complex things, even sometimes involving large teams across different departments. Do they all have their different industry frameworks/methodologies (like Agile), or is that unique to software?

PragmaticPulp 6y ago
In my experience, other industries or even technology fields tend to be more deliberate and methodical, regardless of what framework is being used. I’ve seen Agile used with great effect in other domains, and I’ve also seen plenty of operations that didn’t use any brand-name framework at all because they simply sat down and mapped out the flow of their planning, delivery, and feedback loops. The unique thing about software is that it feels like we can move faster, deploy quicker, and correct mistakes easier than something like a construction site or a hardware project that has multi-month turnaround times for each build. Software feels so malleable and quick to change that we’ve developed an attitude that it’s better to ship something quick, look for failures, and then correct where necessary. Most of the time it works, because if you’re not the company shipping as fast as possible then your competitors might catch that market share before you have a chance to ship your well-designed product. There are always exceptions, of course, but software is the field where I see the most hatred of process in general. The other domains I work in may not love the process, but they’re not at war with process and management like the software developers I’ve worked with (and been).
dbrueck 6y ago
Wondering out loud: does any other human creation have the same level of complexity as computer software?
- username90 6y ago
  If building materials and factory production lines was basically free and instant you'd see a ton of strange and complex creations be done by mechanical engineers or other people working in physical space. Instead of the current sleek cars you'd get abominations with things sticking out everywhere to save engineering hours etc, and nobody would know how they really work.

darkerside 6y ago

This reminds me of what they say about democracy, that it's the worst form of government besides all the other ones. Or programming languages. There's the ones people complain about and the ones nobody users. Process isn't fun, and yes there are times when it gets in the way. But if you don't have one, you still do. It's just not formalized and probably powered by force of personality instead of the needs of the business. Hopefully those are aligned. The powerful think everything is working great, and for them, it is. As long as the business is aligned with their needs, this works. But it doesn't scale to when you have many different stakeholders with conflicting needs.

projectileboy 6y ago

Everyone loves these rants about bad process. I do too. But they always sound childish when they don’t explain how we’re supposed to set direction and coordinate work across 12 teams all working on the same product. And most of us work in enterprise-y environments where this is unavoidable.

diydsp 6y ago

Recently I had a client obsessed with the "Jira" version of the world, ignoring the real world. E.g. product wasn't meeting a spec but the spec was irrelevant. But they committed to it in writing/database so we obsessed to improve that useless spec at great cost to customer needs... To be fair, not just the tool's fault, but the tool does influence perception by looking "official," having "permissions," and inducing sunk cost fallacy by foregrounding how long things are taking. E.g. "We can't admit this spec is useless now... we've put so much time into it, just look at Jira!"

kragen 6y ago

https://archive.fo/lJlrY https://archive.fo/lJlrY

rodolphoarruda 6y ago

"The process is not the product" I found it more interesting and productive to provoke discussions around another perspective: "The product is not the business". It's so common to see people think that just because their product sounds nice and compelling to its intended market/niche, it doesn't mean the same team would be able to sell it and maintain it in an ongoing basis, let alone evolve it. The reality of business operations is too cruel.

stunt 6y ago

Agile works but where companies fail miserably is the implementation. Especially many of those that go with Scrum (or its flavors). They treat Scrum Master as a person instead of a role within the team. So they assign a non-engineer to an engineering team permanently that has some influence on the way of working without ever guiding the team to be self managed agile team.

Viliam1234 6y ago
Most companies implement ScrumBut https://www.scrum.org/resources/what-scrumbut https://www.scrum.org/resources/what-scrumbut For example: Scrum, but retrospectives are a waste of time so we don't do them here (or keep them as short as possible, because no one cares about your feedback anyway); and you can estimate the story points, but the management has already decided that the deadline for these features is one month, so your choice is really which ones you want to implement during the first two weeks, and which ones during the second two weeks, now go ahead and do your little Scrum poker ritual. Meanwhile, on the Scrum training they tell you that the retrospective is the most important part of the Scrum; that everything else can be dropped if necessary but you must keep the retrospective at all cost. Then you get the certificate, and then the management tells you "that's nice, but we do it differently here". Management wants the buzzwords, and perhaps some of the rituals, but not any actual change. You are free to do Scrum, as long as you only select the parts convenient for them, and remove everything inconvenient for them. The same would happen with any other methodology.
paulmooreparks 6y ago
Agile, and Scrum in particular, is a lot like Communism and faith healing. When it doesn't work, its adherents claim the failure was due to not implementing it correctly or not believing in it enough.
- lmm 6y ago
  There's no such thing as a process that works when you don't actually follow it. Most critics of Agile are like recipe reviewers: "I ran out of sugar so I substituted goats' milk, and that sounds like a lot of flour so I used half as much. Tasted awful, 1/5."

brayhite 6y ago

I sympathize with the anti-management sentiment overall, but I’ve yet to see anyone address alternatives to designating someone, new hire or otherwise, as a “manager”. This article doesn’t really touch on it other than to say “do a bunch of things right and folks can self-manage”, which is a retort to a narrow use-case for management. Not all managers are intended to be people managers, nor do they want to be. I can’t help but think the management vs non-management paradigm is 50% due to anti-management stereotype, and 50% due to actually toxic management practices. And I imagine half or less of that latter 50% are toxic because of a bad manager. Everything else is likely due to overbearing leadership, poor company goals, a bad process that management would too like to change but can’t, etc etc. Generally, I agree with the article’s sentiment. Don’t force a process, find what works for your employees. Get company buy-in. Set clear rules and goals. Hold folks accountable, and tell them to hold you accountable too.

anotherhue 6y ago

I used to think Jira was the problem, then at my current (small) company I became the Jira admin. Excellent, I thought. I will finally get to use this tool properly, set it up sensibly, and put to rest all the horrible experiences that are too common. I've been deep in the bowels, custom issue types, custom workflows, if it was accessible I've been in there. After six months of trying I believe it is unsalvageable. Adherents seem to suffer from a form of Stockholm-syndrome. * We have a small team, < 30 people, probably < 2000 issues. It is unacceptably slow. Performance is a joke and it keeps getting worse. No we don't have a dozen integrations. * Next-gen projects. Think Python2->3 confusion but for your entire company/workflow. Madness, short-sighted, and ultimately solely for the benefit of Atlassian, not the users. * "Premium" mode required to provide features that should be basic. Twice the price. No option to enable "Premium" on a per-user basis. So thousands of dollars for one PM to use a Gantt chart. * Pricing. I don't want to pay a full seat/month to allow a marketing person to put a ticket on an engineering backlog. Yes, they could go via a person but if you're going to mandate human mediation then why do we have the damn tool in the first place? This makes it exclusionary. * UI Design keeps getting worse. Necessary information is hidden at every possible opportunity. It's like they saw the Google whitespace focused redesigns from a few years back and felt personally threatened. * I refuse to accept that the cost of switching tools is too high, I've switched my teams over to Basecamp and we not longer feel like we are fighting our tools to do our jobs. * If you work somewhere where this level of process is required (medicine, military...) then Jira is not the right tool. If you don't need this level of process, then Jira is not the right tool. It is simply not the right tool.

ymbeld 6y ago

> Informing everyone, right down to the janitors (and all respect to janitors) where we are going and why. But it isn’t a coincidence that you chose to single out the janitors as those who are “down”.

ojciecczas 6y ago

Nah.