> Agile is not always the answer can be generalised to: Agile is never the answer.
So whats the answer?
What I learned after managing a small team for 2 years
11–20 of 102 posts
Re: What I learned after managing a small team for 2 years
#12> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…
Not stuffing it into some horrible slow "enterprise" webapp would be a start.
Are we using the same Confluence and JIRA - I don't see it being slow as we use cloud.
Only times when it was slow it was long time ago when it was on premise and business always skipped upgrading any servers so admins had to run it on tight rope.
Re: What I learned after managing a small team for 2 years
#13"Don't change everything at once"
Sometimes one big change is better than constant small changes
Re: What I learned after managing a small team for 2 years
#14> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…
> What black magic do you have to cast to get devs to look at the documentation? README.md files in each repo, and code level documentation. The readme file can point to useful links, such as diagrams or stuffy documents where needed.
You don't put everything in README.md for the start - once file gets long enough no one will read it the same as bunch of confluence...
Links? Parent poster just mentioned he was putting relevant links in JIRA tickets - to work on a feature dev has to open the ticket anyway but suprise-suprise they were not clicking the links.
How on earth README.md links will help in such situation.
Re: What I learned after managing a small team for 2 years
#15> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…
> What black magic do you have to cast to get devs to look at the documentation?
That's not how documentation works (in my experience). Ignoring documentation is fine (perhaps I don't need documentation to get things done?). The problem is having the need of documentation and find that none exists; that's the real issue. If there's no documentation, as an engineer I have 2 options: a) read the codebase, b) ask around. Whatever option takes less time and is more accurate wins (and take into account that the code may contains bugs, so the code is not always a reflection of the intended business use cases... on the other hand no-one may know what the codebase is supposed to do).
Documentation is like having a fire extinguisher: hopefully you won't need it most of the time, but if in that single occasion that you need it you find none, well, imagine.
Re: What I learned after managing a small team for 2 years
#16Agile is not about sprints or ceremonies that is SCRUM.
Sprints don't have to be 2 weeks or more - if stuff changes weekly you do weekly sprints.
I just fail to see how one can build anything if priorities change on a daily basis. Most of the features I work on take 2 days at least with 3-5 days most. I can see how one might need to change priorities once a week because you see bunch of stuff built get someone to check it, plan new things that need to be done or adjusted.
I am quite experienced but to get meaningful feature worked out it is at least a day of work.
I can imagine if someone comes up with text changes, color changes or wants to move buttons around on the interface I could probably spit dozens of these in a day.
Re: What I learned after managing a small team for 2 years
#17Re: What I learned after managing a small team for 2 years
#18Earlier quoted context omitted.
> What black magic do you have to cast to get devs to look at the documentation? README.md files in each repo, and code level documentation. The readme file can point to useful links, such as diagrams or stuffy documents where needed.
You don't put everything in README.md for the start - once file gets long enough no one will read it the same as bunch of confluence... Links? Parent poster just mentioned he was putting relevant links in JIRA tickets - to work on a feature dev has to open the ticket anyway but suprise-suprise they were not clicking the links. How on earth README.md links will help in such situation.
Oh when i read documentation i think stuff relevant to getting things to run, architecture and perhaps a little more of whats relevant. Jira tickets and all can be correlated with a proper branching model. I agree, readme files should be concise.
Re: What I learned after managing a small team for 2 years
#19MVP: minimum viable process
I’ve worked for a few orgs as a TPM. If you can get by with a kanban board and weekly sync meetings, and everything else async, do that.
If you need more rigor or the team is big enough or developing software that would benefit from Scrum, then go for that.
Most importantly, get team input and buy-in. There’s no point in dictating process to teams if they’re not into it.
Re: What I learned after managing a small team for 2 years
#20Agile is not about sprints or ceremonies that is SCRUM. Sprints don't have to be 2 weeks or more - if stuff changes weekly you do weekly sprints. I just fail to see how one can build anything if priorities change on a daily basis. Most of the features I work on take 2 days at least with 3-5 days most. I can see how one might need to change priorities once a week because you see bunch of stuff built get someone to che…
[deleted]