Probably (iff you work in the tech industry) coming to a hellscape near you. I posted this not because I agree with this (at all) but because I think it's interesting as an employee to be aware of...
Probably (iff you work in the tech industry) coming to a company hellscape near you.
I posted this not because I agree with this (at all) but because I think it's interesting as an employee to be aware of what "thought 'leaders'" such as McKinsey are currently saying – it's quite likely that lots of corporates will adopt whatever they say because it's "trendy".
I've said before that software engineers and technical workers need to wake up and start unionizing. The same extractive labor practices currently applied to other workers, whose labor is less in...
I've said before that software engineers and technical workers need to wake up and start unionizing. The same extractive labor practices currently applied to other workers, whose labor is less in demand, were going to come for knowledge workers.
Well... here we are. It's now been decided we're being paid too much relative to our ability to generate profits, and software production should be Taylorized somehow. Never mind the eventual effects of enshittification on customers, the burnout of existing employees after layoffs...
I'll go back to yelling at clouds, thanks for your time.
That's also true, but engineers' salary bands are outliers among job classifications in most companies and an easy target for extra scrutiny. [I won't say "all" companies - in healthcare, we're...
That's also true, but engineers' salary bands are outliers among job classifications in most companies and an easy target for extra scrutiny.
[I won't say "all" companies - in healthcare, we're still below most clinical staff, but way above administrative and facilities workers. And don't get me started on the efforts I've seen to extract more labor from clinical staff and drive salaries down. Unions work for nurses.]
The invisible hand is still ar work. I think it's sooner that SWEs will simply self employ their own products before unionizing. If they can't get 200k organizing some corporate software, they...
software engineers and technical workers need to wake up and start unionizing. The same extractive labor practices currently applied to other workers, whose labor is less in demand, were going to come for knowledge workers.
The invisible hand is still ar work. I think it's sooner that SWEs will simply self employ their own products before unionizing. If they can't get 200k organizing some corporate software, they will go straight to the consumer and offer some piece of productivity or entertainment and grab the money from the collective public. Unlike other industries it is very doable for a team of 2-5 to launch a service and make 7 figures. Peanuts for a corporation, a modest living for a small team.
Companies weren't necessarily paying those engineering wages just to be competitive with other companies. They also don't want the next unicorn forming under their nose.
The place I'm currently heading out of the door from (3 more weeks, that's all I've got left come on) have recently just started a huge shift from <fun, safe, happy-clappy if a tad dysfunctional>...
The place I'm currently heading out of the door from (3 more weeks, that's all I've got left come on) have recently just started a huge shift from <fun, safe, happy-clappy if a tad dysfunctional> culturally to <over-the-top, draconian, metric-heavy> approach. You can tell the newest Directors have their claws into everyone else via bullying tactics and the Chief is absolutely useless at controlling their problems.
There's serious senior leadership hemmoraging happening (myself included) with people who just do not want to be around for that transformation.
There's still this drive for PRODUCTIVITY AT ALL COSTS that absolutely just... falls on deaf ears these days. Post-Covid, people are demanding more understanding, respect and honesty from leaders. Seeing things like this from cuntsultants is nothing more than a misunderstood ideal of what a software team SHOULD be, rather than what it is.
In my capacity as former consultant I hereby absolve you of the abusive wordplay you used because this form of consultancy is morally corrupt and detestable.
In my capacity as former consultant I hereby absolve you of the abusive wordplay you used because this form of consultancy is morally corrupt and detestable.
Dear /u/Trauma, I here and understand your pain. I too am a former consultant, I also retain my Directorship in my small consultancy that I span up after time at a Big4. I feel your pain, I...
I here and understand your pain. I too am a former consultant, I also retain my Directorship in my small consultancy that I span up after time at a Big4. I feel your pain, I understand your pain, I am absolving you of all transgressions for the bullshit we do to exist in this damn system.
consultancy is morally corrupt and detestable.
So much of it is now. It's not even leadership anymore, it's just "WORK HARDER SLAVES!"
Another Big4 consultancy, Accenture, hasn't received nearly enough scrutiny for its failures and outsourcing practices, either. A company I used to work for turned its "pivot to the cloud" (oh,...
Another Big4 consultancy, Accenture, hasn't received nearly enough scrutiny for itsfailures and outsourcing practices, either. A company I used to work for turned its "pivot to the cloud" (oh, wait, the current buzzphrase is "digital transformation") over to Accenture, and it did not turn out well.*
*I'm still not sure I'm at liberty to say more even years later. Let's say the Hertz analysis applies, plus.
Yeah we're in the process of doing a lot of that. It's not going well, but they'll keep going with it it so they have extra money to give back to shareholders!
Yeah we're in the process of doing a lot of that. It's not going well, but they'll keep going with it it so they have extra money to give back to shareholders!
Maybe for straight forward coding tasks, but there are so many intangibles. I dislike how the article frames productivity. Who on the team builds team cohesion and improves moral? Who on the team...
Maybe for straight forward coding tasks, but there are so many intangibles. I dislike how the article frames productivity.
Who on the team builds team cohesion and improves moral? Who on the team acts as a sounding board or provides support when someone else is stuck? Which team member comes up with creative solutions to the problems that crop up in development or R&D? There are so many ways to measure "productivity" and as McKinsey likes to do, they have chosen short sighted metrics.
There is a parallel in hen breeding:
Selecting the hen who lays the most eggs doesn't necessarily get you the most efficient egg-laying metabolism. It may get you the most dominant hen, that pecked its way to the top of the pecking order at the expense of other hens. Individual selection doesn't necessarily work to the benefit of the group, but a farm's productivity is determined by group outputs.
Similarly, a worker can be incredibly productive and still bring down the total productivity of the whole team.
I work in cyber security. The amount of data a company can collect on your employee owned device is incredible. Screen on time, keystrokes, mouse movement (or lack of), frequency of use, etc.. Of...
I work in cyber security. The amount of data a company can collect on your employee owned device is incredible. Screen on time, keystrokes, mouse movement (or lack of), frequency of use, etc.. Of course this can be useful for security...and measuring performance.
At least at my company, all of this data is ingested into Tableau. Our execs can see exactly who is working, for how long, and compare it to results they want to see. In my opinion, this shows weak leadership from my executives. Time does not equal work. If you can do your "9 to 5" job in 30 minutes, then that should be rewarded. Instead, it appears as laziness.
We have more layoffs coming soon, and it's almost entirely based off of bullshit metrics.
Tangentially related to this, but I'm always amazed by people who carry out any personal activity on a work device or a system owned/controlled by their employers. Apple are quite bad in this way,...
Tangentially related to this, but I'm always amazed by people who carry out any personal activity on a work device or a system owned/controlled by their employers.
Apple are quite bad in this way, because Apple employees who work on the iPhone are required to use one as their personal device, and the kind of information you would put on your personal device is not something that you want ending up in a deposition. This has actually happened, for example some employees have found that their (what they thought were very private) nudes are now on a device which has been surrendered to a court.
Fully agree. I'm very much wired to not be able to be sitting at my desk 9-5. I'm great at my job and work my ass off, but the way I work is usually in a couple 2-hour spurts a day where I get my...
Fully agree. I'm very much wired to not be able to be sitting at my desk 9-5. I'm great at my job and work my ass off, but the way I work is usually in a couple 2-hour spurts a day where I get my full day's work done and the rest of my time spent online that day is taking care of emails, my jira board, and taking breaks between those spurts to conserve my mental. If my computer were monitored, it might appear to management that I'm only working "half time" because just monitoring computer usage is a horrible way to measure productivity.
My current boss fully understands this and wouldn't dream of babysitting me, but I dread when they retire and having the possibility that I have a new boss that wants to babysit me and doesn't let me work to my own strengths. That was what my job was two jobs ago and I was constantly stressed out and unproductive.
I agree with you that leadership monitoring their employees like that is their failure. Many people need different conditions to work optimally, like how I just can't do 8 straight hours of work, and not enough management teams in businesses understand that, even though I myself am fortunate with my boss and my teams.
An innovation in developer productivity measuring brought to you by McKinsey, a consulting firm that will definitely take your money and give you numbers if you tell them you need numbers. I...
An innovation in developer productivity measuring brought to you by McKinsey, a consulting firm that will definitely take your money and give you numbers if you tell them you need numbers.
I decided it was meaningless when there is no examination of the role of design effort, architecture, or specification. Even if you get really good at optimizing how code is produced, that's meaningless unless those developers know what you're trying to build.
Plus, similar to what @asher mentioned, I think magic metrics are a fallback for weak managers and C-level people that don't trust anyone below them to be good at their jobs. Their job should be to get in there and support their people and give them direction. But it's a lot less work to sit back and watch a dashboard.
I honestly think one of the problems in industry software engineers is that good devs get promoted until they are bad managers and they never get proper training or mentoring. Fix that and I bet a lot of the chaos lower down goes away.
I have never heard of management consultants delivering recommendations that weren't both (a) obviously wrong, and (b) flagrantly at odds with Goodhart's law.
I have never heard of management consultants delivering recommendations that weren't both (a) obviously wrong, and (b) flagrantly at odds with Goodhart's law.
There's always three sides to every story on this stuff, but I have to agree. You either embed your consultants in properly, use them to drive the strategy that YOU want... or you just leave them...
There's always three sides to every story on this stuff, but I have to agree.
You either embed your consultants in properly, use them to drive the strategy that YOU want... or you just leave them out. There's some very high-level stuff that they can get their head around, especially if it's esoteric to your industry / way of working. But so few want to drive the change they wank on and on about, they just want your currency in their pockets.
Challenge. If you can extend yourself outside the Statement of Work and you actually can drive the change, so be it. But be there for that change, not the cash it makes some clown at the top of your business. Big4 will never do that as it's risky, whilst boutiques can do all sorts of good work providing it's all aligned right.
This may be a hot take but: why are companies so obsessed with trying to get maximum time out of your day? Leadership is top down so why is "efficiency" bottom up? If there are some sort of...
This may be a hot take but: why are companies so obsessed with trying to get maximum time out of your day? Leadership is top down so why is "efficiency" bottom up? If there are some sort of productivity problems, change the way you schedule tasks or hire people who can do the task faster (i.e. Pay for more talented labor).
If you can't hire b), congrats, you have talent to further foster and an upper bound on what's possible. Keep them happy instead of choking your golden geese to death. Or your on boarding is horrible and you need to work on that. Neither have to do with current workers.
Mostly because folks misunderstand that businesses aren't there for you, they're there for stakeholders. The revenue & profit targets are set by stakeholders / boards and then the C-Suite and...
Mostly because folks misunderstand that businesses aren't there for you, they're there for stakeholders. The revenue & profit targets are set by stakeholders / boards and then the C-Suite and Leadership have to figure out how to achieve those things... very often putting them at direct odds with the people putting in the graft.
The world is full of 'leaders' who can't actually lead and are fluffy / slide deck / glass office in the corner managers with a fancy title. They're the types to micromanage, not trust their staff and generally cause problems at a lot of levels beneath them, rather than declaring a strategy, leaning in where needed and then trusting and getting out of the way.
Hiring more / better staff means that a department might cost £120K more a year. Over ten years that's £1.2M (£1.5M with inflation) that whilst we all know adds 'productivity', the shareholders simply see it coming out of their short-term revenue and profit margins and as such isn't acceptable.
The drive for quick wins in the stock market, quick wins in the profit margin mean companies do big layoffs at the end of bad-quarters / bad-years and then hire the same people back six months later (or people like them).
Companies no longer work with or for the pieces that make up the machine. They act as value extraction machines for stakeholders and shareholders who simply have very little to offer the machine. Even leadership barely lubricates that machine now, they just hit it with a crowbar and demand greater extraction.
I understand it, but I find it woefully ironic that companies traditionally want these decade+ portfolio of products, but see a $2m investment over 10 years as a risk. Meanwhile, some of these...
Hiring more / better staff means that a department might cost £120K more a year. Over ten years that's £1.2M (£1.5M with inflation) that whilst we all know adds 'productivity', the shareholders simply see it coming out of their short-term revenue and profit margins and as such isn't acceptable.
I understand it, but I find it woefully ironic that companies traditionally want these decade+ portfolio of products, but see a $2m investment over 10 years as a risk. Meanwhile, some of these executives probably made $2m within that same quarter (you know, 1/40th of this duration) and would be devaststed to sacrifice such revenue for their shareholders.
Are they truly "working in the best interest of the shareholders?". Well, I guess they get to tell the shareholders they are, while having a golden parachute at the ready. Frustrating but it's probably better use of energy to protect the workers against abuse (i.e. Not allowing easy sudden layoffs with little/zero severance. Like many other countries already do) than to worry about those who can retire tomorrow very comfortably.
Now you see why so many people stare at this nonsense and rage against it. These people don't actually add value, cut the CEO out of most businesses and you're suddenly freeing up £10M+ worth of...
I understand it, but I find it woefully ironic that companies traditionally want these decade+ portfolio of products, but see a $2m investment over 10 years as a risk. Meanwhile, some of these executives probably made $2m within that same quarter (you know, 1/40th of this duration) and would be devaststed to sacrifice such revenue for their shareholders.
Now you see why so many people stare at this nonsense and rage against it. These people don't actually add value, cut the CEO out of most businesses and you're suddenly freeing up £10M+ worth of stock, salary and bonuses to put to use adding more value.
I recently called my Director out for his £350K a year salary when he started moaning at us about platform spend. He's interefered and ensured improvements couldn't be made at every oppotunity, then moaned at us of overspend. I just quietly said something along the lines of "£350K worth of moaning at us is a good way to plug that gap" and just got on with my job.
There's so much waste at the top... and I'm at the top. I stare at it daily. Anything above "Head of" generally is wasted cash, investment and is there to cover the arse of a company legally.
Are they truly "working in the best interest of the shareholders?". Well, I guess they get to tell the shareholders they are, while having a golden parachute at the ready. Frustrating but it's probably better use of energy to protect the workers against abuse (i.e. Not allowing easy sudden layoffs with little/zero severance. Like many other countries already do) than to worry about those who can retire tomorrow very comfortably.
Generally they don't see past their own arrogance, ego and hubris. I've worked with some wicked CTOs and CDOs in the past, but they are so few and far between. Very often these people are dead-eyed, soulless husks of people who bleed whatever colour the company they work at is branded as.
They're huge drains on resources. But because they speak MBA or close enough, they get to boss people around and generally act as resource vacuums.
I started working for one of these "consultancy" companies since last year and, unfortunately, I have to say that until now every single time I was assigned to a project, it was going to shit...
I started working for one of these "consultancy" companies since last year and, unfortunately, I have to say that until now every single time I was assigned to a project, it was going to shit because the client's management have no clue of what they want and what they need.
From absurd level of micromanaging to vague and volatile requests without any respect for what the planned release was (and I'm not talking about bugs or issues).
It reached a point in which, in the internal quarterly feedback, the overwhelming majority of suggestions were "please offer the clients to teach them how to manage a tech company". I've literally asked to be removed from my last project because I couldn't bear to deal with the clients' management and how they were being bamboozled by other consultants they hired to "replace us because we were not working towards the goal". The goal is still a mystery to this day.
I can assure you, every project I joined, the people on our teams are always eager to just do something of good quality and deliver in time and mathemagically the clients' management have some moron in key position that just want to show that we are there to sabotage their company, apparently.
I couldn't give a shit about your company pal (not you specifically OBLIVIATER :P), the company I work for don't give a shit as well, we offer vastly different product and if you are successful it's good for us because of reputation and potential follow-up business.
It takes a special kind of idiots to think a consultant firm is there to damage you.
A clarification, we provide teams of people, usually a single manager to act as contact point, 1–2 architects depending on the task, and several engineers of different specialization according to needs (security, platform, engineering, QA, etc). We are not that kind of consultancy firm that submerge you with management and meetings. In fact, if a meeting exceed 30 minutes, it must be for something really fucked up that happened.
I've worked Big4 and I've ran my own consultancy firm. Whilst you're there based in a SOW, you should be able to challenge your clients on needs and wants comfortably. Most big consultancy firms...
I've worked Big4 and I've ran my own consultancy firm. Whilst you're there based in a SOW, you should be able to challenge your clients on needs and wants comfortably. Most big consultancy firms don't do that as it's risky and can cause problems for them selling later.
Rather than just do a good job, clients are just there to make money off. Doesn't matter if that's a bank or hospitals, consultants offer very little in the way of reasonable transformation or advice unless paid megabucks and even then its questionable in value.
Consultants are there to cover the top dogs arse, nothing more, nothing less.
Or they've got that hilarious swagger that salesman always have. "Yeah guv, we can deliver your checks notes £81Million digital transformation plan in 12 months" Spoiler alert. They could not.
Or they've got that hilarious swagger that salesman always have.
"Yeah guv, we can deliver your checks notes £81Million digital transformation plan in 12 months"
Then it falls on the project manager to scope things down to something realistically doable given the complete absence of any executive support or sponsorship from the customer. So they can be...
Then it falls on the project manager to scope things down to something realistically doable given the complete absence of any executive support or sponsorship from the customer. So they can be like "Yeah 'digital transformation' means a powerpoint deck right?"
Or at my current place, the Project Leads are just people who scream "I'VE GOT A FIRE... THERE'S A FIRE... QUICK SOMEONE COME AND PUT OUT THIS FIRE!" and then walk off without organising and...
Or at my current place, the Project Leads are just people who scream "I'VE GOT A FIRE... THERE'S A FIRE... QUICK SOMEONE COME AND PUT OUT THIS FIRE!" and then walk off without organising and helping in anyway. Gets infuriating.
You should recognize that giving the illusion of action without really doing anything is previously what a large swath of clients want from you. They don't know what to do, they feel something...
You should recognize that giving the illusion of action without really doing anything is previously what a large swath of clients want from you. They don't know what to do, they feel something should be done (or are told as much by the C rank and/or the board), they don't really believe a consultant knows what to do but hiring someone takes the heat off of them. But actually implementing changes would make it their responsibility again so that needs to be resisted.
Then there's the second class of customers who know exactly what they want to do (usually fire, I mean, make redundant) and need a scape goat.
With those two (and the companies catering to them) ruining the image of consultants it's not a big mistery why so many people perceive them as locusts. All the consultants who are just domain experts or drop in firefighters trying to a honest job get much less attention, mainly because they don't disrupt everything in their wake.
They refer to “DORA” metrics which don’t seem so bad? From an article about it: Those seem like measures of project health and team agility, though, not productivity?
They refer to “DORA” metrics which don’t seem so bad? From an article about it:
Through six years of research, the DevOps Research and Assessment (DORA) team has identified four key metrics that indicate the performance of a software development team:
Deployment Frequency—How often an organization successfully releases to production
Lead Time for Changes—The amount of time it takes a commit to get into production
Change Failure Rate—The percentage of deployments causing a failure in production
Time to Restore Service—How long it takes an organization to recover from a failure in production
Those seem like measures of project health and team agility, though, not productivity?
These are all fine to measure - by the team, for it to know how things are going. But once these measues become targets by higher ups, the cobra effect rears it's head. The measures are easy...
These are all fine to measure - by the team, for it to know how things are going. But once these measues become targets by higher ups, the cobra effect rears it's head. The measures are easy enough to game:
Deployment Frequency: Make deploys smaller, but less meaningful.
Lead Time for Changes: Make smaller changes, push them out with less QA.
Change Failure Rate: Manipulate issue severity, hide issues, or deploy smaller but less meaningful changes.
Time to Restore Service: Trigger service interruption through known issues, which can be quickly fixed.
Yes, and they are not the metrics McKinsey developed and wants to sell. They focus more on effort and being able to track individual performance. The article goes into detail why this is, though...
Yes, and they are not the metrics McKinsey developed and wants to sell. They focus more on effort and being able to track individual performance. The article goes into detail why this is, though tempting, a bad idea.
They lost me at "story points". I worked with Pivotal Labs on a project. They were one of the earlier to firmly embrace story points. For greenfield development, story points can work. Story...
They lost me at "story points".
I worked with Pivotal Labs on a project. They were one of the earlier to firmly embrace story points. For greenfield development, story points can work.
Story points don't work well on brown field—code you didn't write. And most software development is brown field (and, yes, the brown is for 💩): maintaining and revising an existing system that is often antiquated by degrees.
You can only do just so much to capture uncertainty in your story points. Because code is communication and communication is subjective, elaborating on code you didn't write adds more complication and reduces certainty. I've seen too many features that should have been "trivial" explode into weeks and months long efforts with brown field.
They don't work for greenfield, either, unless the project is really trivial. In my career, I've seen a team reliably produce reasonably accurate estimates once, and it was for maintenance work on...
They don't work for greenfield, either, unless the project is really trivial.
In my career, I've seen a team reliably produce reasonably accurate estimates once, and it was for maintenance work on a well-understood product that was EoL and not receiving new features. Every other team I've worked on which estimated tickets at all may as well have been using a random number generator.
There are some pretty obvious issues:
Estimation of software is just fundamentally difficult. The error bars are enormous.
Estimates are used to set deadlines, which makes them subject to Goodhart's law. If missing your estimate triggers a meeting about "why we missed this estimate", estimates will start getting sandbagged. (And if your estimates aren't used for anything, why the fuck are you making them? By definition the folks you have estimating are smart, well-educated professionals; they will notice that you're wasting their time.)
I've never seen an organization measure actuals and use them to feed back into their estimation process. This step is obviously mandatory to getting good estimates, and I've literally never seen it done.
Pushback on estimates is constant (probably due to management being well-aware they've incentivized sandbagging). This obviously does not improve the quality of those estimates.
It's weird because story points are all about getting a really rough estimate for how much you can get done in a week (or whatever time interval) and the simplest way to do that is to use whatever...
It's weird because story points are all about getting a really rough estimate for how much you can get done in a week (or whatever time interval) and the simplest way to do that is to use whatever you got done last time. That's a feedback loop that should be auto-adjusting if estimates are at all stable. They're not a real-world time estimate because it allows for point inflation or whatever. Multiply by ten if you want. Who cares, they're just points.
One of the things I've noticed is that, even if you do this, the energy that management has for scrutinizing every little detail of software development efforts (nearly always triggered by some...
I've never seen an organization measure actuals and use them to feed back into their estimation process. This step is obviously mandatory to getting good estimates, and I've literally never seen it done.
One of the things I've noticed is that, even if you do this, the energy that management has for scrutinizing every little detail of software development efforts (nearly always triggered by some upper manager who is a. annoyed by something their manager is pushing them on b. excited for some reason to try to plan out every little eventuality or c. just one of these metric-obsessed people who thinks you can predict everything with the right framework) usually peters out after too short of a period to be useful.
Basically, by the time you've sort of figured it out (or think you have), the need to report up on the estimates has diminished because you've delivered enough perceived value during that time that no one has their hackles up that your devs are just sitting around doing nothing. Or, like a golden retriever puppy, they've just moved onto the next toy.
This requires really good time keeping and then on top of that understanding the project being solved and categorizing it. I used to work for a software company that integrated with banks for...
I've never seen an organization measure actuals and use them to feed back into their estimation process. This step is obviously mandatory to getting good estimates, and I've literally never seen it done.
This requires really good time keeping and then on top of that understanding the project being solved and categorizing it. I used to work for a software company that integrated with banks for payments. These are generally fairly straightforward but the estimates are so wrong because people wouldn't track their time well, some people would dick off and some many other factors. Bank slow response, odd payments that aren't standard or each bank handles then differently even though they use the "same"format.
Probably materially harder for more complex projects.
I've been a part of one or two organizations that used past estimates to improve future accuracy. This was the glorious part of Pivotal Tracker: it did most (all?) of this work for you under the...
I've been a part of one or two organizations that used past estimates to improve future accuracy. This was the glorious part of Pivotal Tracker: it did most (all?) of this work for you under the hood! If you were serious, as a team, about consistently learning and growing, Tracker was a wonderful tool!
I’ve seen that on a smaller scale even on a greenfield project. I think being able to maintain a reasonably consistent number of story points might be a sign of maturity. When you blow the...
I’ve seen that on a smaller scale even on a greenfield project.
I think being able to maintain a reasonably consistent number of story points might be a sign of maturity. When you blow the estimates for one task, it’s time to reassess. Maybe it should be put aside for now, or broken down into smaller tasks? It seems like it should be possible to get some easier tasks done every iteration? If not, the project really is in a bad state.
Maybe something like timeboxing would be a reasonable way of avoiding spending all your team’s time on hard, difficult to measure tasks, even if they do need to be done.
Maybe you can’t estimate things until you try to code them, which might mean dividing them up into “research X” tasks that are about doing enough investigation to make an estimate and “finish X” tasks that are hopefully better estimated.
But agile is in some sense about “find a process that works for you,” even if that seems like vacuous advice, and that might mean throwing out story points entirely. I don’t know that story points make sense at all for research?
I entirely agree. What you described is how I've project managed many software efforts, particularly when the response to estimating a task is "we don't know". I love using what I called...
I entirely agree.
What you described is how I've project managed many software efforts, particularly when the response to estimating a task is "we don't know". I love using what I called time-boxed "discovery" stories. Engineers who worked for me would sometimes be annoyed. But then they wanted free license for the task to take however long it would. The challenge is always that someone with more responsibility and authority higher up is most always going to need to have expectations that are managed.
In life, there is a never a truly blank check. There are always limits, whether we see them or not.
The problem our shop had many years ago when the edict came from on high that we must now operate using Agile was that we went too by the book. Nearly all of our teams were working on established...
But agile is in some sense about “find a process that works for you,” even if that seems like vacuous advice, and that might mean throwing out story points entirely.
The problem our shop had many years ago when the edict came from on high that we must now operate using Agile was that we went too by the book. Nearly all of our teams were working on established products that, occasionally, undergo major transformations that have something resembling greenfield work but are mostly driven by maintenance and small transformations.
After a year of getting pissed off at my team for constantly missing estimates and never finishing committed work for a given Sprint, I realized the problem wasn't their throughput, it was the measurement. Story Points still had value to understand complexity, but two week timeboxes were 100% arbitrary and not even in sync with our production delivery cycle (pre-CE tools, so deployments could realistically only be done about every 6 weeks).
So we just moved our delivery tracking to Kanban and kept most of the Agile ceremonies but also reduced who needed to attend them regularly (people just sitting around listening to grooming about stuff they would never work on). We stopped worrying about the end of the next sprint and instead about the next scheduled deployment date which is all that matters anyway. Made change mgmt easier and de-stressed the team from trying to make arbitrary dates to focus instead on committing to only as much work as they could realistically take on for the week. Anyone who runs light requests more or volunteers to help others complete their tasks.
You'll never get to that spot by reading the manual, but you'll know you've gotten to where you need to when it all just feels right. As a manager so long as you're staying 100% cognizant of your devs' time and staying out of their way until they start spinning their wheels, you're doing well.
I once worked at a company which used story points and because it was a small startup we completely ignored them and just added numbers which were sort of in the right range. Unfortunately this...
I once worked at a company which used story points and because it was a small startup we completely ignored them and just added numbers which were sort of in the right range. Unfortunately this startup had a lot of mismanagement problems, stemming primarily from employing a lot of very excitable people without any impulse control (for example they did not enjoy fixing existing bugs, such as memory leaks – of which there were a great many – and instead preferred to write new code and integrate new libraries).
I think a surprisingly large problem with story point estimates specifically is that because they're numbers, it's very easy to do arithmetic with them and compute utterly meaningless things like...
I think a surprisingly large problem with story point estimates specifically is that because they're numbers, it's very easy to do arithmetic with them and compute utterly meaningless things like "velocity" or "capacity". If you're going to estimate, either (a) make it opaque to this with non-numeric t-shirt-size estimates (small/medium/large) or (b) drop the pretense and just estimate a duration of time.
Totally. It's also super easy to dream up fun numbers, and a lot harder to work out if they have any empiracle basis. For example, at the same company we had a dispute about whether the memory...
Totally. It's also super easy to dream up fun numbers, and a lot harder to work out if they have any empiracle basis. For example, at the same company we had a dispute about whether the memory leaks were causing the performance problems. People there were very convinced that this was true, but after profiling it became clear that there were a lot of threads locking the same object (so massive contention) which meant that the supposedly very parallel program was actually a very confused almost sequential program running over a lot of threads.
The problem most middle managers run into is if you record an estimated amount of time for something, it's way easier for upper mgmt to hold you to unrealistic timeframes. If you obfuscate it a...
drop the pretense and just estimate a duration of time.
The problem most middle managers run into is if you record an estimated amount of time for something, it's way easier for upper mgmt to hold you to unrealistic timeframes. If you obfuscate it a bit by just using Story Points/t-shirt sizing as a measure of complexity, then you have more ability to realistically work with your devs on when things can get done.
It's smoke and mirrors; in an ideal world it wouldn't need to exist. But, unless the devs also control their own paychecks and expenses, it's a reality they have to navigate. Good dev team managers should be able to shield them from most of that, but having a framework to help with it can make a difference.
Re who and what McKinsey are and what they are willing to participate in https://tildes.net/~finance/1at4/size_of_mckinsey_consulting_firm_opioid_settlement_increased_by_230_million...
Re who and what McKinsey are and what they are willing to participate in
Do we need article headlines like this on Tildes that read like corporate pandering? I think they create productive conversation but I do wonder about reusing clickbait headlines like this one.
Do we need article headlines like this on Tildes that read like corporate pandering? I think they create productive conversation but I do wonder about reusing clickbait headlines like this one.
The purpose of posts like these from management consultants is to generate content for “thought leadership” so they can then sell consulting based on their “expertise”. I know these guys...
The purpose of posts like these from management consultants is to generate content for “thought leadership” so they can then sell consulting based on their “expertise”.
I know these guys intimately and they are not software developers, so I wouldn’t trust anything they have to say, and in the end it doesn’t matter because we are not the target audience of the articles they write.
I work with legacy code. Sometimes it takes days to locate a bug and then it's fixed with a few small changes. To be released, the change needs to go through a QA process which adds on more hours....
I work with legacy code. Sometimes it takes days to locate a bug and then it's fixed with a few small changes. To be released, the change needs to go through a QA process which adds on more hours.
For dozens of hours of work, all you have to show for it is a two byte change in file size. There's no metric you can use from my output to measure my productivity.
The business side on the other hand, somehow doesn't have an issue occurring anymore that used to crop up all the time, so their productivity, and their metrics, are way up.
This has been particularly tough for me working in an early stage startup that has undergone huge growth. In the early days, being someone who could do this kind of digging and stop a big issue...
This has been particularly tough for me working in an early stage startup that has undergone huge growth. In the early days, being someone who could do this kind of digging and stop a big issue from recurring was recognized in-and-of-itself. It didn't matter that there weren't JIRA tickets or story points; all that mattered was that customers were happy again.
Things are a lot different now. Everything needs to have a JIRA ticket, be story pointed, t-shirt sized etc. It's a big reason why people in my position eventually just check out mentally and acquiesce to wasting large portions of their day on writing tickets before they do any little thing, even when it takes more time to write the ticket than it does to do the thing.
Jira and software like it aren't inherently useful day-to-day, at least no more than any other tool or list you could create on your own would be. And in organizations past a certain size, that is...
Jira and software like it aren't inherently useful day-to-day, at least no more than any other tool or list you could create on your own would be.
And in organizations past a certain size, that is still mostly true. However, as I tell my team, the value in creating a good who-what-why in your stories and making good use of comments and tagging are not in getting the work done, but in referencing it later.
Sure, you can always check your code libraries to know what you did, but knowing why you did it and who asked for it can save hours, days, sometimes even weeks of back and forth on the functional/architecture side of the house. It might not mean much to a developer doing the work, but it will if they find out they have to undo something later that ended up missing out on important business context.
Writ large: rough estimates, grouping of requests, and understanding technical complexities in some sort of reportable fashion are the only effective ways that workloads can be scheduled/managed as priorities shift over months and years.
So I always understand the gripe devs have about this, but it's the same thing you hear from salespeople and CRM: they just don't want to do the overhead for someone else, but they often lose sight of the bigger picture of why it's important. And, of course, there's ways of overdoing it. Only good managers find the balance.
Probably (iff you work in the tech industry) coming to a
companyhellscape near you.I posted this not because I agree with this (at all) but because I think it's interesting as an employee to be aware of what "thought 'leaders'" such as McKinsey are currently saying – it's quite likely that lots of corporates will adopt whatever they say because it's "trendy".
I've said before that software engineers and technical workers need to wake up and start unionizing. The same extractive labor practices currently applied to other workers, whose labor is less in demand, were going to come for knowledge workers.
Well... here we are. It's now been decided we're being paid too much relative to our ability to generate profits, and software production should be Taylorized somehow. Never mind the eventual effects of enshittification on customers, the burnout of existing employees after layoffs...
I'll go back to yelling at clouds, thanks for your time.
I don't think it's even that – I think it's a natural drive corporations have to drive wages down as far as possible, irrespective of output.
That's also true, but engineers' salary bands are outliers among job classifications in most companies and an easy target for extra scrutiny.
[I won't say "all" companies - in healthcare, we're still below most clinical staff, but way above administrative and facilities workers. And don't get me started on the efforts I've seen to extract more labor from clinical staff and drive salaries down. Unions work for nurses.]
The invisible hand is still ar work. I think it's sooner that SWEs will simply self employ their own products before unionizing. If they can't get 200k organizing some corporate software, they will go straight to the consumer and offer some piece of productivity or entertainment and grab the money from the collective public. Unlike other industries it is very doable for a team of 2-5 to launch a service and make 7 figures. Peanuts for a corporation, a modest living for a small team.
Companies weren't necessarily paying those engineering wages just to be competitive with other companies. They also don't want the next unicorn forming under their nose.
The place I'm currently heading out of the door from (3 more weeks, that's all I've got left come on) have recently just started a huge shift from <fun, safe, happy-clappy if a tad dysfunctional> culturally to <over-the-top, draconian, metric-heavy> approach. You can tell the newest Directors have their claws into everyone else via bullying tactics and the Chief is absolutely useless at controlling their problems.
There's serious senior leadership hemmoraging happening (myself included) with people who just do not want to be around for that transformation.
There's still this drive for PRODUCTIVITY AT ALL COSTS that absolutely just... falls on deaf ears these days. Post-Covid, people are demanding more understanding, respect and honesty from leaders. Seeing things like this from cuntsultants is nothing more than a misunderstood ideal of what a software team SHOULD be, rather than what it is.
In my capacity as former consultant I hereby absolve you of the abusive wordplay you used because this form of consultancy is morally corrupt and detestable.
Dear /u/Trauma,
I here and understand your pain. I too am a former consultant, I also retain my Directorship in my small consultancy that I span up after time at a Big4. I feel your pain, I understand your pain, I am absolving you of all transgressions for the bullshit we do to exist in this damn system.
So much of it is now. It's not even leadership anymore, it's just "WORK HARDER SLAVES!"
This made me giggle, thank you.
Ah yes, McKinsey, the "morally neutral" company.
Another Big4 consultancy, Accenture, hasn't received nearly enough scrutiny for its failures and outsourcing practices, either. A company I used to work for turned its "pivot to the cloud" (oh, wait, the current buzzphrase is "digital transformation") over to Accenture, and it did not turn out well.*
*I'm still not sure I'm at liberty to say more even years later. Let's say the Hertz analysis applies, plus.
Yeah we're in the process of doing a lot of that. It's not going well, but they'll keep going with it it so they have extra money to give back to shareholders!
Maybe for straight forward coding tasks, but there are so many intangibles. I dislike how the article frames productivity.
Who on the team builds team cohesion and improves moral? Who on the team acts as a sounding board or provides support when someone else is stuck? Which team member comes up with creative solutions to the problems that crop up in development or R&D? There are so many ways to measure "productivity" and as McKinsey likes to do, they have chosen short sighted metrics.
There is a parallel in hen breeding:
Selecting the hen who lays the most eggs doesn't necessarily get you the most efficient egg-laying metabolism. It may get you the most dominant hen, that pecked its way to the top of the pecking order at the expense of other hens. Individual selection doesn't necessarily work to the benefit of the group, but a farm's productivity is determined by group outputs.
Similarly, a worker can be incredibly productive and still bring down the total productivity of the whole team.
I actually came across an article on that kind of person on a team and how they are often overlooked for promotions and stuff: https://noidea.dog/glue
I work in cyber security. The amount of data a company can collect on your employee owned device is incredible. Screen on time, keystrokes, mouse movement (or lack of), frequency of use, etc.. Of course this can be useful for security...and measuring performance.
At least at my company, all of this data is ingested into Tableau. Our execs can see exactly who is working, for how long, and compare it to results they want to see. In my opinion, this shows weak leadership from my executives. Time does not equal work. If you can do your "9 to 5" job in 30 minutes, then that should be rewarded. Instead, it appears as laziness.
We have more layoffs coming soon, and it's almost entirely based off of bullshit metrics.
Tangentially related to this, but I'm always amazed by people who carry out any personal activity on a work device or a system owned/controlled by their employers.
Apple are quite bad in this way, because Apple employees who work on the iPhone are required to use one as their personal device, and the kind of information you would put on your personal device is not something that you want ending up in a deposition. This has actually happened, for example some employees have found that their (what they thought were very private) nudes are now on a device which has been surrendered to a court.
What’s funny is if you work at Android there is no similar requirement.
I mean, my best advice to anyone:
If you can see it on a screen, so can the rest of the world inside of an hour.
Fully agree. I'm very much wired to not be able to be sitting at my desk 9-5. I'm great at my job and work my ass off, but the way I work is usually in a couple 2-hour spurts a day where I get my full day's work done and the rest of my time spent online that day is taking care of emails, my jira board, and taking breaks between those spurts to conserve my mental. If my computer were monitored, it might appear to management that I'm only working "half time" because just monitoring computer usage is a horrible way to measure productivity.
My current boss fully understands this and wouldn't dream of babysitting me, but I dread when they retire and having the possibility that I have a new boss that wants to babysit me and doesn't let me work to my own strengths. That was what my job was two jobs ago and I was constantly stressed out and unproductive.
I agree with you that leadership monitoring their employees like that is their failure. Many people need different conditions to work optimally, like how I just can't do 8 straight hours of work, and not enough management teams in businesses understand that, even though I myself am fortunate with my boss and my teams.
Although it doesn't measure the 3-4 hours I sat with a notebook and pen where-the-fuck-I-like planning and brainstorming the next project 🤦🏻♂️
I feel like this is inevitable if we are going to go with remote work long time.
In many jurisdictions this isn't legal and so we have hope that the worst snooping excesses will stay limited to the anglosphere.
An innovation in developer productivity measuring brought to you by McKinsey, a consulting firm that will definitely take your money and give you numbers if you tell them you need numbers.
I decided it was meaningless when there is no examination of the role of design effort, architecture, or specification. Even if you get really good at optimizing how code is produced, that's meaningless unless those developers know what you're trying to build.
Plus, similar to what @asher mentioned, I think magic metrics are a fallback for weak managers and C-level people that don't trust anyone below them to be good at their jobs. Their job should be to get in there and support their people and give them direction. But it's a lot less work to sit back and watch a dashboard.
I honestly think one of the problems in industry software engineers is that good devs get promoted until they are bad managers and they never get proper training or mentoring. Fix that and I bet a lot of the chaos lower down goes away.
Consultants are a cancer on the tech industry. 95% of them are parasites taking money away from the workers
Not even just the tech industry mate, pretty much anywhere they land their grubby little mits.
I have never heard of management consultants delivering recommendations that weren't both (a) obviously wrong, and (b) flagrantly at odds with Goodhart's law.
There's always three sides to every story on this stuff, but I have to agree.
You either embed your consultants in properly, use them to drive the strategy that YOU want... or you just leave them out. There's some very high-level stuff that they can get their head around, especially if it's esoteric to your industry / way of working. But so few want to drive the change they wank on and on about, they just want your currency in their pockets.
Challenge. If you can extend yourself outside the Statement of Work and you actually can drive the change, so be it. But be there for that change, not the cash it makes some clown at the top of your business. Big4 will never do that as it's risky, whilst boutiques can do all sorts of good work providing it's all aligned right.
This may be a hot take but: why are companies so obsessed with trying to get maximum time out of your day? Leadership is top down so why is "efficiency" bottom up? If there are some sort of productivity problems, change the way you schedule tasks or hire people who can do the task faster (i.e. Pay for more talented labor).
If you can't hire b), congrats, you have talent to further foster and an upper bound on what's possible. Keep them happy instead of choking your golden geese to death. Or your on boarding is horrible and you need to work on that. Neither have to do with current workers.
Mostly because folks misunderstand that businesses aren't there for you, they're there for stakeholders. The revenue & profit targets are set by stakeholders / boards and then the C-Suite and Leadership have to figure out how to achieve those things... very often putting them at direct odds with the people putting in the graft.
The world is full of 'leaders' who can't actually lead and are fluffy / slide deck / glass office in the corner managers with a fancy title. They're the types to micromanage, not trust their staff and generally cause problems at a lot of levels beneath them, rather than declaring a strategy, leaning in where needed and then trusting and getting out of the way.
Hiring more / better staff means that a department might cost £120K more a year. Over ten years that's £1.2M (£1.5M with inflation) that whilst we all know adds 'productivity', the shareholders simply see it coming out of their short-term revenue and profit margins and as such isn't acceptable.
The drive for quick wins in the stock market, quick wins in the profit margin mean companies do big layoffs at the end of bad-quarters / bad-years and then hire the same people back six months later (or people like them).
Companies no longer work with or for the pieces that make up the machine. They act as value extraction machines for stakeholders and shareholders who simply have very little to offer the machine. Even leadership barely lubricates that machine now, they just hit it with a crowbar and demand greater extraction.
I understand it, but I find it woefully ironic that companies traditionally want these decade+ portfolio of products, but see a $2m investment over 10 years as a risk. Meanwhile, some of these executives probably made $2m within that same quarter (you know, 1/40th of this duration) and would be devaststed to sacrifice such revenue for their shareholders.
Are they truly "working in the best interest of the shareholders?". Well, I guess they get to tell the shareholders they are, while having a golden parachute at the ready. Frustrating but it's probably better use of energy to protect the workers against abuse (i.e. Not allowing easy sudden layoffs with little/zero severance. Like many other countries already do) than to worry about those who can retire tomorrow very comfortably.
Now you see why so many people stare at this nonsense and rage against it. These people don't actually add value, cut the CEO out of most businesses and you're suddenly freeing up £10M+ worth of stock, salary and bonuses to put to use adding more value.
I recently called my Director out for his £350K a year salary when he started moaning at us about platform spend. He's interefered and ensured improvements couldn't be made at every oppotunity, then moaned at us of overspend. I just quietly said something along the lines of "£350K worth of moaning at us is a good way to plug that gap" and just got on with my job.
There's so much waste at the top... and I'm at the top. I stare at it daily. Anything above "Head of" generally is wasted cash, investment and is there to cover the arse of a company legally.
Generally they don't see past their own arrogance, ego and hubris. I've worked with some wicked CTOs and CDOs in the past, but they are so few and far between. Very often these people are dead-eyed, soulless husks of people who bleed whatever colour the company they work at is branded as.
They're huge drains on resources. But because they speak MBA or close enough, they get to boss people around and generally act as resource vacuums.
It can be frustrating.
I started working for one of these "consultancy" companies since last year and, unfortunately, I have to say that until now every single time I was assigned to a project, it was going to shit because the client's management have no clue of what they want and what they need.
From absurd level of micromanaging to vague and volatile requests without any respect for what the planned release was (and I'm not talking about bugs or issues).
It reached a point in which, in the internal quarterly feedback, the overwhelming majority of suggestions were "please offer the clients to teach them how to manage a tech company". I've literally asked to be removed from my last project because I couldn't bear to deal with the clients' management and how they were being bamboozled by other consultants they hired to "replace us because we were not working towards the goal". The goal is still a mystery to this day.
I can assure you, every project I joined, the people on our teams are always eager to just do something of good quality and deliver in time and mathemagically the clients' management have some moron in key position that just want to show that we are there to sabotage their company, apparently.
I couldn't give a shit about your company pal (not you specifically OBLIVIATER :P), the company I work for don't give a shit as well, we offer vastly different product and if you are successful it's good for us because of reputation and potential follow-up business.
It takes a special kind of idiots to think a consultant firm is there to damage you.
A clarification, we provide teams of people, usually a single manager to act as contact point, 1–2 architects depending on the task, and several engineers of different specialization according to needs (security, platform, engineering, QA, etc). We are not that kind of consultancy firm that submerge you with management and meetings. In fact, if a meeting exceed 30 minutes, it must be for something really fucked up that happened.
I've worked Big4 and I've ran my own consultancy firm. Whilst you're there based in a SOW, you should be able to challenge your clients on needs and wants comfortably. Most big consultancy firms don't do that as it's risky and can cause problems for them selling later.
Rather than just do a good job, clients are just there to make money off. Doesn't matter if that's a bank or hospitals, consultants offer very little in the way of reasonable transformation or advice unless paid megabucks and even then its questionable in value.
Consultants are there to cover the top dogs arse, nothing more, nothing less.
Also their analysts are in their 20s and don't know how to talk to senior executives without either embarrassing their team or pooping their pants.
Or they've got that hilarious swagger that salesman always have.
"Yeah guv, we can deliver your checks notes £81Million digital transformation plan in 12 months"
Spoiler alert. They could not.
Then it falls on the project manager to scope things down to something realistically doable given the complete absence of any executive support or sponsorship from the customer. So they can be like "Yeah 'digital transformation' means a powerpoint deck right?"
Or at my current place, the Project Leads are just people who scream "I'VE GOT A FIRE... THERE'S A FIRE... QUICK SOMEONE COME AND PUT OUT THIS FIRE!" and then walk off without organising and helping in anyway. Gets infuriating.
You should recognize that giving the illusion of action without really doing anything is previously what a large swath of clients want from you. They don't know what to do, they feel something should be done (or are told as much by the C rank and/or the board), they don't really believe a consultant knows what to do but hiring someone takes the heat off of them. But actually implementing changes would make it their responsibility again so that needs to be resisted.
Then there's the second class of customers who know exactly what they want to do (usually fire, I mean, make redundant) and need a scape goat.
With those two (and the companies catering to them) ruining the image of consultants it's not a big mistery why so many people perceive them as locusts. All the consultants who are just domain experts or drop in firefighters trying to a honest job get much less attention, mainly because they don't disrupt everything in their wake.
They also remove excess profit from the C-suite and shareholders. It's the classic rainmaker scam.
They refer to “DORA” metrics which don’t seem so bad? From an article about it:
Those seem like measures of project health and team agility, though, not productivity?
These are all fine to measure - by the team, for it to know how things are going. But once these measues become targets by higher ups, the cobra effect rears it's head. The measures are easy enough to game:
Yes, and they are not the metrics McKinsey developed and wants to sell. They focus more on effort and being able to track individual performance. The article goes into detail why this is, though tempting, a bad idea.
Pragmatic Engineer wrote a pretty good response to this https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity
They lost me at "story points".
I worked with Pivotal Labs on a project. They were one of the earlier to firmly embrace story points. For greenfield development, story points can work.
Story points don't work well on brown field—code you didn't write. And most software development is brown field (and, yes, the brown is for 💩): maintaining and revising an existing system that is often antiquated by degrees.
You can only do just so much to capture uncertainty in your story points. Because code is communication and communication is subjective, elaborating on code you didn't write adds more complication and reduces certainty. I've seen too many features that should have been "trivial" explode into weeks and months long efforts with brown field.
They don't work for greenfield, either, unless the project is really trivial.
In my career, I've seen a team reliably produce reasonably accurate estimates once, and it was for maintenance work on a well-understood product that was EoL and not receiving new features. Every other team I've worked on which estimated tickets at all may as well have been using a random number generator.
There are some pretty obvious issues:
It's weird because story points are all about getting a really rough estimate for how much you can get done in a week (or whatever time interval) and the simplest way to do that is to use whatever you got done last time. That's a feedback loop that should be auto-adjusting if estimates are at all stable. They're not a real-world time estimate because it allows for point inflation or whatever. Multiply by ten if you want. Who cares, they're just points.
But yeah, sometimes they're not stable.
One of the things I've noticed is that, even if you do this, the energy that management has for scrutinizing every little detail of software development efforts (nearly always triggered by some upper manager who is a. annoyed by something their manager is pushing them on b. excited for some reason to try to plan out every little eventuality or c. just one of these metric-obsessed people who thinks you can predict everything with the right framework) usually peters out after too short of a period to be useful.
Basically, by the time you've sort of figured it out (or think you have), the need to report up on the estimates has diminished because you've delivered enough perceived value during that time that no one has their hackles up that your devs are just sitting around doing nothing. Or, like a golden retriever puppy, they've just moved onto the next toy.
This requires really good time keeping and then on top of that understanding the project being solved and categorizing it. I used to work for a software company that integrated with banks for payments. These are generally fairly straightforward but the estimates are so wrong because people wouldn't track their time well, some people would dick off and some many other factors. Bank slow response, odd payments that aren't standard or each bank handles then differently even though they use the "same"format.
Probably materially harder for more complex projects.
I've been a part of one or two organizations that used past estimates to improve future accuracy. This was the glorious part of Pivotal Tracker: it did most (all?) of this work for you under the hood! If you were serious, as a team, about consistently learning and growing, Tracker was a wonderful tool!
I’ve seen that on a smaller scale even on a greenfield project.
I think being able to maintain a reasonably consistent number of story points might be a sign of maturity. When you blow the estimates for one task, it’s time to reassess. Maybe it should be put aside for now, or broken down into smaller tasks? It seems like it should be possible to get some easier tasks done every iteration? If not, the project really is in a bad state.
Maybe something like timeboxing would be a reasonable way of avoiding spending all your team’s time on hard, difficult to measure tasks, even if they do need to be done.
Maybe you can’t estimate things until you try to code them, which might mean dividing them up into “research X” tasks that are about doing enough investigation to make an estimate and “finish X” tasks that are hopefully better estimated.
But agile is in some sense about “find a process that works for you,” even if that seems like vacuous advice, and that might mean throwing out story points entirely. I don’t know that story points make sense at all for research?
I entirely agree.
What you described is how I've project managed many software efforts, particularly when the response to estimating a task is "we don't know". I love using what I called time-boxed "discovery" stories. Engineers who worked for me would sometimes be annoyed. But then they wanted free license for the task to take however long it would. The challenge is always that someone with more responsibility and authority higher up is most always going to need to have expectations that are managed.
In life, there is a never a truly blank check. There are always limits, whether we see them or not.
The problem our shop had many years ago when the edict came from on high that we must now operate using Agile was that we went too by the book. Nearly all of our teams were working on established products that, occasionally, undergo major transformations that have something resembling greenfield work but are mostly driven by maintenance and small transformations.
After a year of getting pissed off at my team for constantly missing estimates and never finishing committed work for a given Sprint, I realized the problem wasn't their throughput, it was the measurement. Story Points still had value to understand complexity, but two week timeboxes were 100% arbitrary and not even in sync with our production delivery cycle (pre-CE tools, so deployments could realistically only be done about every 6 weeks).
So we just moved our delivery tracking to Kanban and kept most of the Agile ceremonies but also reduced who needed to attend them regularly (people just sitting around listening to grooming about stuff they would never work on). We stopped worrying about the end of the next sprint and instead about the next scheduled deployment date which is all that matters anyway. Made change mgmt easier and de-stressed the team from trying to make arbitrary dates to focus instead on committing to only as much work as they could realistically take on for the week. Anyone who runs light requests more or volunteers to help others complete their tasks.
You'll never get to that spot by reading the manual, but you'll know you've gotten to where you need to when it all just feels right. As a manager so long as you're staying 100% cognizant of your devs' time and staying out of their way until they start spinning their wheels, you're doing well.
I once worked at a company which used story points and because it was a small startup we completely ignored them and just added numbers which were sort of in the right range. Unfortunately this startup had a lot of mismanagement problems, stemming primarily from employing a lot of very excitable people without any impulse control (for example they did not enjoy fixing existing bugs, such as memory leaks – of which there were a great many – and instead preferred to write new code and integrate new libraries).
I think a surprisingly large problem with story point estimates specifically is that because they're numbers, it's very easy to do arithmetic with them and compute utterly meaningless things like "velocity" or "capacity". If you're going to estimate, either (a) make it opaque to this with non-numeric t-shirt-size estimates (small/medium/large) or (b) drop the pretense and just estimate a duration of time.
Totally. It's also super easy to dream up fun numbers, and a lot harder to work out if they have any empiracle basis. For example, at the same company we had a dispute about whether the memory leaks were causing the performance problems. People there were very convinced that this was true, but after profiling it became clear that there were a lot of threads locking the same object (so massive contention) which meant that the supposedly very parallel program was actually a very confused almost sequential program running over a lot of threads.
The problem most middle managers run into is if you record an estimated amount of time for something, it's way easier for upper mgmt to hold you to unrealistic timeframes. If you obfuscate it a bit by just using Story Points/t-shirt sizing as a measure of complexity, then you have more ability to realistically work with your devs on when things can get done.
It's smoke and mirrors; in an ideal world it wouldn't need to exist. But, unless the devs also control their own paychecks and expenses, it's a reality they have to navigate. Good dev team managers should be able to shield them from most of that, but having a framework to help with it can make a difference.
Re who and what McKinsey are and what they are willing to participate in
https://tildes.net/~finance/1at4/size_of_mckinsey_consulting_firm_opioid_settlement_increased_by_230_million
https://tildes.net/~finance/1at5/when_mckinsey_comes_to_town
https://tildes.net/~life/1alx/confessions_of_a_mckinsey_whistleblower
https://tildes.net/~misc/jth/how_mckinsey_helped_the_trump_administration_carry_out_its_immigration_policies
https://tildes.net/~finance/fec/the_story_mckinsey_didnt_want_written
Do we need article headlines like this on Tildes that read like corporate pandering? I think they create productive conversation but I do wonder about reusing clickbait headlines like this one.
The best engineers I know get awful DORA metrics. Sure, you can measure them, but is measurement worth it if you push top talent away?
The purpose of posts like these from management consultants is to generate content for “thought leadership” so they can then sell consulting based on their “expertise”.
I know these guys intimately and they are not software developers, so I wouldn’t trust anything they have to say, and in the end it doesn’t matter because we are not the target audience of the articles they write.
Software developers are not the target audience – executives are, and what they think matters for workers!
I work with legacy code. Sometimes it takes days to locate a bug and then it's fixed with a few small changes. To be released, the change needs to go through a QA process which adds on more hours.
For dozens of hours of work, all you have to show for it is a two byte change in file size. There's no metric you can use from my output to measure my productivity.
The business side on the other hand, somehow doesn't have an issue occurring anymore that used to crop up all the time, so their productivity, and their metrics, are way up.
This has been particularly tough for me working in an early stage startup that has undergone huge growth. In the early days, being someone who could do this kind of digging and stop a big issue from recurring was recognized in-and-of-itself. It didn't matter that there weren't JIRA tickets or story points; all that mattered was that customers were happy again.
Things are a lot different now. Everything needs to have a JIRA ticket, be story pointed, t-shirt sized etc. It's a big reason why people in my position eventually just check out mentally and acquiesce to wasting large portions of their day on writing tickets before they do any little thing, even when it takes more time to write the ticket than it does to do the thing.
Jira and software like it aren't inherently useful day-to-day, at least no more than any other tool or list you could create on your own would be.
And in organizations past a certain size, that is still mostly true. However, as I tell my team, the value in creating a good who-what-why in your stories and making good use of comments and tagging are not in getting the work done, but in referencing it later.
Sure, you can always check your code libraries to know what you did, but knowing why you did it and who asked for it can save hours, days, sometimes even weeks of back and forth on the functional/architecture side of the house. It might not mean much to a developer doing the work, but it will if they find out they have to undo something later that ended up missing out on important business context.
Writ large: rough estimates, grouping of requests, and understanding technical complexities in some sort of reportable fashion are the only effective ways that workloads can be scheduled/managed as priorities shift over months and years.
So I always understand the gripe devs have about this, but it's the same thing you hear from salespeople and CRM: they just don't want to do the overhead for someone else, but they often lose sight of the bigger picture of why it's important. And, of course, there's ways of overdoing it. Only good managers find the balance.