5 ms·

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFERENT PERSON was part of the "business", and interfaced primarily with the scrum master, but they were with us for several hours of both planning and retro. Our sprints were 2-3 weeks. At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning. We used a physical board which was matched by the tracker. They were kept in sync by individuals and validated by the DEDICATED DOCUMENTATION PERSON. We broke down the tasks relentlessly, until there were almost no 3-point tasks, maybe one or two 5-point tasks, and everything else was 1-pointers. I think this one is the most bang for your buck, lowest hanging fruit, easiest to implement winner. Someone has to enforce it vigilantly until everyone is used to it. Those three things are, IMNSHO, the keys to getting halfway decent Agile going. Edit: Was one of the least soul-crushing and nicest experiences in professional software development. The planning meetings were a serious effort, but also a pleasure because I liked everyone on the team, and the large time windows made it not seem rushed, so we had time to joke around and shoot the shit.

TedDoesntTalk 5y ago
This sounds soul-crushing and I hope never to work in such an environment.
- porker 5y ago
  > This sounds soul-crushing and I hope never to work in such an environment. It isn't. Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.
  - chris11 5y ago
    That example does sound really bad. But I would feel disengaged if everything was broken down to 1 point stories at the beginning of the sprint.
    - antihipocrat 5y ago
      I thought the idea was to focus on what is achievable in the sprint. Breaking tasks into separate steps or points exposes the complexity of a task and a task that is listed as 1 point should be fairly quick to implement. For me I'd feel more engaged by seeing that I've contributed to completing distinct points on the board at the end of the sprint. I'm a team of one and only recently started coding a large project. Sometimes I can work entire days only having achieved intangible progress. I'd love to be able to quantify this work as progress toward distinct tasks. Maybe I need to implement an Agile-like system for myself.
  - forgotmypw17 5y ago
    The "scrum master" is not telling you how long a ticket will take. They're asking you, can you break this ticket down any further? I see that you have a task to implement validation in the phone number field, can we break that down into three tasks? Determining the format which needs to be applied and edge cases, adding validation to the field on the client side, and also on the server side? Right away, thinking about it this way may reveal certain unknowns which you had not previously thought about. And all of it took an extra minute or two. While your team-mates are also engaged and "THERE" to help. Later you can see which of the tasks took longer or less than expected, and use this to improve your future estimates (during the retro.) This is only skimming the top of the types of benefits you can gain from a good Agile process.
    - porker 5y ago
      No, in this case the "scrum master" did tell us how long the tickets would take, because the cost had already been agreed with the client before we were involved. It was a special place to work.
- forgotmypw17 5y ago
  Was one of the least soul-crushing and nicest experiences in professional software development.
- underdeserver 5y ago
  It's not. The time spent in those retrospectives and planning sessions are about the technical aspects - how talks should be broken down, how overall design of interacting components should look like. It's 100% actual work. I'd take these over another bs "status sync" any day.
  - username90 5y ago
    Some developers might love just mindlessly doing trivial tickets week after week, since it means they don't have to worry about anything since the job is so easy. But others will view that as soul crushing, you can't say it isn't soul crushing for them.
    - Robin_Message 5y ago
      Being able to break down a complex technical problem into mostly one point tickets doesn't mean it is easy or mindless, just that you're good at planning and executing.
      - username90 5y ago
        It means that the day to day job is easy and mindless, even if it is some ok work being done during those meetings. Doing all the real work in a meeting every other week does seem soul crushing.
      - tkiolp4 5y ago
        There’s a difference between breaking down a complex technical problem in a few days (my approach) and doing it on the fly while doing a sprint planning. Most of Agile people want you to give estimates and simple dumb tasks that break down a complex one; this is fine... but hey, it will take me a week to do so! This is not OK for them (they want the estimate while doing the sprint planning).
- draw_down 5y ago
  I dunno if it’s quite soul crushing, but entire days of planning and retro certainly are not fun. Pass.
- g051051 5y ago
  > At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning. I'm getting ill just thinking about this. Two whole days wasted every sprint!
  - Jtsummers 5y ago
    Two whole days! Oh the humanity! If those two days out of every two weeks are critical to a team hitting their deadlines, then the team is already fucked. If you can't stop, think, talk, and relax for a moment, then you're already behind or will be behind and you'll probably never catch up without risking burnout of the team and mass quitting.
    - g051051 5y ago
      If your team is so dysfunctional that you need two days to stop, think, talk, and relax, then no amount of meetings are ever going to get you on track.
      - Jtsummers 5y ago
        It’s not about dysfunction. It’s about deliberateness. Only idiots press forward without taking time to think and consider how everything is going. By making it part of the routine you help to ensure the absence of that kind of moronic behavior. Press forward and burn out your team with a lack of slack and forethought if you want. No one is forcing you to be intelligent.
        g051051 5y ago
        It's not about deliberateness, it's about mindless ritual for rituals' sake. Only idiots would perform cargo-cult practices over a set time regardless of need or utility. By using your brain to take time only when necessary you help to ensure the absence of that kind of moronic behavior. Force time wasting meetings and burn out your team with a lack of respect. No one is forcing you to be intelligent.
Celeo 5y ago
I'd certainly like to be in an environment that has the dedicated people to those roles that so often are either combined or eschewed entirely, but 16+ hours of meetings per sprint sounds incredibly draining.
- sagarm 5y ago
  Plus two people!
- forgotmypw17 5y ago
  It wasn't particularly draining, because the large windows allowed a more relaxed pace, ensuring that nothing was missed, and a time for joking around. And it was not "16+ hours of meetings", but two days of taking a break from coding to do more social work, also having a 2-hour lunch together in the middle :)
  - danparsonson 5y ago
    Even a two hour lunch break still leaves more than six hours for a retrospective, so, honest question, what do you talk about? I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about. How can you have six hours of things to discuss after three weeks of work?
    - callmeal 5y ago
      >I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about Depends on the size of the team. For a 2-3 week sprint, and and team of 10-12 devs, a six hour relaxed retro is just barely time enough.
      - danparsonson 5y ago
        That doesn't answer my question :-) Are you all regularly having terrible problems that need in-depth discussion? Are you all celebrating every success with its own party? Are your processes so wildly off the mark that you have to change everything every sprint? Is there something else you do in your retrospectives that I don't? For my current team (also around 10-12 devs, 2 week sprints) it's: - what went well? we completed most/all of our tasks, cracked a tricky problem, received good feedback from somewhere - let's say 5-10 minutes of celebration - what didn't go well? maybe a task was more difficult than expected, some new requirement added unexpected difficulties, some third party something didn't perform as expected - 10-15 minutes of commiseration and discussion, maybe more if there's something complicated, perhaps that requires further action - what would you do differently? unless there are some procedural problems, I would expect almost nothing here; maybe someone has some new ideas about how to improve something, perhaps some aspect of the project isn't running as smoothly as it could - 5-10 minutes maybe So about thirty minutes max across the whole team, usually less. What secret magic are we missing out on? Six hours??
fukmbas 5y ago
Lmao an entire day on retro... That's thousands of dollars in wasted productivity. Garbage
MauranKilom 5y ago
How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made? Example: You want to improve performance. Somebody will have to fire up a profiler and measure things, and then figure out which hotspots are worth optimizing. I totally get breaking it down to "set up profiling tool", "do profiling runs for workflow X/Y/Z", and "identify low-hanging fruit". Presumably these tasks are not going to take the entire sprint. How do you plan the next step in task format? Do you not do any further work on the topic until the next sprint, where you then plan out concrete "optimize function X" tasks? If not, i.e. whoever does profiling also gets to optimize code during the same sprint, how do you account for that in planning? Three dummy tasks "optimize a hotspot" without any actual idea what it will involve? Maybe it requires rewriting a component to use different data structures? Maybe it's just a single JVM config tweak? "Could be a 1 or it could take my whole life?" Maybe it's just less common in certain domains, but this kind of "we need to investigate this issue and then decide what changes to make based on the investigation (and good engineering judgement)" - which is bread and butter in my part of the org - does not seem to fit into the "tasks with points" concept at all. Well, unless you want to always spread the process of "investigate issue", "identify problem and solution(s)" and "implement solution" over a whole month. That seems soul-crushing to me. To be clear, I'm very interested in seeing how to make this mesh with Agile. But it feels like trying to write a binary search in a language that has no indirection or conditionals.
- forgotmypw17 5y ago
  Research and algo design was where most of the 3- and 5-point tickets came from. I think I remember a couple with more points, but not many. Given the "about one hour of work, give or take" target point value we used, there weren't many tasks which had more points than that.
  - MauranKilom 5y ago
    I see. But that's still only the first, "plannable" part. If the research (or algo design) led to the conclusion that component X needed a rewrite, would it require waiting half a month to get started? Maybe that makes sense if it's a larger thing (so that detailed planning would be worthwhile), but would you be required to drop it and do something else in the meantime even for smaller ones (say, a man-day of work)?
lz400 5y ago
The best version of Agile I've ever been part of didn't start great, started like what you describe. And everyone hated the day long retro and planning. So we iterated over it until we got people to come to those meetings with their homework done and tasks reasonably thought out and split instead of having to waste everyone's time for it. And in the end it worked quite well. Retro and planning down to ~1 hour. I will fight, in any team I'm a part from now on, to avoid the interminable scrum rituals. They are soul crushing for most good engineers I know. I never ever want to do them again.

TedDoesntTalk 5y ago

This sounds soul-crushing and I hope never to work in such an environment.

porker 5y ago
> This sounds soul-crushing and I hope never to work in such an environment. It isn't. Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.
- chris11 5y ago
  That example does sound really bad. But I would feel disengaged if everything was broken down to 1 point stories at the beginning of the sprint.
  - antihipocrat 5y ago
    I thought the idea was to focus on what is achievable in the sprint. Breaking tasks into separate steps or points exposes the complexity of a task and a task that is listed as 1 point should be fairly quick to implement. For me I'd feel more engaged by seeing that I've contributed to completing distinct points on the board at the end of the sprint. I'm a team of one and only recently started coding a large project. Sometimes I can work entire days only having achieved intangible progress. I'd love to be able to quantify this work as progress toward distinct tasks. Maybe I need to implement an Agile-like system for myself.
- forgotmypw17 5y ago
  The "scrum master" is not telling you how long a ticket will take. They're asking you, can you break this ticket down any further? I see that you have a task to implement validation in the phone number field, can we break that down into three tasks? Determining the format which needs to be applied and edge cases, adding validation to the field on the client side, and also on the server side? Right away, thinking about it this way may reveal certain unknowns which you had not previously thought about. And all of it took an extra minute or two. While your team-mates are also engaged and "THERE" to help. Later you can see which of the tasks took longer or less than expected, and use this to improve your future estimates (during the retro.) This is only skimming the top of the types of benefits you can gain from a good Agile process.
  - porker 5y ago
    No, in this case the "scrum master" did tell us how long the tickets would take, because the cost had already been agreed with the client before we were involved. It was a special place to work.
forgotmypw17 5y ago
Was one of the least soul-crushing and nicest experiences in professional software development.
underdeserver 5y ago
It's not. The time spent in those retrospectives and planning sessions are about the technical aspects - how talks should be broken down, how overall design of interacting components should look like. It's 100% actual work. I'd take these over another bs "status sync" any day.
- username90 5y ago
  Some developers might love just mindlessly doing trivial tickets week after week, since it means they don't have to worry about anything since the job is so easy. But others will view that as soul crushing, you can't say it isn't soul crushing for them.
  - Robin_Message 5y ago
    Being able to break down a complex technical problem into mostly one point tickets doesn't mean it is easy or mindless, just that you're good at planning and executing.
    - username90 5y ago
      It means that the day to day job is easy and mindless, even if it is some ok work being done during those meetings. Doing all the real work in a meeting every other week does seem soul crushing.
    - tkiolp4 5y ago
      There’s a difference between breaking down a complex technical problem in a few days (my approach) and doing it on the fly while doing a sprint planning. Most of Agile people want you to give estimates and simple dumb tasks that break down a complex one; this is fine... but hey, it will take me a week to do so! This is not OK for them (they want the estimate while doing the sprint planning).
draw_down 5y ago
I dunno if it’s quite soul crushing, but entire days of planning and retro certainly are not fun. Pass.
g051051 5y ago
> At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning. I'm getting ill just thinking about this. Two whole days wasted every sprint!
- Jtsummers 5y ago
  Two whole days! Oh the humanity! If those two days out of every two weeks are critical to a team hitting their deadlines, then the team is already fucked. If you can't stop, think, talk, and relax for a moment, then you're already behind or will be behind and you'll probably never catch up without risking burnout of the team and mass quitting.
  - g051051 5y ago
    If your team is so dysfunctional that you need two days to stop, think, talk, and relax, then no amount of meetings are ever going to get you on track.
    - Jtsummers 5y ago
      It’s not about dysfunction. It’s about deliberateness. Only idiots press forward without taking time to think and consider how everything is going. By making it part of the routine you help to ensure the absence of that kind of moronic behavior. Press forward and burn out your team with a lack of slack and forethought if you want. No one is forcing you to be intelligent.
      - g051051 5y ago
        It's not about deliberateness, it's about mindless ritual for rituals' sake. Only idiots would perform cargo-cult practices over a set time regardless of need or utility. By using your brain to take time only when necessary you help to ensure the absence of that kind of moronic behavior. Force time wasting meetings and burn out your team with a lack of respect. No one is forcing you to be intelligent.

Celeo 5y ago

I'd certainly like to be in an environment that has the dedicated people to those roles that so often are either combined or eschewed entirely, but 16+ hours of meetings per sprint sounds incredibly draining.

sagarm 5y ago
Plus two people!
forgotmypw17 5y ago
It wasn't particularly draining, because the large windows allowed a more relaxed pace, ensuring that nothing was missed, and a time for joking around. And it was not "16+ hours of meetings", but two days of taking a break from coding to do more social work, also having a 2-hour lunch together in the middle :)
- danparsonson 5y ago
  Even a two hour lunch break still leaves more than six hours for a retrospective, so, honest question, what do you talk about? I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about. How can you have six hours of things to discuss after three weeks of work?
  - callmeal 5y ago
    >I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about Depends on the size of the team. For a 2-3 week sprint, and and team of 10-12 devs, a six hour relaxed retro is just barely time enough.
    - danparsonson 5y ago
      That doesn't answer my question :-) Are you all regularly having terrible problems that need in-depth discussion? Are you all celebrating every success with its own party? Are your processes so wildly off the mark that you have to change everything every sprint? Is there something else you do in your retrospectives that I don't? For my current team (also around 10-12 devs, 2 week sprints) it's: - what went well? we completed most/all of our tasks, cracked a tricky problem, received good feedback from somewhere - let's say 5-10 minutes of celebration - what didn't go well? maybe a task was more difficult than expected, some new requirement added unexpected difficulties, some third party something didn't perform as expected - 10-15 minutes of commiseration and discussion, maybe more if there's something complicated, perhaps that requires further action - what would you do differently? unless there are some procedural problems, I would expect almost nothing here; maybe someone has some new ideas about how to improve something, perhaps some aspect of the project isn't running as smoothly as it could - 5-10 minutes maybe So about thirty minutes max across the whole team, usually less. What secret magic are we missing out on? Six hours??

fukmbas 5y ago

Lmao an entire day on retro... That's thousands of dollars in wasted productivity. Garbage

MauranKilom 5y ago

How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made? Example: You want to improve performance. Somebody will have to fire up a profiler and measure things, and then figure out which hotspots are worth optimizing. I totally get breaking it down to "set up profiling tool", "do profiling runs for workflow X/Y/Z", and "identify low-hanging fruit". Presumably these tasks are not going to take the entire sprint. How do you plan the next step in task format? Do you not do any further work on the topic until the next sprint, where you then plan out concrete "optimize function X" tasks? If not, i.e. whoever does profiling also gets to optimize code during the same sprint, how do you account for that in planning? Three dummy tasks "optimize a hotspot" without any actual idea what it will involve? Maybe it requires rewriting a component to use different data structures? Maybe it's just a single JVM config tweak? "Could be a 1 or it could take my whole life?" Maybe it's just less common in certain domains, but this kind of "we need to investigate this issue and then decide what changes to make based on the investigation (and good engineering judgement)" - which is bread and butter in my part of the org - does not seem to fit into the "tasks with points" concept at all. Well, unless you want to always spread the process of "investigate issue", "identify problem and solution(s)" and "implement solution" over a whole month. That seems soul-crushing to me. To be clear, I'm very interested in seeing how to make this mesh with Agile. But it feels like trying to write a binary search in a language that has no indirection or conditionals.

forgotmypw17 5y ago
Research and algo design was where most of the 3- and 5-point tickets came from. I think I remember a couple with more points, but not many. Given the "about one hour of work, give or take" target point value we used, there weren't many tasks which had more points than that.
- MauranKilom 5y ago
  I see. But that's still only the first, "plannable" part. If the research (or algo design) led to the conclusion that component X needed a rewrite, would it require waiting half a month to get started? Maybe that makes sense if it's a larger thing (so that detailed planning would be worthwhile), but would you be required to drop it and do something else in the meantime even for smaller ones (say, a man-day of work)?

lz400 5y ago

The best version of Agile I've ever been part of didn't start great, started like what you describe. And everyone hated the day long retro and planning. So we iterated over it until we got people to come to those meetings with their homework done and tasks reasonably thought out and split instead of having to waste everyone's time for it. And in the end it worked quite well. Retro and planning down to ~1 hour. I will fight, in any team I'm a part from now on, to avoid the interminable scrum rituals. They are soul crushing for most good engineers I know. I never ever want to do them again.