3 ms·

The last "agile" shop I worked at instead did 10+ small projects in parallel (1-2 devs per project) and then wondered why we never got to where we wanted to go.

beretguy 2y ago
One place I worked at did that + only 1 person per project and all projects got rotated between developers at the start of every week on Monday. And when we did stand up meeting every morning nobody cared what anybody else had to say cause we all worked in different projects. Go figure.
- steveBK123 2y ago
  Yes, exactly the same with the rotation. It was almost like they were optimizing for bus factor. It was completely brain scrambling and unsatisfactory work as it was constant musical chairs.
- linhns 2y ago
  If I were you I would have left immediately.
  - beretguy 2y ago
    My contract got cancelled after 1 month.
- cruffle_duffle 2y ago
  Maybe not the rotate projects bit but I’ve worked on plenty of teams where everybody is doing something different. Sometimes it is because they are spread too thin other times it is because each project individually can’t really be swarmed on and is really a solo adventure. Rotating between each project on a weekly basis, however, that seems awful.
pc86 2y ago
In contrast the last really fast-moving place I worked at has 1-3 devs per project but they were entirely 100% in charge of technical design, building it, shipping it, and maintaining it. If we wanted to wait to ship, we waited. If we wanted to ship early, we did it. I'm in an org 3-4 times the total size now and we move at half the speed.
- philote 2y ago
  That sounds great for moving fast, but not so great for sharing and keeping info about these projects. If/when someone quit, how would their projects get split up for other devs to maintain?
  - pc86 2y ago
    It definitely had its downsides especially for the 1-dev projects. In reality it wasn't that bad. Code reviews usually pointed out where documentation was needed or would be helpful, and everyone was just senior enough where you could give them a feature ticket on one of these small projects and reasonably expect they'd be able to just figure it out if they had to. Outdated or missing critical documentation, or too junior (or too lazy) coworkers would definitely have made this approach fall apart and that's a big risk of it IMO.
psunavy03 2y ago
Which is precisely the opposite of the entire intent of Agile. Take one small thing, get it done. Done done. Then decide what the next thing is, then the next, based on what you learn from that one thing. Unfortunately, too many people can't be arsed to actually understand things like the OODA loop, Cynefin, and the other things that describe precisely WHY that is a good idea. But hey, they do standups.

beretguy 2y ago

One place I worked at did that + only 1 person per project and all projects got rotated between developers at the start of every week on Monday. And when we did stand up meeting every morning nobody cared what anybody else had to say cause we all worked in different projects. Go figure.

steveBK123 2y ago
Yes, exactly the same with the rotation. It was almost like they were optimizing for bus factor. It was completely brain scrambling and unsatisfactory work as it was constant musical chairs.
linhns 2y ago
If I were you I would have left immediately.
- beretguy 2y ago
  My contract got cancelled after 1 month.
cruffle_duffle 2y ago
Maybe not the rotate projects bit but I’ve worked on plenty of teams where everybody is doing something different. Sometimes it is because they are spread too thin other times it is because each project individually can’t really be swarmed on and is really a solo adventure. Rotating between each project on a weekly basis, however, that seems awful.

pc86 2y ago

In contrast the last really fast-moving place I worked at has 1-3 devs per project but they were entirely 100% in charge of technical design, building it, shipping it, and maintaining it. If we wanted to wait to ship, we waited. If we wanted to ship early, we did it. I'm in an org 3-4 times the total size now and we move at half the speed.

philote 2y ago
That sounds great for moving fast, but not so great for sharing and keeping info about these projects. If/when someone quit, how would their projects get split up for other devs to maintain?
- pc86 2y ago
  It definitely had its downsides especially for the 1-dev projects. In reality it wasn't that bad. Code reviews usually pointed out where documentation was needed or would be helpful, and everyone was just senior enough where you could give them a feature ticket on one of these small projects and reasonably expect they'd be able to just figure it out if they had to. Outdated or missing critical documentation, or too junior (or too lazy) coworkers would definitely have made this approach fall apart and that's a big risk of it IMO.

psunavy03 2y ago

Which is precisely the opposite of the entire intent of Agile. Take one small thing, get it done. Done done. Then decide what the next thing is, then the next, based on what you learn from that one thing. Unfortunately, too many people can't be arsed to actually understand things like the OODA loop, Cynefin, and the other things that describe precisely WHY that is a good idea. But hey, they do standups.