5 ms·

I’ve become extremely apathetic towards Agile. Whatever, this how a company needs to manage it, fine. I’m not wasting time wrapping my head around it. Tshirt si

I’ve become extremely apathetic towards Agile. Whatever, this how a company needs to manage it, fine. I’m not wasting time wrapping my head around it. Tshirt size or point poker stuff or ‘As a developer, I would like to’ stories, like seriously, whatever. It’s not going anywhere and doesn’t always make sense, so I just suck it up and truck along. Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks.

ketamine__ 7y ago
Jira is hell. There are now multiple boards, issues cloned from one board to another, and tons of lanes. We'll probably add more because documenting every detail is now the goal. We are a small team that is spending many hours per week having discussions on process. We even hired a consultant to come in and evaluate things. Jira seems to help stakeholders and product owners conceptualize the work and timelines but I see zero productivity gains from continuously evaluating and tweaking Jira.
- elric 7y ago
  Jira is just a tool. Blame the players, not the game. Or, in this case; the users, not the tool. Developers just want to know what they're supposed to be working on. Managerial types want to know what people are working on, when things will be done, and goodness knows what else. You obviously need to give developers the room and time to get actual development done. But at the same time, unless you work for a truly tiny company, there's always going to be some level of crap reporting that feels useless to most developers, but is important to someone else. It's hard to strike a balance that works for everyone.
  - willis936 7y ago
    When the shape of the tool is bloat and unnecessary overhead, is it still not the tool’s fault?
  - eberyvody 7y ago
    blaming the user does not feel like a winning strategy, idk. totally agree that it's a bad tool. a previous team i was on used github issues with a labeling system then switched to jira when we wanted to "get serious". my est is that we had a 50% decrease in issue quality and it shifted from 50% -> 90% of issues written by PMs and managers vs ICs who had a finer grained understanding of high leverage (impact/effort) tasks. i really do blame 1) the shittyness (er... "complexity", er... "power") of the UI and 2) the strict sprint-gaming behavior it encourages. i love a strong PM/EM for directing the team towards business value, but less so for enumerating and prioritizing the micro-tactics to get there. edit/disclaimer: i admit i'm super biased, but i've thought about this a lot working on a competitor of sorts.
deanCommie 7y ago
The thing is, it's not all about you. Source: I am a developer like you that has the exact same instinctual attitude about it. Here is why it's wrong. Project managers need to build schedules so they could coordinate dependent features across multiple teams. Marketing needs to orchestrate launch announcements and fixed activities that are not quite as inflexible as printing millions of CD-ROMs, but still require dates. And managers, ultimately, are held responsible for a project delivery, so they need to track it's progress, understand what things are ahead (lol) or behind (yup), which areas need help from more people, more seniority, or less scope. All of this needs to come together for any successful project of any reasonable complexity. None of this is new, or news to you, of course. Here's the part you're missing: The way things USED to work was that PMs, Marketing, Sales, and Managers would come up with processes that worked for them, and forced it on development teams, regardless of how it made the devs feel. Agile was an attempt for the developers to take ownership of their process bottoms-up. Planning poker, standups, sprints, all these ideas were invented by developers to make their lives EASIER not harder. And none of it was supposed to be panacea - the only way to do things. Each team is supposed to figure out the right balance of what works for them. So don't be apathetic. You are an active contributor to this process. Take pride in the fact that you have a lot of autonomy about how to define your project structure in an agile environment. Change what you don't like, and figure out what works the best for your team.* * Giant fucking asterix: I understand plenty of companies are extremely top-down and inflexible about "AGILE" development processes. They paid some consultants millions of dollars to define a process, and they're going to force their development teams to follow it regardless of what the front line devs want. If that is what is happening at your org, I'm sorry, that is truly unfortunate. But by and large, I find that even at companies where the devs have plenty of autonomy to define their process, they still grump about the very idea of having be forced to provide status updates or work in atomic chunks of effort and keep their software constantly releasable.
- TsomArp 7y ago
  Before the Agile manifesto, before Scrum/XP/Lean became popular, I had my own way of delivering software which basically was: meet with users/stakeholders, talk about what they need, build a first version in 2 to 4 weeks, release, test, adjust, repeat. For me it makes so much sense agile that I don't get why some devs don't understand the beauty and simplicity of it. If you want to know more about the why of the standup, and what is the idea behind it, read Borland's tell: https://www.scruminc.com/origins-daily-standup/ https://www.scruminc.com/origins-daily-standup/
cle 7y ago
> Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks. Working with you might be as painful for others as working with agile is for you... All these things (scrum, agile, etc.) are just mechanisms for working effectively as a group. Like all tools, some work better in certain situations than others, and they should be adopted deliberately with an understanding of the tradeoffs. This is traditionally where "management" falls short. It doesn't have to be this way. Accept that there are no silver bullets or always-correct methodologies, just a hodgepodge of techniques for helping people work better together.
- runawaybottle 7y ago
  Like everything in life, depends on who’s asking.
- oxfordmale 7y ago
  The problem is that is now how Scrum is sold. If you claim Scrum doesn't work for your particular team/project, the usual answer is that you are not implementing Scrum correctly.

ketamine__ 7y ago

Jira is hell. There are now multiple boards, issues cloned from one board to another, and tons of lanes. We'll probably add more because documenting every detail is now the goal. We are a small team that is spending many hours per week having discussions on process. We even hired a consultant to come in and evaluate things. Jira seems to help stakeholders and product owners conceptualize the work and timelines but I see zero productivity gains from continuously evaluating and tweaking Jira.

elric 7y ago
Jira is just a tool. Blame the players, not the game. Or, in this case; the users, not the tool. Developers just want to know what they're supposed to be working on. Managerial types want to know what people are working on, when things will be done, and goodness knows what else. You obviously need to give developers the room and time to get actual development done. But at the same time, unless you work for a truly tiny company, there's always going to be some level of crap reporting that feels useless to most developers, but is important to someone else. It's hard to strike a balance that works for everyone.
- willis936 7y ago
  When the shape of the tool is bloat and unnecessary overhead, is it still not the tool’s fault?
- eberyvody 7y ago
  blaming the user does not feel like a winning strategy, idk. totally agree that it's a bad tool. a previous team i was on used github issues with a labeling system then switched to jira when we wanted to "get serious". my est is that we had a 50% decrease in issue quality and it shifted from 50% -> 90% of issues written by PMs and managers vs ICs who had a finer grained understanding of high leverage (impact/effort) tasks. i really do blame 1) the shittyness (er... "complexity", er... "power") of the UI and 2) the strict sprint-gaming behavior it encourages. i love a strong PM/EM for directing the team towards business value, but less so for enumerating and prioritizing the micro-tactics to get there. edit/disclaimer: i admit i'm super biased, but i've thought about this a lot working on a competitor of sorts.

deanCommie 7y ago

The thing is, it's not all about you. Source: I am a developer like you that has the exact same instinctual attitude about it. Here is why it's wrong. Project managers need to build schedules so they could coordinate dependent features across multiple teams. Marketing needs to orchestrate launch announcements and fixed activities that are not quite as inflexible as printing millions of CD-ROMs, but still require dates. And managers, ultimately, are held responsible for a project delivery, so they need to track it's progress, understand what things are ahead (lol) or behind (yup), which areas need help from more people, more seniority, or less scope. All of this needs to come together for any successful project of any reasonable complexity. None of this is new, or news to you, of course. Here's the part you're missing: The way things USED to work was that PMs, Marketing, Sales, and Managers would come up with processes that worked for them, and forced it on development teams, regardless of how it made the devs feel. Agile was an attempt for the developers to take ownership of their process bottoms-up. Planning poker, standups, sprints, all these ideas were invented by developers to make their lives EASIER not harder. And none of it was supposed to be panacea - the only way to do things. Each team is supposed to figure out the right balance of what works for them. So don't be apathetic. You are an active contributor to this process. Take pride in the fact that you have a lot of autonomy about how to define your project structure in an agile environment. Change what you don't like, and figure out what works the best for your team.* * Giant fucking asterix: I understand plenty of companies are extremely top-down and inflexible about "AGILE" development processes. They paid some consultants millions of dollars to define a process, and they're going to force their development teams to follow it regardless of what the front line devs want. If that is what is happening at your org, I'm sorry, that is truly unfortunate. But by and large, I find that even at companies where the devs have plenty of autonomy to define their process, they still grump about the very idea of having be forced to provide status updates or work in atomic chunks of effort and keep their software constantly releasable.

TsomArp 7y ago
Before the Agile manifesto, before Scrum/XP/Lean became popular, I had my own way of delivering software which basically was: meet with users/stakeholders, talk about what they need, build a first version in 2 to 4 weeks, release, test, adjust, repeat. For me it makes so much sense agile that I don't get why some devs don't understand the beauty and simplicity of it. If you want to know more about the why of the standup, and what is the idea behind it, read Borland's tell: https://www.scruminc.com/origins-daily-standup/ https://www.scruminc.com/origins-daily-standup/

cle 7y ago

> Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks. Working with you might be as painful for others as working with agile is for you... All these things (scrum, agile, etc.) are just mechanisms for working effectively as a group. Like all tools, some work better in certain situations than others, and they should be adopted deliberately with an understanding of the tradeoffs. This is traditionally where "management" falls short. It doesn't have to be this way. Accept that there are no silver bullets or always-correct methodologies, just a hodgepodge of techniques for helping people work better together.

runawaybottle 7y ago
Like everything in life, depends on who’s asking.
oxfordmale 7y ago
The problem is that is now how Scrum is sold. If you claim Scrum doesn't work for your particular team/project, the usual answer is that you are not implementing Scrum correctly.