Generally in my book projects should only be assigned to teams, and managing that project to completion should be part of that team's way of working.
Doing this in an agile manner generally means smaller projects, one at a time.
Generally in my book projects should only be assigned to teams, and managing that project to completion should be part of that team's way of working.
Doing this in an agile manner generally means smaller projects, one at a time.
Usually what happens is that they become middlemen that can’t actually relay information between developers and the businesses. As a result developers and digitally inclined business people tend to talk to each other directly while they let the pseudo jobbers waste everyone’s time because… because it’s “best practice”.
Hah. Especially rich when you consider that the whole “agile manifesto” was thought up and sold by people who haven’t worked in software engineering since 20 years before Python even existed. Of course it doesn’t work. Not because any part of it is particularly bad, but because every part of it is extremely vague and completely unfit for reality. If you follow any sort of practice which isn’t YAGNI religiously you’re going to fuck up.
Projects ship because one of the people who do actual work gets fed up with all the bullshit and simply does what needs to be done. All the “project managers” and other role players are only there because SWE management is full of people who can’t code anymore. You don’t see all these pseudo jobbers in IT operations, and you don’t because SysAdmins want to be SysAdmins.
Just because someone "can't code anymore" (arguable premise though that is) doesn't mean their job is automatically bullshit.
I probably should have said “won’t code anymore” because that is what I meant. It’s the developers who become project managers, architects, agile whatever. Luckily I don’t have to deal with that anymore because I’ve become specialised in helping startups in-fuck their chaos as they transition into enterprise organisations. Many of them never make it because of how their internal processes are hindered by all sorts of “best practices”.
This doesn’t mean that there aren’t excellent project managers out there. As I said, I’ve worked with some myself. Far too often project managers don’t actually do anything. I recently worked a team which has 1 PM, 1 Manager, 3 IT business partners and one architect in front of two developers. Today they have two developers and one IT business partner, who’s really an accountant that got into coding because he liked it. But is now capable of explaining the business to the developers.
It’s obviously not like that everywhere and I’m happy for you if you’ve had a better track record than me. I would argue that it is perhaps you who lack the experience that you seem to think I do. Because it’s not just on SWE you’ll find an abundance of bullshit jobs once an organisation reaches 100-500 employees.
It was almost like they were optimizing for bus factor.
It was completely brain scrambling and unsatisfactory work as it was constant musical chairs.
Rotating between each project on a weekly basis, however, that seems awful.
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.
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.
The tech lead should have better business understanding than "currently needed" and ideally be supported by a domain expert (business analyst, product owner).
A project manager may support the tech lead to ensure the project's output ships.
User stories are assigned to teams.