From what I read, it honestly sounds like maybe things started slowing down because 1. development generally slows down as a project becomes bigger (even when keeping technical debt in mind) and 2. Because of a shitty feature request. Yeah, it sounds like the PM didn't help either but it's not clear to me that they were the biggest problem here (although it is true that PMs can definitely be hit and miss, even more so when hired in the middle of the project's lifecycle).
The team also needed to evolve, starting with a very small implementation and evolve it to handle each additional use case in a way that the stakeholders felt there was progress in their biggest pain points.
It's an experienced lead that takes their hands off the keyboard for a few weeks and immerses themselves in the social problem. (And yes, sometimes it means breaking big problems into small pieces as a team and organizing around the work in separate steps, even if that feels unsatisfying.)
I feel bad for PMs, because there is a role for them - just usually not the role that they've been assigned to. PMs tied down to small teams usually causes problems. PMs should be facilitating inter-team development. I believe tech-leads and BAs should be assigned the role that PMs seem to find themselves in when they're assigned to small teams.
And please PMs, learn what the product is all about. Too many times I've seen PMs actively not wanting to know what the hell the product is about and instead love getting bogged down in process (and of course meetings).
The best PMs I ever worked with I could come to with "I need X from the organization" and within a few hours or less I'd be unblocked and could move forward. The other type that pester developers are poison and should be thrown off the boat for the reasons listed in the article.
The time estimate and completion time features on tools like Jira make my insides sink a little bit. I think it's somewhat difficult to know ahead of time exactly how long something will take to implement, and, even worse, committing yourself to that puts pressure to ignore unforeseen events or complications or to not take care of them properly. I'd rather be extra careful than quick.
Assuming your team isn't massive or out of control, I think it's possible to have trust in programmers that they won't muck about and will deliver work in the time it takes to deliver the work--which for a good programmer isn't affected by management or Jira or estimates. It's just a constant.
People over process right?
However, if you intend this as an argument against general software project management, I must disagree. (See: "He introduced us to ‘Jira’, a word that strikes fear into the soul of a developer.")
Lately I've had the opportunity to work at a place with very forward-thinking, progressive, and helpful PMs and generally good organizational structure.
I like our approach and here is why:
* We are not afraid to change things. This might lead to some temporary disagreements between technical leads and PMS, but EVERYONE in the team has transparency into the process, and an opportunity to voice an opinion.
* We taking scoring tickets very seriously. I've been at places where everyone on a team might vote on a ticket, even if they cannot appreciate the true scope of it. Here it's different. For instance, we have seen that in the last couple of weeks, our velocity was unusually high. This might indicate we are scoring tickets too highly, and from what I've seen of my own work, I'm inclined to agree.
I've had a length interview with a PM who spent some time afterwards telling me about his metholodogies (I gladly listened.) When given the choice between Gantt charts which have cliffs (indicating poor future planning and rushing to get things done last minute) and nice step-ladder charts, we see why PMs prefer things the way they do.
Sometimes it gets in the way of just writing code sure. But with good organizational structure, especially in a mid-size company that has upcoming deadlines and business features to ship, we identify priorities quickly while still being aware of things like reducing code debt.
Just look at construction - spend years planning for 6 months of development. And there are still schedule overruns!
Sure, you can have detailed estimates. But every company I've worked at wants detailed, accurate estimates with maybe one day's worth of planning. Often they want "guesses" or "rough estimates" on the spot, literally seconds after telling you what they want. I've also never come across a single company that actually froze requirements.
And every developer knows what happens when you say you can't give an accurate estimate quickly: They demand you make a guess anyway and that becomes the estimate. If you give a range, they'll take the minimum as the estimate.
We use JIRA, but our PMs understand the importance of fixing things that are broken. Refactoring code is usually added as a subtask to stories that have to deal with the code that needs refactored.
I will agree that micro-managing is not a good way to do software development, but many times if you just go pure laissez fair then a lot of times projects go off the rails.
Maybe the difference for me is that software engineering is my job, not my lifestyle or identity. I don't know.
That only works when the people who are asking for the software know what they want. In the situation described in the article:
"The one where you try to replace an expert user’s years of experience and intuition with software. What started out as a vague and wooly requirement, soon became a monster as we started to dig into it."
In my experience, the business people aren't good at turning vague and wooly requirements into precise specifications for software - they're not trained as logical thinkers. Usually, that job falls on the developers, who will try to clarify the requirements until they have something that's precise enough to be translated into logically consistent code. This may involve a lot of trial an error, since trying to extract the requirements from the business people is a non-linear process (e.g., they can change their minds on what the spec is, and a seemingly small change in the spec can have a large effect on the architecture).
In my experience, different orgs use PMs in different ways. The most positive experiences I've had has been with PMs who were there to facilitate communication, get people unblocked, keep track of requirements and big picture stuff, and in general to help people out and worry about certain things so the engineers don't have to.
I've also had bad experiences with PMs in other orgs. In the bad cases, the PMs are used by upper management solely to keep an eye on everyone, not to help them. These are the places where the only time you deal with PMs is when they summon you into meetings to explain why you're not done with something yet, or they pop into your office to give you a list of items and want to know which ones are done and what's the ETA on everything else.
When used appropriately, PMs can be a godsend and no one resents having to deal with them because they make everyone's jobs easier. When used inappropriately, all they ever do is go around and harass people with stuff like, "is X done yet, and if not, what's the ETA?" When used in that capacity, that means they been drafted into a different role where they're being used by higher-level management to stay on top of everyone and roll up daily or weekly reports that the higher-level managers then send up to their managers to make it look like they're in control of the situation.
When used extremely inappropriately, you will see a (anti)pattern of gradually increasing granularity in how they track people. They go from tracking high level goals and milestones to tracking people and projects with increasing levels of granularity. They go from tracking engineering time in terms of months or weeks to days or hours.
Eventually this granularity crosses some threshold of usefulness, and it starts having detrimental effects on the results. Things like refactoring or code cleanup or really just doing anything that is not working on a specific new feature becomes verboten. People start exaggerating their time estimates to give themselves wiggle room, or to sneak in extra time for critical maintenance work that is not associated with a shipping feature. Eventually everyone's just lying to everyone about everything, and the constant meetings and "are you done yet?" pop-ins become pointless rituals that waste everyone's time but continue happening with greater frequency.
However, this case appears to be micromanagement, pure and simple. Micromanagement is "way too much of a good thing".
EDIT: Don't forget the pie-in-the-sky requirements. If you have sane and straightforward requirements, then you can usually break them down without too much drama. But, if they are that simple to break down, should they even be?
