5 ms·

Most project management frameworks are tricky. The best is to have no project management. Just a stream of ideas and high trust to prioritise effectively in an

by dijit 4y ago

Most project management frameworks are tricky. The best is to have no project management. Just a stream of ideas and high trust to prioritise effectively in an autonomous way. This only works when you have full alignment and everyone is competent at managing their own time and expectations. Invariably someone will get flustered with this approach because they need visibility or believe things to be unaligned and hamfist scrum into the process. They usually do this with Jira and then claim there’s no better software. So we have two bits of pain for the price of one. I really believe that we have a real lack of competence in project management in general; estimations are hard for sure, but reaching for tools without understanding trade offs is the kind of thing mid-level engineers do; seniors usually being marked by not adapting to tools but making tools work for their ends. This is all a digression and what I originally wanted to say was that IME; scrum is the cart leading the horse. Agile is also a difficult fit for something brand new; as how can you get user stories properly told without having users? but I think it’s quite good for refining something existing.

chaosbutters314 4y ago
excel is still the best project management tool I've used. jira is just a mess at this point
- Klinky 4y ago
  I agree that Jira is not the best project management tool, but it wasn't really designed to be one. It's not terrible a work tracking, but it seems to lacking in the roadmap/pre-planning departments that project/product should be using to feed developers work. That said, spreadsheets are also not great project management tools either, quickly becoming messy and out of date. Nor do I think relying on senior devs to roll their own project management tools is a good idea. I'd like to see more WBS(work breakdown structure) tools used to identify needs in advance and ways to monitor their implementation, testing & deployment. The industry's love affair with agile seems to lead to pre-planning & consistent structure being seen as "too waterfall". Basically it feels like no one does agile "correctly", and those that it's worked well for, likely have a workflow and product cycle that aligns with it well, but that may not be true for all products, tech, stacks, etc. Ultimately we're trying to answer these basic questions: What are we doing? Why are we doing it? How are we doing it? When will it be done? Is it actually done? If those questions cannot be answered easily there are probably gaps in your workflow.
MuffinFlavored 4y ago
> high trust What do you do if you work in an organization that is set up with scrum managers whose sole job it is is to run through tickets + follow up? "Hey developer, how is the progress on that ticket coming? Any blockers? When do you estimate it will be done? How many story points should it be? Should we pull it into the next sprint? Don't merge any code into the release branch for that ticket until we start the next sprint. Let's have a daily standup meeting, then let's have a weekly planning meeting for the next sprint." The scrum manager reports to the manager manager who reports to the director/VP who wants to see progress through releases/tickets, etc. etc. Like... how many HackerNews readers live this every day versus how many will say "if that was my 9am-5pm, I'd quit because it's a sign of ________ in an organization/corporation/team and I wouldn't stand for that. I only work for teams that let me do whatever I want with 0 observability into progress/ticket tracking".
- dijit 4y ago
  I mean, if you’re at that point then you’ve already failed the scenario I described. A scrum master is a symptom of lack of trust personified into a role. I’m sure some are servant leaders that seek to unblock, unify or enhance development; but that would be the exception. The causes for them being employed to begin with are likely lack of visibility or lack of trust in the ability of the team to understand what is a high priority.
AtomicOrbital 4y ago
Exactly ... agile fails on any project which requires pure research or exploratory hard problems which are above and beyond just grunt work ... Agile shops typically assume the work is predictable and just a function of redoing a known recipe

by dijit 4y ago

chaosbutters314 4y ago

excel is still the best project management tool I've used. jira is just a mess at this point

Klinky 4y ago
I agree that Jira is not the best project management tool, but it wasn't really designed to be one. It's not terrible a work tracking, but it seems to lacking in the roadmap/pre-planning departments that project/product should be using to feed developers work. That said, spreadsheets are also not great project management tools either, quickly becoming messy and out of date. Nor do I think relying on senior devs to roll their own project management tools is a good idea. I'd like to see more WBS(work breakdown structure) tools used to identify needs in advance and ways to monitor their implementation, testing & deployment. The industry's love affair with agile seems to lead to pre-planning & consistent structure being seen as "too waterfall". Basically it feels like no one does agile "correctly", and those that it's worked well for, likely have a workflow and product cycle that aligns with it well, but that may not be true for all products, tech, stacks, etc. Ultimately we're trying to answer these basic questions: What are we doing? Why are we doing it? How are we doing it? When will it be done? Is it actually done? If those questions cannot be answered easily there are probably gaps in your workflow.

MuffinFlavored 4y ago

> high trust What do you do if you work in an organization that is set up with scrum managers whose sole job it is is to run through tickets + follow up? "Hey developer, how is the progress on that ticket coming? Any blockers? When do you estimate it will be done? How many story points should it be? Should we pull it into the next sprint? Don't merge any code into the release branch for that ticket until we start the next sprint. Let's have a daily standup meeting, then let's have a weekly planning meeting for the next sprint." The scrum manager reports to the manager manager who reports to the director/VP who wants to see progress through releases/tickets, etc. etc. Like... how many HackerNews readers live this every day versus how many will say "if that was my 9am-5pm, I'd quit because it's a sign of ________ in an organization/corporation/team and I wouldn't stand for that. I only work for teams that let me do whatever I want with 0 observability into progress/ticket tracking".

dijit 4y ago
I mean, if you’re at that point then you’ve already failed the scenario I described. A scrum master is a symptom of lack of trust personified into a role. I’m sure some are servant leaders that seek to unblock, unify or enhance development; but that would be the exception. The causes for them being employed to begin with are likely lack of visibility or lack of trust in the ability of the team to understand what is a high priority.

AtomicOrbital 4y ago

Exactly ... agile fails on any project which requires pure research or exploratory hard problems which are above and beyond just grunt work ... Agile shops typically assume the work is predictable and just a function of redoing a known recipe