To be honest, neither Hexbear nor Lemmygrad has caused any noticable issues for lemm.ee. I recently compiled some stats for lemm.ee rule breakers by home instance, and as you can see in this post (in the “Administration” section), neither of those instances even made the top 10.
In general, mods haven’t complained about those two instances either, and the stats for community bans by independent community mods are more or less very similar. If any users creates issues in a lemm.ee community, then the community mods are free to just ban those users, regardless of what instance their account is hosted on.
if fact I wouldn’t even be able to as my home instance is defederated from these instances and thus such posts would be invisible to me
Preventing such situations for lemm.ee mods is actually one of the many reasons we don’t want to use defederation as a moderation tool on lemm.ee - we rather use site bans etc. Too much collateral damage with defederation, especially when dealing with larger instances which probably have vastly more innocent users than problematic ones. We reserve defederation for more extreme cases, like spam instances & CSAM.
I think there are two separate things I want to address here:
First, agile isn’t a project management methodology, it’s just a set of 4 abstract priorities and 12 abstract principles. It’s very short, you can check it out here:
https://agilemanifesto.org/
Nothing here says that you’re not allowed to write documentation, write down requirements, etc. In fact, the principles encourage you yourself as a software team to create the exact processes and documentation that you need in order to meet your goals.
“Working software over comprehensive documentation” does not mean you aren’t allowed to have documentation, it just means that you should only write documentation if it helps you build working software, rather than writing documentation for the sake of bureaucracy.
“Individuals and interactions over processes and tools” does not mean that you should have no processes, it just means that the individuals in your team should be empowered to collaboratively create whatever processes you need to deliver good software.
Secondly, in terms of practical advice:
a. You have metrics about how your system is used.
b. You have automated tests covering any requirements, so that you can feel confident when making changes to one part of the system that it isn’t violating any unrelated requirements.
c. You actually document any confusing parts in the code itself using comments. The most important thing to cover in comments is “why is this logic necessary?” - whenever something is confusing, you need to answer this question with a comment. Otherwise, the system becomes very annoying to change later on.
If you are missing any of the above, then propose to your team that you start doing it ASAP