The Process Is Not the Product. The New Agile Anti-Manifesto
medium.com
medium.com
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.
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.
> 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.
We don't have anything even resembling to this in our company, and we use Jira. Again: Jira is a relatively good tool for storing information that's related to a certain piece of work. If you don't think that the context for any work should be documented, then don't do it, but we have learned it the hard way that code changes without business and technical context are not great, because in 5 years you might have a completely different set of people working on the codebase and they sometimes need to ask why this code was ever created. This is the context we store in Jira, and we could store it on a wiki, in Asana, etc. but Jira works just as well and again: it has brilliant integrations to everything.
Yeah, performance is not great but it's getting better nowadays. There are faster tools out there, but we considered integrations to be more important (YMMV ofc.).
I've worked in 6 or 7 companies that used Jira across a variety of different industries, and Jira was terrible in all of them; one of them was a previously excellent company that made a switch to using Jira, and that distinctly coincided with the company becoming worse to work with in many ways.
> Again, Java or Javascript are also a good example: I am relatively sure that crappy Java code is much more common than crappy Clojure or Haskell code. Does it mean Haskell is 'better' than Java
All else being equal, yes. You can make an argument that Haskell etc. attract better programmers because they're hard to learn, but it's hard to make a corresponding argument about Jira; how much time and effort does it take to not use something?
> We don't have anything even resembling to this in our company, and we use Jira. Again: Jira is a relatively good tool for storing information that's related to a certain piece of work.
Well, a) I'm pretty sure that's not how most companies use it, and b) I don't think it's very well suited to that either. Its IDs are the worst of both worlds (not a simple number but not actually informative either) and its search function is awful, so it's vastly inferior to using a wiki (a real one, not Confluence).
> Yeah, performance is not great but it's getting better nowadays. There are faster tools out there, but we considered integrations to be more important (YMMV ofc.).
Most places I've worked disabled most integrations due to performance problems, so I may be missing some of your experiences, but I don't understand what and how you're integrating if you're only using it as a store of information.
Now the good part is that you don't actually have to use all those customizations if your company doesn't 'need' that much process. Whether you have a Todo-In progress-Done workflow or Backlog-Ready for Dev-In Progress-Code review-Ready for QA-In QA-In Regression-Ready to merge-Merged to integration branch-In Integration Testing-Ready for master-Merged to master-Released to Prod workflow is up to you!
Yes, the tool was called "Jira".
That's actually better than my experience of the "simple workflow action" approach, where the fields you need to change aren't available, because you clicked the wrong action at the wrong time or did the wrong thing three actions back. And since there's no way to undo an action or return to the previous screen, you're stuffed. If you're lucky you might be able to find a manager who's able to do some other transition or define a new transition to fix your problem. More likely you have to throw that task away and recreate it from scratch. Oh, and there's no way to close the copy that's in the wrong state, so it's in your to-do list forever now.
> Now the good part is that you don't actually have to use all those customizations if your company doesn't 'need' that much process. Whether you have a Todo-In progress-Done workflow or Backlog-Ready for Dev-In Progress-Code review-Ready for QA-In QA-In Regression-Ready to merge-Merged to integration branch-In Integration Testing-Ready for master-Merged to master-Released to Prod workflow is up to you!
You need customization to have any workflow available at all - that was what I said about hoping a manager thought of what you were trying to do first. You want to put your In progress thing back to Todo? To bad, you can't. Accidentally marked something as Ready for QA when it isn't? Tough, no undo. Etc.
Jiras standard workflow is literraly Todo-In progress-Done and you can transition from any state to any state and edit any fields you want at any time.
Don't blame the tool. You said you needed an axe to chop wood to stay warm. Is it the axe's fault if you go kill your neighbor with it?
We use Jira and we have none of the problems you describe. We also have it integrated with a bunch of other tools we use and it gives us a really good overview of where we are at with things, looking up the Why behind a code change etc.
FWIW we do use a more elaborate workflow but it works well and parts of it are so that you can see if something it out with customers or not and those transitions are automated and done by our deployment scripts.
There may be predefined transitions between all the predefined states. But as soon as you add a new state you do not get any transitions to/from it except those you explicitly define. Any custom step that you define will not be undoable unless you explicitly define a way to undo it, and Jira will give you no help at all in ensuring that your undo transition actually undoes.
> Don't blame the tool. You said you needed an axe to chop wood to stay warm. Is it the axe's fault if you go kill your neighbor with it?
If the axe keeps slipping in people's hands and they keep chopping off their fingers, that's a problem with the axe. Even if there's one guy who doesn't have that problem and thinks everyone else must've been holding it wrong, it's still a badly designed axe.
> We use Jira and we have none of the problems you describe. We also have it integrated with a bunch of other tools we use and it gives us a really good overview of where we are at with things, looking up the Why behind a code change etc.
Who maintains your Jira workflows, and what's the process for making changes to them? I guarantee you're doing something unusual, because like I said, I've seen Jira in five or six companies and it was bad in all of them. (Blind guess: at your company the people who are actually using it are empowered to make changes to the workflows, which is very much not the default and not what Jira's permissioning system guides you towards).
I don't envy you and I feel for you. It does not have to be that way but you also can't blame Atlassian for letting those sorts of companies, which let's face it are larger companies with more licenses bought, buy Jira and catering to them. However, Atlassian has kept things very very simple and open enough that you don't have to be a victim of that.
> Who maintains your Jira workflows, and what's the process for making changes to them? I guarantee you're doing something unusual, because like I said, I've seen Jira in five or six companies and it was bad in all of them. (Blind guess: at your company the people who are actually using it are empowered to make changes to the workflows, which is very much not the default and not what Jira's permissioning system guides you towards).
I do have to give you this, Jira is not great for empowering people to make their own changes to workflows and such, so you _are_ entirely at the mercy of your company. They are sort of changing some of this with at least Jira Cloud and the new issue view (which I hate with a vengeance for the most part) in that you can both "pin" fields yourself on a per project basis (which is bad, because in our case I want the same ones pinned in all projects, as they all share the same issue types and workflows but there's a project per product we have) and you can move fields between the left and right context (or removed from screen) without having to be a Jira admin. It's still lacking in many ways though. Just so you know, I'm not saying Jira is the best tool ever out there and everything is perfect about it. I'm just saying that your company misusing it doesn't mean that the tool isn't valuable and doesn't have some great features. Did you know that Jira since not too long ago allows story points to have floating point values now, because so many people requested it? That is absolute utter BS and not in line with any agile methodology I've ever come across. But I guess this is where I have to refer back to Money, Money, Money ... :)
FWIW I've been both at companies where other people were Jira admins and to get something changed you had to go through someone else and where I was the admin. Sometimes the changes requested were denied. In other cases, even within a large (10k+ employees) companies, we just had our own Jira for the project and I was actually (one of the few) Jira admin(s). At my current company I am not but most things are actually configured just as they should be. If you want something changed, you ask for it and it's usually not a problem and the stuff they're putting in is not crazy.
Would you rather have a centrally managed IBM Remedy? :)
P.S.: And just on the axe, I think it depends. Is it a standard axe with a hickory handle? By default that definitely doesn't slip. Oh you say you oiled it so much that it slips all the time now? Not the axe's fault!
Ideally I'd like to be able to revert to the state as of a specific point in history - JIRA has an "activity log" that shows that it keeps all the history of transitions, but unlike say a wiki I can't just click on one of them and say "reset it to this version". Obviously that doesn't solve everything if your transitions have done something non-idempotent in external systems, but it would cover a lot of cases.
TBH all I really need is a way to undo the last action, for the case of "oh shit I didn't mean to click that" or "oh shit my mouse slipped and I dragged it to the wrong column" - or worse still, because the column I was dragging it to changed midflight because of JIRA's ridiculous performance issues. Again obviously that could go wrong if there's an external integration involved, but I'm ok with enabling confirmation for transitions that are going to make a change to an external system (I might even be ok with enabling it for every transition if I didn't have to drag a card through five different states one by one and wait 30s for the UI to unfreeze each time). But being able to irreversibly screw an issue up just by dropping it in the wrong place is not cool. (My current company has one of the less bad Jira setups I've used, but I still have a task that I can't see on my open issues view because I accidentally dragged it into some kind of fixed/resolved/closed state, and even though it's now back in the right state, its Resolution isn't Unresolved and there's no way to put it back to that).
> Would you rather have a centrally managed IBM Remedy? :)
I've not used that. I've had a much better time using Trello, Trac, or even (going back a few years now) Bugzilla to fill the same role. Yes, they don't do as much as JIRA, but I really think that's actually a downside. More concretely I think capturing requirements/planning/roadmaps and tracking the status of work in progress are actually separate things that should be done separately, and the fact that JIRA tries to do both is part of what makes it so complex and slow.
I am not sure about it at all.
> attract better programmers because they're hard to learn
This also biases demographic toward people who care more about proving they can do hard code then those who want to produce maintainable software. That does not lead to better code.
For example, there is no reason why each transition in the workflow couldn't simply have a corresponding counter-transition: "Start development" / "Abort development"; "Move to test" / "Return to development" (not the same as "Test failed"); "Test OK" / "Test again"; "Close" / "Reopen". And the excessive fields almost certainly can be removed from the form, so you could reduce the entire thing to Title + Description + State + Assigned To.
You are right that most companies don't do this. That's because in most companies the management decides how Jira should be configured... and their preference is for "more data" because it gives them the illusion of control, and they don't really care how much extra paperwork this means for the developers.
Well, we could perhaps blame Jira for having the wrong defaults. But even where Jira has the right defaults, the management often decides to override them.
For example, Jira allows to split tasks to subtasks, but by default this functionality is disabled, and the documentation argues strongly against it. (The recommended way to use Jira is that the tasks are atomic, and you have a database of tasks. To relate tasks to each other, use links or tags or epics; all of them optional.) Yet, most managers insist that tasks must be divided to subtasks. And then you get the usual "one subtask per each task" or "analysis, development, and testing are subtasks, instead of steps in workflow", because that's how the management wanted it.
Then underlying reason is that developers and managers have different needs. Developers need a database of bugs, and a short list of tasks to be done. Managers want as much information as possible (no matter whether the information makes sense or not, because they don't understand half of it anyway), plus time tracking (to push people to work faster), plus something that would reduce their need to plan and check how the plan progresses... and if they can outsource all this work to developers, that makes their own work more convenient. Which is why the Jira is configured the way it usually is. But the same thing will happen with any other tool... and if the tool would not allow such abuse, then the management would not allow the tool.
There isn't, but you have to manually maintain them, and inevitably they get out of sync.
> But the same thing will happen with any other tool... and if the tool would not allow such abuse, then the management would not allow the tool.
Bad management insists on tools that let them manage badly, of which Jira is the prime example. It's not a bad tool in the sense of being badly coded, and on some level I can't blame Atlassian for making a tool that micromanagers love - I'm sure there's a huge market for that. But precisely because it's designed to give bad managers what they want first and foremost, it's a red flag in a working environment.
I've never seen that with other less flexible bug tracking tools.
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.
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!indented 1 (blanks squeezed out)
indented 2
indented 3Just like wearing a tie is dangerous when you're adding a cooling fan to your cpu. :)
See the documentation: https://news.ycombinator.com/formatdoc
You need to really understand your tools. If people tried to use power tools the way they use computer tools there would be missing fingers everywhere.
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.
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.
"And my teenage nephew could do the same thing in PHP in a weekend."
(But for some mysterious reason they never fire their developer team and hire the nephew instead.)
Think Rockets, Cars, large hardware projects, large software projects where a dozen teams are required to implement GDPR for their services etc.
When this role is placed in a small team of 8-20 engineers it just adds more status update burden to the team, the engineers can more effectively communicate with each other than through a TPM and so the only role the TPM can fill is "pushing". If one can assume that engineers don't choose to slack off whenever someone isn't looking - then pushing just means extra hours, burnout, and missed dates.
Isn't this what traditionally most managers were doing?
I remember my first job, decades ago, before agile was a thing, when I had this interaction with my boss constantly: "How long is this new feature going to take?" "Not sure, probably three weeks." "Are you absolutely sure it can't be done in two weeks?" "Well, I guess in the lucky case it might be possible, but..." "Great, so two weeks it is." Then complaining about how I said two weeks and broke my promise, when it actually took two weeks and a half.
The only difference is that now you can do it with numbers, so it seems more "scientific", even if all numbers are ultimately just guesses.
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.
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.
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...
It can, but it (almost always) isn't. Previous discussion:
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.
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.
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.
imagine management asking surgeons to cut corners and water down disinfectants, the lawsuit would be _legendary_
Like, 9 women cannot give birth to a baby in one month.
How did we get this bad? Is it our education? Computer science isn't really even science let alone engineering. It's more like a branch of pure mathematics. As a result people who should have been trained to make engineering tradeoffs instead obsess about things that don't matter to the job they are actually doing.
Software engineering is more online and connected than most professions. A lot of devs grew up in an era where building your personal brand was touted as the most important thing you could do for your career. They watched certain peers vault themselves into local fame and maybe fortune by going all-in on Angular or React or Go or Rust or Bitcoin at just the right time. In some cases, being dogmatic or cult-like about something and spreading the mentality that it’s the best option without tradeoffs becomes a self-fulfilling prophecy.
If enough people spend enough time declaring microservices or agile or Bitcoin to be the one true solution, it starts to become accepted as true. Those who were at the forefront of promoting it stand to gain a lot by being there first and establishing themselves as experts in the field.
I see contrarianism in small parts of most fields, but software seems to uniquely reward contrarianism. Agile was the contrarian methodology until it became popular, at which point anti-Agile became contrarian and is now growing in popularity.
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.
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.
I get the frustration. Imposed process smells of poor management. But process and management can’t just be wished away.
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.
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).
Medicine presents a higher level of complexity than software. I'm not putting "in my opinion" in that statement, ample publications on the topic.
You can rebuild and recompile software, not living systems.
Start with cell biology, build up to organisms, add politics, money, regulation, sprinkle with some liability and soft human factors. It is unknowns upon unknowables all the way down and up.
And to be clear, I'm not trying to make some point or argue some position, just genuinely curious and think this is an interesting consideration.
Software is implemented on automated systems we understand, build, and can predict at some level of performance. Medicine is built with humans, to work on humans (which we can't predict nor understand fully, let alone build like we do computers and software), and on top of that, uses software (and lots more).
Software does not exist in a vacuum, some recent examples of the unanticipated effects of systems complexity in software could include
a) political radicalization of facebook and youtube users through algorithms designed for a completely different goal, maximizing screen-time b) the simplest case, citibank losing millions because of bad UI design (not taking the human user into the design).
So medicine, from a systems standpoint, is not that structurally/conceptually different from software. It is researched, designed and practiced/used by humans, just like software. Some of the reasons medicine is more complex is that it is, at the moment, dealing with more living systems than software (medicine: attempting to influence complex performance on the biological level. Software: for end-users, interact/affect on the psychological, conscious level).
At the moment, medicine is more complex than the software industry. As software continues eating the world, that will change, as nanobots, brain-imitating processors, etc, arrive.
I am at the moment looking at a cluster-fuck of improving a tiny process for a regional medical complex, and the staggering complexity is outside of anything I had to deal with while working in finance and distributed computing, and those software systems were more complex than what got humans into space.
We know the lessons from space and atomic projects - have a mandate, financial and political commitment, theoretical and societal backing. But getting matter to controlled fission or orbit sure appears easier than even understanding cancer, let alone eliminating it, as history so far has shown us.
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.
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.
> Individuals and interactions over processes and tools
> Customer collaboration over contract negotiation
But it isn’t a coincidence that you chose to single out the janitors as those who are “down”.
These kind of things have to stand on their own.
Hopefully the medium (lower case) shouldn't affect the message.
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!"