Comment by glenjamin
1 year ago
This is called project management, and in my experience seems to be a practice/discipline that's often overlooked or ignored at startups and scaling tech companies.
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.
I don’t think I’ve ever worked with a project manager who wasn’t a total pseudo jobber. That is to say, I have worked with some wonderful project managers, but they got things done rather than “manage projects”. They’d be hands deep in Active Directory, weird json stuff to help find issues with OCR or working on change management and training when a new system needed to be adopted. But the whole “agile” side of project managers, scrum masters, IT business partners and so one have always just gotten on the way.
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.
This may shock you, but companies actually need people to do things other than code. There's some strong "junior developer" vibes in this last paragraph, not realizing that SWE management and project management are spending their whole day making sure that the code you're writing is actually what the company needs, and they're not just lighting money on fire by employing you.
Just because someone "can't code anymore" (arguable premise though that is) doesn't mean their job is automatically bullshit.
It’s two decades of experience speaking. I didn’t speak about managers though. I was a manager for a couple of years before my undiagnosed ADHD made itself know when I had my first baby. Management has nothing to do with project management. I’m solely speaking about the horde of pseudo jobbers who work as middlemen between developers and whatever it is that developers are supposed to do. I’ve never encountered one which wasn’t a waste of resources except for business process and lean consultants who would actually do change management on the business side before anyone attempted doing any form of digitalisation.
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.
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.
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.
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?
1 reply →
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.
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.
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.
If I were you I would have left immediately.
1 reply →
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.
It's usually easier for a technical "tech lead" to pick up project management than for a project manager to pick up "tech lead" (deep technical) skills, but exceptions exist.
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.
This matches my experience - I was intentional about not saying that a project manager was important - just that project management (the practice) is important.
>Generally in my book projects should only be assigned to teams
User stories are assigned to teams.