4 ms·

Is there a software methodology that does away with all the ceremony and standups and meetings and trusts me to receive a task and see it to completion without

Is there a software methodology that does away with all the ceremony and standups and meetings and trusts me to receive a task and see it to completion without management interference? I am still very pissed that the job of an SWE has become this pastiche of different business fucks telling me how to make stuff and hectoring me with random JIRA bullshit. Tell me what you want, put me in touch with my stakeholders, give me a POC for progress updates, and stand the hell back. LEAN seems to be about as close as we can get. Otherwise, to this antisocial developer that just wants to be left alone, agile sucks.

solraph 3y ago
Agile can be this, but it requires finding a company that trusts it's SWE people. Once you have that trust, the rest of it just flows from there. But - it requires everyone to actually be willing to work this way. I work in a company/team that has this, and while we use Jira[0], it's effectively there to remember what we need to do for a given task/bug and ensure that two people don't work on the same thing. The use of Epics lets management & stakeholders see what is happening with a given feature without bugging us. We don't have estimations, retros, or any of the other usual rituals, and it's amazing. If there's a mismatch of expectations or we need to hash something out there's Slack and Zoom. Someone volunteers to write up a card, and we're done. The corollary is that we've had a couple of hires come and go who just did not have the skills and/or interest in being part of those conversations, and they did not last. I'm in two minds if this is the damage inflicted on them by years of managerial Taylorism, or that they just could not keep up with the rest of the team. I expect (but hope to be wrong) that once we expand enough to have actual juniors we might have to embrace some of the more ritual parts of agile. [0] We use Jira in Kanban mode with a couple of text templates for the different card types (epic, story, bug), and none of the usual rules about what can be moved in and out of what column. EDIT: complete->couple
- pdntspa 3y ago
  That sounds like paradise compared to the last couple of companies I worked for.
- yCombLinks 3y ago
  You hiring remote? Sounds great compared to my heavy management job
  - solraph 3y ago
    Currently after a senior react dev, but really only around GMT+10 (give or take a couple of hours each way).
andrei_says_ 3y ago
You may want to look at Basecamp’s Shape Up. Form tiny independent teams capable of designing and shipping features. Assign them features and have them design and ship within 6 weeks. If they can’t fit in that time, drop the feature. The tiny teams (2-3 people) have near full decision power on all details. The stakeholders bid on features every cycle. No micromanagement, no running tasks through a shredder and reassembling them. Trusted teams building the product. https://basecamp.com/shapeup https://basecamp.com/shapeup
- brailsafe 3y ago
  Thabks for the link, seems way more coherent than anything I've been apart of previously.
  - andrei_says_ 3y ago
    It’s a practical approach they arrived to by iterating. Empowers their teams into full ownership while creating a culture of trust and growth. Companies adopting shapeup say it’s a breath of fresh air.
- deleted 3y ago
  [deleted]
stcroixx 3y ago
Best ‘methodology’ I’ve used in my 26 year career was a simple spreadsheet of items - manager would read them out loud at a meeting and whoever was interested would volunteer. After that, up to you to make it happen.
- BerislavLopac 3y ago
  Based on the experience of some teams I have worked with and/or managed, I can easily imagine many of the items on the least being met with crickets...
- matwood 3y ago
  Add 'come back in 2 weeks with completed items and repeat' and you basically have agile. Unless the items were things like 'build product', which I would argue is not a path to success.
jochem9 3y ago
Where I work we have true self steering teams. The team's tech lead(s) are most in tune with what the customer wants and how we want to deliver it to them. The rest we figure out in the team. It's very common for non-leads to also start talking to specific stakeholders once they work on a feature. Usually they'll become the (technical) owner of a piece of software just because they build it, maintain it and care about it. This means everyone has a lot of responsibility, but also immense freedom to take on that responsibility the way they see fit. We have some scrum-type rituals. Primarily stand-ups (15 mins teams call to sync and have stakeholders listen in if they want) and the occasional retro, although it's not a typical retro with a format. They're basically a full team meeting when things aren't going smoothly or something else happens that everyone needs to be aware of ('sudden' crisis at the customer, which they have a lot) and use round tables to make sure everyone is heard. Most other things are handled in smaller groups of relevant people. We have a backlog in Jira to keep track of what we want to do and in which order. We pick up work kanban style. The current team is 13 people, so it also gives an overview of what's going on where. There's no formal format for writing things down, but over time we've learned to add quite a bit of context, especially for nice to have stuff we don't pick up straight away. The reason this works is that we hire people who can deal with the freedom and responsibility. We put a lot of trust in them from day one, while coaching them using all kinds of formal and informal systems.
matwood 3y ago
You've fallen into the trap of blaming agile and JIRA for a companies terrible process. This is exactly what the company wants because you'll spend your time complaining about the things (tool and what the company calls something) that don't matter. Instead you should focus on embracing agile and using the retros to change the process.
- rightbyte 3y ago
  Sure, in theory he could have used the Ring of Power for good. But it would probably succumb him in the end. Oh wrong discussion. But it fits anyway. Just don't give managment the ability to micromanage you in an automated and machine like way and there is no risk of misuse of that power happening. Manual micromanagement is hard work you know.
- manuelabeledo 3y ago
  > You've fallen into the trap of blaming agile and JIRA for a companies terrible process. How many people do you think have fallen into this trap? It seems that every single company out there are trying agile, and almost all of them are doing it wrong. I have yet to be part of an organization that does agile right, or at least the way it was promised to us from the beginning. Perhaps the whole idea is just another utopia that will never reach its full potential.
  - matwood 3y ago
    Process is hard. Building things is hard. It's easy to blame Jira or <insert buzzword of the day> process, instead of admitting that process is hard. On one side you see many developers who want to be given a requirement and left alone. They basically want waterfall. On the other is the business that needs to know what's happening and be able to adjust according to various factors. How these groups come together is the challenge and based on all failures is one we have not yet met as an industry.
bluGill 3y ago
> Is there a software methodology that does away with all the ceremony and standups and meetings and trusts me to receive a task and see it to completion without management interference? Kanban, which is an agile method. It contains the good parts from Scrum, without the pointless ceremony. Just take the most important story off the list, do it, then repeat until done. Feel free to adjust priorities of not started stories. JIRA and the like can be useful tools to track what work is done. However the value isn't to engineers, it is to management on a large project. Keep that mindset in mind, on a large project management is hard.

solraph 3y ago

Agile can be this, but it requires finding a company that trusts it's SWE people. Once you have that trust, the rest of it just flows from there. But - it requires everyone to actually be willing to work this way. I work in a company/team that has this, and while we use Jira[0], it's effectively there to remember what we need to do for a given task/bug and ensure that two people don't work on the same thing. The use of Epics lets management & stakeholders see what is happening with a given feature without bugging us. We don't have estimations, retros, or any of the other usual rituals, and it's amazing. If there's a mismatch of expectations or we need to hash something out there's Slack and Zoom. Someone volunteers to write up a card, and we're done. The corollary is that we've had a couple of hires come and go who just did not have the skills and/or interest in being part of those conversations, and they did not last. I'm in two minds if this is the damage inflicted on them by years of managerial Taylorism, or that they just could not keep up with the rest of the team. I expect (but hope to be wrong) that once we expand enough to have actual juniors we might have to embrace some of the more ritual parts of agile. [0] We use Jira in Kanban mode with a couple of text templates for the different card types (epic, story, bug), and none of the usual rules about what can be moved in and out of what column. EDIT: complete->couple

pdntspa 3y ago
That sounds like paradise compared to the last couple of companies I worked for.
yCombLinks 3y ago
You hiring remote? Sounds great compared to my heavy management job
- solraph 3y ago
  Currently after a senior react dev, but really only around GMT+10 (give or take a couple of hours each way).

andrei_says_ 3y ago

You may want to look at Basecamp’s Shape Up. Form tiny independent teams capable of designing and shipping features. Assign them features and have them design and ship within 6 weeks. If they can’t fit in that time, drop the feature. The tiny teams (2-3 people) have near full decision power on all details. The stakeholders bid on features every cycle. No micromanagement, no running tasks through a shredder and reassembling them. Trusted teams building the product. https://basecamp.com/shapeup https://basecamp.com/shapeup

brailsafe 3y ago
Thabks for the link, seems way more coherent than anything I've been apart of previously.
- andrei_says_ 3y ago
  It’s a practical approach they arrived to by iterating. Empowers their teams into full ownership while creating a culture of trust and growth. Companies adopting shapeup say it’s a breath of fresh air.
deleted 3y ago
[deleted]

stcroixx 3y ago

Best ‘methodology’ I’ve used in my 26 year career was a simple spreadsheet of items - manager would read them out loud at a meeting and whoever was interested would volunteer. After that, up to you to make it happen.

BerislavLopac 3y ago
Based on the experience of some teams I have worked with and/or managed, I can easily imagine many of the items on the least being met with crickets...
matwood 3y ago
Add 'come back in 2 weeks with completed items and repeat' and you basically have agile. Unless the items were things like 'build product', which I would argue is not a path to success.

jochem9 3y ago

Where I work we have true self steering teams. The team's tech lead(s) are most in tune with what the customer wants and how we want to deliver it to them. The rest we figure out in the team. It's very common for non-leads to also start talking to specific stakeholders once they work on a feature. Usually they'll become the (technical) owner of a piece of software just because they build it, maintain it and care about it. This means everyone has a lot of responsibility, but also immense freedom to take on that responsibility the way they see fit. We have some scrum-type rituals. Primarily stand-ups (15 mins teams call to sync and have stakeholders listen in if they want) and the occasional retro, although it's not a typical retro with a format. They're basically a full team meeting when things aren't going smoothly or something else happens that everyone needs to be aware of ('sudden' crisis at the customer, which they have a lot) and use round tables to make sure everyone is heard. Most other things are handled in smaller groups of relevant people. We have a backlog in Jira to keep track of what we want to do and in which order. We pick up work kanban style. The current team is 13 people, so it also gives an overview of what's going on where. There's no formal format for writing things down, but over time we've learned to add quite a bit of context, especially for nice to have stuff we don't pick up straight away. The reason this works is that we hire people who can deal with the freedom and responsibility. We put a lot of trust in them from day one, while coaching them using all kinds of formal and informal systems.

matwood 3y ago

You've fallen into the trap of blaming agile and JIRA for a companies terrible process. This is exactly what the company wants because you'll spend your time complaining about the things (tool and what the company calls something) that don't matter. Instead you should focus on embracing agile and using the retros to change the process.

rightbyte 3y ago
Sure, in theory he could have used the Ring of Power for good. But it would probably succumb him in the end. Oh wrong discussion. But it fits anyway. Just don't give managment the ability to micromanage you in an automated and machine like way and there is no risk of misuse of that power happening. Manual micromanagement is hard work you know.
manuelabeledo 3y ago
> You've fallen into the trap of blaming agile and JIRA for a companies terrible process. How many people do you think have fallen into this trap? It seems that every single company out there are trying agile, and almost all of them are doing it wrong. I have yet to be part of an organization that does agile right, or at least the way it was promised to us from the beginning. Perhaps the whole idea is just another utopia that will never reach its full potential.
- matwood 3y ago
  Process is hard. Building things is hard. It's easy to blame Jira or <insert buzzword of the day> process, instead of admitting that process is hard. On one side you see many developers who want to be given a requirement and left alone. They basically want waterfall. On the other is the business that needs to know what's happening and be able to adjust according to various factors. How these groups come together is the challenge and based on all failures is one we have not yet met as an industry.

bluGill 3y ago

> Is there a software methodology that does away with all the ceremony and standups and meetings and trusts me to receive a task and see it to completion without management interference? Kanban, which is an agile method. It contains the good parts from Scrum, without the pointless ceremony. Just take the most important story off the list, do it, then repeat until done. Feel free to adjust priorities of not started stories. JIRA and the like can be useful tools to track what work is done. However the value isn't to engineers, it is to management on a large project. Keep that mindset in mind, on a large project management is hard.