Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.
Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.
Any attempt to persuade him otherwise just results in him pointing his raygun to his watch. Either he's ignorant, can't or won't understand, or simply doesn't care.
Software management in 2019 is still very much like this. Management has had 40 years to solve this problem, and it looks like it won't be solved in the next 40 either
It’s as if we were complaining that elected officials get the crap for mismanaging the country. Well, that’s the point of them doing their job. Our goal is not to all become managers (though some do, exactly for these reasons), it shouldn’t be a ”why don’t you do it ?” rhetoric.
I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.
It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.
What'd that look like, that's different from what they do now? Trying to imagine what developer input to that would look like. I think a lot of devs already feel like existing PM tools they use for sprint tracking and such are worse than if they pushed more planning into git or somewhere otherwise closer to the code, so getting buy-in might not be so hard if devs got to be a little less heavy in a bunch of not-actually-that-useful-to-them tools on a day to day basis.
I think 1/4 of the challenge is what tool to use and 3/4 is convincing and motivating people to be reliable and forthcoming with accurate information. A good project manager demonstrates he or she can add value, unblock things, escalate and communicate appropriately, and not just be the Project Police.
By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker.
By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
Almost every time I bring this up somewhere, someone pops up to say that metrics are important, key to fair and impersonal management. Without it, everything would suck, and managers couldn't do anything. The problem with that thinking is two-fold:
1. It ignores the fact that, as soon as there's a metric that determines someone's rewards and punishments in a management system (whether it's governmental regulation, corporate middle-management, anarcho-communistic self-management, or anything else), the system of measurement will get gamed, and the most overtly "successful" will end up being the most cleverly sociopathic about it.
2. There is an alternative to strictly quantitative evaluation. The alternative is qualitative evaluation. This requires good judgement, intimate knowledge of the problem domain, good intentions, and the ability to consider context, among other things. Sadly, this is incompatible with bureaucracy, which means you need to either carve a bureaucracy-free zone out of the larger organization to manage a team well or stay out of medium-to-large corporations (and out of small businesses that ape the behaviors of large bureaucracies).
Managers who insist on doing everything quantitatively (and sometimes they're forced to do so by their managers) will not get good results. "Good" is qualitative, not quantitative. Equating "good" with metrics just gives you results that look "good" on paper, but really aren't good.
Probably the biggest benefit of a small organization is the ability to eschew managerial bureaucracy in practice.
They do: engineering-led companies are often dynamic success stories, then when they get big enough traditional management works down from the top to lower levels and the firm stagnates.
They're useless if you're giving management direct access to team planning & communication tools, of course.