3 ms·

< rant > I want to see the code produced by this non-system; and to learn its longevity, particularly beyond when key early contributors have left. I want to s

< rant > I want to see the code produced by this non-system; and to learn its longevity, particularly beyond when key early contributors have left. I want to see the applications produced by that code and to learn the size of the teams, departments and companies around the products. This article carries little weight without some of that context. There's no meat to this article, just a rant about some management style the author doesn't like. The author goes so far as to say that only the managers can fail in software. This sounds unbelievable to me because we're all humans. Sprints, and points, are not JIRA. Points are not Sprints. Jira is not Scrum. These are all orthogonal tools that can work well together, in my experience. They don't always work well together. If you're doing Scrum well, you'll inspect what's working and what isn't, and change it. It's possible to change so far from Scrum you've moved on from it... but I haven't seen that happen and yet still found it useful in most places I've worked. People who dislike Scrum often complain that the defenders regularly say "well, you're not doing Scrum if you define it like that". They throw away the whole argument. Scrum that isn't Scrum, isn't scrum. You can't not-do a thing and then claim that thing doesn't work. < / rant >

P5fRxh5kUvp2th 4y ago
What proponents of agile have a tendency to do is take anything effective and call it "agile". I've literally had people say "you're doing agile even if you don't know it!". You can't nail them down, it's always "oh that works? yeah, that's agile. Oh, that doesn't work? you're not really doing agile". --- And now let me say, I don't like scrum because it's a shitty way to write software. There's really only 2 ideas in agile that are useful. 1. iterative development, and 2. evaluate and change That's it. The rest don't matter and are often actively harmful. You don't need scrum masters, PO's, sprints, story points, ad nauseum. Can they be useful? Maybe, it really depends on the scale and needs of what you're building, but I'm going to argue that outside of business analyst, these roles should be developers that take responsibilities. yeah yeah, inb4 "scrum master should be a developer!". Ask yourself this. What is the difference between a tech lead and a scrum master? answer: scrum master is considered a career, tech lead is considered a skilled developer. The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business.
- the_other 4y ago
  > That's it. The rest don't matter and are often actively harmful. Oh, ok. It's a terminology thing. We're actually in agreement. It was very hard to see that from the article because it's only negative. > The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business. Small-a agile prescribes no roles at all, so I can't say whether a BA would be useful or not. Scrum (which is the Big-A Agile I have most experience with) also doesn't define a BA role and broadly agrees with you: get the devs doing that work. It also doesn't make any distinction between "designer", "architect", "copywriter" or "engineer". They're all "developers" in Scrum, as far as I understand it from the course I did, and repeatedly re-reading the guide. Neither agile, nor Scrum talk about story points, JIRA, user stories. Scrum recommends you estimate, so that you can fit things into a sprint (so it can be released), and so you can measure your team's own sense of sizing. Those tools (story points, etc) are extras, often prescribed by businesses that aren't as agile as they'd like to to believe... but can still be useful so long as they're used well. Use them as guides, signals for internal team use, not to share outside the team, not to be held accountable. That's what the planning + review are for. Those are your accountability points. Honestly, I think the bigger problem with trying to use Scrum is continuous integration. If you're releasing often, faster than your sprint cadence, you're bound to come unstuck with your sprints and they'll feel like a hinderance. I'm not saying "avoid CI", I'm saying "if you use CI, and you should, modify your definitions a bit, find a way of working with the accountability system; share that organisational burden with the wider company". One problem with agile I've seen is that business priorities often change before work can be completed. You _should_ respond to the changing environment (e.g. new compliance, new customers etc), but it can be very very distracting when you have longer-form projects to complete.

P5fRxh5kUvp2th 4y ago

What proponents of agile have a tendency to do is take anything effective and call it "agile". I've literally had people say "you're doing agile even if you don't know it!". You can't nail them down, it's always "oh that works? yeah, that's agile. Oh, that doesn't work? you're not really doing agile". --- And now let me say, I don't like scrum because it's a shitty way to write software. There's really only 2 ideas in agile that are useful. 1. iterative development, and 2. evaluate and change That's it. The rest don't matter and are often actively harmful. You don't need scrum masters, PO's, sprints, story points, ad nauseum. Can they be useful? Maybe, it really depends on the scale and needs of what you're building, but I'm going to argue that outside of business analyst, these roles should be developers that take responsibilities. yeah yeah, inb4 "scrum master should be a developer!". Ask yourself this. What is the difference between a tech lead and a scrum master? answer: scrum master is considered a career, tech lead is considered a skilled developer. The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business.

the_other 4y ago
> That's it. The rest don't matter and are often actively harmful. Oh, ok. It's a terminology thing. We're actually in agreement. It was very hard to see that from the article because it's only negative. > The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business. Small-a agile prescribes no roles at all, so I can't say whether a BA would be useful or not. Scrum (which is the Big-A Agile I have most experience with) also doesn't define a BA role and broadly agrees with you: get the devs doing that work. It also doesn't make any distinction between "designer", "architect", "copywriter" or "engineer". They're all "developers" in Scrum, as far as I understand it from the course I did, and repeatedly re-reading the guide. Neither agile, nor Scrum talk about story points, JIRA, user stories. Scrum recommends you estimate, so that you can fit things into a sprint (so it can be released), and so you can measure your team's own sense of sizing. Those tools (story points, etc) are extras, often prescribed by businesses that aren't as agile as they'd like to to believe... but can still be useful so long as they're used well. Use them as guides, signals for internal team use, not to share outside the team, not to be held accountable. That's what the planning + review are for. Those are your accountability points. Honestly, I think the bigger problem with trying to use Scrum is continuous integration. If you're releasing often, faster than your sprint cadence, you're bound to come unstuck with your sprints and they'll feel like a hinderance. I'm not saying "avoid CI", I'm saying "if you use CI, and you should, modify your definitions a bit, find a way of working with the accountability system; share that organisational burden with the wider company". One problem with agile I've seen is that business priorities often change before work can be completed. You _should_ respond to the changing environment (e.g. new compliance, new customers etc), but it can be very very distracting when you have longer-form projects to complete.