[HN Gopher] McKinsey: Yes, you can measure software developer pr...
___________________________________________________________________
McKinsey: Yes, you can measure software developer productivity
Author : tosh
Score : 15 points
Date : 2023-08-20 21:31 UTC (1 hours ago)
(HTM) web link (www.mckinsey.com)
(TXT) w3m dump (www.mckinsey.com)
| barbazoo wrote:
| Well, I read it and still don't know how they measure software
| developer productivity.
|
| Good stuff for the next bullshit bingo template though, I didn't
| have "Developer Velocity Index Benchmark" yet.
| tracerbulletx wrote:
| Hey now, it does have some specific advice! For example you
| should perform the "extensive reconfiguration" needed to
| generate code test coverage reports. Presumably since this
| article is about metrics for the C-Suite we can provide this
| valuable information to them so they can assess "the extent to
| which areas of code have been adequately tested". What truly
| useful and not catastrophically bone headed advice. Thank
| goodness we have tech savvy experienced contractors like
| McKinsey to whip our shabby tech org in to shape.
| xnyan wrote:
| We are not in the audience, the audience is any organization
| that needs to manage and understand the output of software
| engineers, but does not have the necessary technical ability
| to do this.
|
| If I'm understanding them correctly, their pitch is basically
| "pay us a lot of money to teach you some basic software
| engineering concepts, and don't use dumb metrics like LoC
| produced per day."
|
| I think paying McKinsey prices to get this is a poor value,
| but it would probably improve most software engineering
| management.
| blibble wrote:
| > "pay us a lot of money to teach you some basic software
| engineering concepts, and don't use dumb metrics like LoC
| produced per day."
|
| "use our stupid metrics instead"
| contingencies wrote:
| _You can measure rot within a growing corporation. It 's how much
| money they spend on us._ - McKinsey
| sidongio123 wrote:
| So how do you measure productivity? I see no definition of
| "Developer Velocity" in this article or the linked ones, nor do I
| see an explanation of how it's measured, nor do I see any real
| attempt to prove its validity. They simply _assert_ that they
| have a meaningful metric, which is begging the question.
|
| >generative AI tools such as CopilotX and ChatGPT have the
| potential to enable developers to complete tasks up to two times
| faster
|
| I'm surprised McKinsey is willing to endorse ChatGPT, which is
| one of their major competitors in the information-free drivel
| market.
| xnyan wrote:
| As I kind of expected, a lot of general statements I mostly agree
| with, but very light on specifics and no concrete data at all.
| "276% better!" does not mean anything without knowing how they
| define better.
|
| > leaders and developers alike need to move past the outdated
| notion that leaders "cannot" understand the intricacies of
| software engineering
|
| Leaders absolutely can understand software engineering, if time
| and effort to learn is spent. McKinsey themselves say this. So
| their argument is 1) if you learn about software engineering,
| you'll be more capable of evaluating the efforts of software
| engineers and 2) don't use idiotic quantifiers of productivity
| like LoC per day.
| freetanga wrote:
| Nope. Being an ex McK, first thing to do is check who wrote this,
| knowing that the senior figureheads are just for name, it was
| written by the lowly Analyst or EM.
|
| In this case, worthless crap.
| crazygringo wrote:
| I was ready to dismiss all of this, but it's actually pretty
| interesting.
|
| The big-picture view is given by Exhibit 1, and you can see it's
| really much more about analyzing all aspects of productivity
| (company-level, team-level, etc.) to identify bottlenecks around
| e.g. too much time spent testing over writing code, or senior
| developers stuck in endless cross-team alignment meetings which
| means management needs to identify a single person responsible
| for making final decisions quickly. So this is a document for
| engineering managers, not engineers.
|
| But in terms of measuring actual _individual_ developer
| productivity, if you read through all the verbiage it 's really
| mostly just adding up the "planning poker" agile/sprint points
| that a developer delivers over the course of months. About which
| I have two main thoughts:
|
| 1) As long as planning poker is executed correctly -- i.e. always
| with unanimous consensus from engineers and without managers/PM's
| providing pressure -- this is actually probably going to be
| pretty decently objective, as a moving average. It's not terrible
| -- it's infinitely better than things like "lines of code".
| Although teams can also experience gradual "points drift" over
| the course of months, and points between teams can't be
| translated, so it can't be used company-wide or even year-to-
| year. But it will compare productivity _between team members._
|
| 2) BUT, there's a huge risk involved because not all e.g. 5 point
| stories are the same, because of variance. Some are very
| straightforward where you _know_ it 's 5 points, while others are
| much more unknown, where the best guess is 5 points -- and it
| might wind up being 2 points but it also might wind up being 50
| points. And so I could definitely see certain stories turning
| into "hot potatoes" nobody wants to touch because it's just too
| much of a risk -- it'll tank their average and they won't get
| promoted. And then everything just breaks down. Which means you
| either need post-sprint processes for "correcting" estimates and
| assigning a reasonable value for points done, or going deeper
| into "research" stories -- e.g. a 1-point pre-story to better
| nail down the actual size.
| oxfordmale wrote:
| Planning poker
|
| Step 1: We are going to estimate tasks in imaginary relative
| units
|
| Step 2: We are now going to use these imaginary units to
| measure your velocity
|
| Step 3: We are now going to compare your progress in imaginary
| units to other teams who use a different imaginary units, and
| complain your underperforming
|
| Then you imaginary unit inflation and before you know
| everything is an XXXXXXXXXXXXXXXL t shirt size.
| FooBarBizBazz wrote:
| SV companies function as cults built on the same principles
| as pick-up artistry and other scams, but institutionalized
| and sanctified with language. Recruiters are professionally
| engaged in love-bombing tactics, and managers are
| professionally engaged in negging. It's all a game to get as
| much psychological leverage over people as possible. That's
| also why they like to get 'em young.
| Shaanie wrote:
| The main issue is when the developers inevitably find out that
| story points completed are how they're evaluated.
| Shaanie wrote:
| Hm, accidentally hit the submit button before the reply was
| fully done. Anyway, I think the story point completed,
| tickets done, pull requests submitted or even number of
| commits works somewhat well for measuring developer
| productivity, as long as nobody is aware of it. The least
| productive developers I've worked with did tend to have very
| few commits in comparison to more productive peers, but
| obviously that'd quickly change if they found out that it's a
| metric being watched, I see no reason for why story points
| wouldn't cause similar issues. Fight to get the "easy
| points", less collaboration etc.
| blibble wrote:
| as someone whose gone through a McKinsey "agile transformation",
| I'd not listen to a single thing McKinsey says about software
| development
|
| the company has now realised and is now rolling back everything
| they did
|
| but sadly lost probably 2/3rds of its good developers in the
| process
___________________________________________________________________
(page generated 2023-08-20 23:02 UTC)