4 ms·

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

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/
- oxfordmale 7y ago
  Being Agile has often little to do with being agile. True "agile" development has nothing to do with story points, daily stand up, bi-weekly planning poker sessions, retrospectives, spikes, scrum masters, etc, etc
- FZ1 7y ago
  The origin of the "standup" is just a regular daily coordination meeting - like thousands of organizations have always had. Ever heard of a "morning sales meeting"? They've existed for decades - short, to the point, 15-20 min. No one's ever heard of scrum in sales meetings. This kind of thing exists in hundreds of other businesses as well. Much like everything else in scrum, they are just trying to take credit for something people already did - so they can package it and sell it back to people as if it were a novel idea. There's nothing new or special about scrum - except a reduction in productivity because of the additional overhead and meetings.
- loopz 7y ago
  So it's a copy of a copy (Borland team), of something entirely unrelated (rugby). Also, it's for "our own good" and "we should own the process ourselves". While saner interpretations of AM are to be strictly verboten. Only time I've seen such meetings not devolve into a status meeting, is when PM actively sought to cast light on potential issues and inquired about who need information, etc. This was effectively rooted out when SAFe came and eliminated PM-role entirely, while hiding discovery and decisionmaking processes, keeping them secret. Of course, past poster child examples have nothing to do with Attention- and Selection bias either.
runawaybottle 7y ago
So in response, I’ll reiterate. I know it’s not all about me, so I shut up, tshirt size (point poker? - what is a cute an analogy? How about it’s not getting done this week? Okay not so cute. Maybe I need to think about it? What is the cute analogy there? A spike. What’s that? ‘It’s when an asshole can’t just do the simple get shit done thing and wants to .. ah fuck it, it’s a spike, cost of business, accept the user story). I can’t play this semantics game. I don’t care how you want to measure it. Business: But now we know where the spikes come from Gotta be smart about this devs, this ain’t rigged to your favor. Truck along, give your points and user stories, but if you want to be measured on a bullshit scale it’s at your own folly. Game it.
- matthewmacleod 7y ago
  I don't even really understand your objections here. You're describing various tools that are useful in some situations to get the various developer and business outcomes you want. Planning poker is useful for exposing different interpretations of a task from the perspective of multiple developers while trying to avoid group pressure or prejudiced outcomes. Spikes are tools that allow developers to explore a problem space and gain information about whether a proposed approach to a bigger problem is feasible and how much work might be involved. And story points are there to help the development team understand how much work they are able to get through in a period of time, to help improve estimates or targets that are useful for themselves and other parts of the business. I'm really sorry if you've had a bad time with this stuff, but none of it is unreasonable or particularly outlandish – and personally everything you've highlighted has been extremely useful to me as a developer. Like all tools they can be abused; the problem there is a broken organisation, and not a broken tool.
  - runawaybottle 7y ago
    We can drill down. Let’s take moronic point poker. Let’s say I want to give a task to a new developer. He decides it’s tough and gives a high estimate. The rest of the devs give a lower estimate. Ok, what got achieved? We just pressured the new dev into what exactly? He gave his estimate. I don’t know, you’re all brilliant so fill me in. Most likely the new dev will lie under pressure and give a lower estimate. This is what really happens in real life. These mechanisms are so unrealistic. It’s ritual at this point.
rasteau 7y ago
For most scenarios where estimates are asked of development, there's usually an alternative approach that will yield better results. Cost-benefit analysis scenario: Request: We need to know how long it will take to build X so we can decide if we want to build it. Response: What is the maximum amount of time to build X, such that if it took any longer, you wouldn't have us build it? Rationale: Estimating whether a project will be over/under a time given frame is more likely to be accurate than estimating a specific span of time. Dependencies scenario: Request: We need to know how long it will take to build X because marketing needs to know when to start preparing. Response: What is the amount of time marketing needs to prepare? Rationale: Estimating that development is some amount of time away from completing is more likely to be accurate than estimating the entire project. ---- Underlying most arguments for estimates from development is an unwillingness by those doing the asking to do their own estimation.
luckyscs 7y ago
Furthermore, and I find it odd that us smarty pants math people keep forgetting this. Numbers make decisions easily justifiable. Those story points, those days tracking roadblocks. All that data, weather it's wrong or right, allows people to make decisions where they would otherwise have to justify with nebulous reasoning. The down side is, our point keep doesn't explain the reasoning behind delays and other bad numbers. Hopefully, we get better at quantizing this shit, but it's not going to go away. Their is something like a gravitational force in accountability. Those who can shirk it, to others or to numbers, must shirk it to have more power. And honestly I'd rather blame numbers rather than people, the impersonality of bad numbers allows you retro without personal attacks and defensiveness, which allows more rapid improvement.
- runawaybottle 7y ago
  So here’s a question for you. I notice that during our sprint planning, some team members create almost 50 user stories. I probably create 1/6 of that. Do you think it would bode well for me to create more user stories so that I can mark it as ‘done’, so when the numbers are rolled up I can look great and avoid the mass culling that seems to be a forgone conclusion given the system that encourages this kinda nonsense?
  - deanCommie 7y ago
    That's not how...any of that works. 1 - their stories are likely smaller than yours. 2 - you estimate TOGETHER, in a shared common estimation system 3 - what is meant to be tracked is the total collective TEAM velocity, not the velocity of an individual team member
  - rumanator 7y ago
    > Do you think it would bode well for me to create more user stories so that I can mark it as ‘done’ User stories are only a way to gather requirements for a feature and set a definition of done. They have nothing to do with productivity.

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/

oxfordmale 7y ago
Being Agile has often little to do with being agile. True "agile" development has nothing to do with story points, daily stand up, bi-weekly planning poker sessions, retrospectives, spikes, scrum masters, etc, etc
FZ1 7y ago
The origin of the "standup" is just a regular daily coordination meeting - like thousands of organizations have always had. Ever heard of a "morning sales meeting"? They've existed for decades - short, to the point, 15-20 min. No one's ever heard of scrum in sales meetings. This kind of thing exists in hundreds of other businesses as well. Much like everything else in scrum, they are just trying to take credit for something people already did - so they can package it and sell it back to people as if it were a novel idea. There's nothing new or special about scrum - except a reduction in productivity because of the additional overhead and meetings.
loopz 7y ago
So it's a copy of a copy (Borland team), of something entirely unrelated (rugby). Also, it's for "our own good" and "we should own the process ourselves". While saner interpretations of AM are to be strictly verboten. Only time I've seen such meetings not devolve into a status meeting, is when PM actively sought to cast light on potential issues and inquired about who need information, etc. This was effectively rooted out when SAFe came and eliminated PM-role entirely, while hiding discovery and decisionmaking processes, keeping them secret. Of course, past poster child examples have nothing to do with Attention- and Selection bias either.

runawaybottle 7y ago

So in response, I’ll reiterate. I know it’s not all about me, so I shut up, tshirt size (point poker? - what is a cute an analogy? How about it’s not getting done this week? Okay not so cute. Maybe I need to think about it? What is the cute analogy there? A spike. What’s that? ‘It’s when an asshole can’t just do the simple get shit done thing and wants to .. ah fuck it, it’s a spike, cost of business, accept the user story). I can’t play this semantics game. I don’t care how you want to measure it. Business: But now we know where the spikes come from Gotta be smart about this devs, this ain’t rigged to your favor. Truck along, give your points and user stories, but if you want to be measured on a bullshit scale it’s at your own folly. Game it.

matthewmacleod 7y ago
I don't even really understand your objections here. You're describing various tools that are useful in some situations to get the various developer and business outcomes you want. Planning poker is useful for exposing different interpretations of a task from the perspective of multiple developers while trying to avoid group pressure or prejudiced outcomes. Spikes are tools that allow developers to explore a problem space and gain information about whether a proposed approach to a bigger problem is feasible and how much work might be involved. And story points are there to help the development team understand how much work they are able to get through in a period of time, to help improve estimates or targets that are useful for themselves and other parts of the business. I'm really sorry if you've had a bad time with this stuff, but none of it is unreasonable or particularly outlandish – and personally everything you've highlighted has been extremely useful to me as a developer. Like all tools they can be abused; the problem there is a broken organisation, and not a broken tool.
- runawaybottle 7y ago
  We can drill down. Let’s take moronic point poker. Let’s say I want to give a task to a new developer. He decides it’s tough and gives a high estimate. The rest of the devs give a lower estimate. Ok, what got achieved? We just pressured the new dev into what exactly? He gave his estimate. I don’t know, you’re all brilliant so fill me in. Most likely the new dev will lie under pressure and give a lower estimate. This is what really happens in real life. These mechanisms are so unrealistic. It’s ritual at this point.

rasteau 7y ago

For most scenarios where estimates are asked of development, there's usually an alternative approach that will yield better results. Cost-benefit analysis scenario: Request: We need to know how long it will take to build X so we can decide if we want to build it. Response: What is the maximum amount of time to build X, such that if it took any longer, you wouldn't have us build it? Rationale: Estimating whether a project will be over/under a time given frame is more likely to be accurate than estimating a specific span of time. Dependencies scenario: Request: We need to know how long it will take to build X because marketing needs to know when to start preparing. Response: What is the amount of time marketing needs to prepare? Rationale: Estimating that development is some amount of time away from completing is more likely to be accurate than estimating the entire project. ---- Underlying most arguments for estimates from development is an unwillingness by those doing the asking to do their own estimation.

luckyscs 7y ago

Furthermore, and I find it odd that us smarty pants math people keep forgetting this. Numbers make decisions easily justifiable. Those story points, those days tracking roadblocks. All that data, weather it's wrong or right, allows people to make decisions where they would otherwise have to justify with nebulous reasoning. The down side is, our point keep doesn't explain the reasoning behind delays and other bad numbers. Hopefully, we get better at quantizing this shit, but it's not going to go away. Their is something like a gravitational force in accountability. Those who can shirk it, to others or to numbers, must shirk it to have more power. And honestly I'd rather blame numbers rather than people, the impersonality of bad numbers allows you retro without personal attacks and defensiveness, which allows more rapid improvement.

runawaybottle 7y ago
So here’s a question for you. I notice that during our sprint planning, some team members create almost 50 user stories. I probably create 1/6 of that. Do you think it would bode well for me to create more user stories so that I can mark it as ‘done’, so when the numbers are rolled up I can look great and avoid the mass culling that seems to be a forgone conclusion given the system that encourages this kinda nonsense?
- deanCommie 7y ago
  That's not how...any of that works. 1 - their stories are likely smaller than yours. 2 - you estimate TOGETHER, in a shared common estimation system 3 - what is meant to be tracked is the total collective TEAM velocity, not the velocity of an individual team member
- rumanator 7y ago
  > Do you think it would bode well for me to create more user stories so that I can mark it as ‘done’ User stories are only a way to gather requirements for a feature and set a definition of done. They have nothing to do with productivity.