Your Company's Problem is Hiding in Plain Sight - High Work-In-Progress (WIP)(mdalmijn.com)
mdalmijn.com
Your Company's Problem is Hiding in Plain Sight - High Work-In-Progress (WIP)
https://mdalmijn.com/p/your-companys-problem-is-hiding-in
46 comments
Scrum is not "Agile cosplay." It's just a different way of limiting WIP. First off, go to the Scrum Guide and show me where it's required to use Story Points in Scrum . . . it's not.
All Scrum says is to pick a goal to accomplish in 1-4 weeks, build a backlog of stuff you need to do to accomplish the goal, go do it, show it to the stakeholders, and retrospect. You limit WIP by focusing on one goal and only pulling in what's necessary to get there in 1-4 weeks.
Kanban is a perfectly valid way of doing things as well, but half the Scrum-bashers out there are taking big whacks at a strawman, because 80 percent of the time, they're not actually attacking Scrum. They're attacking some ancillary practices someone tacked on like planning poker, story points, burndowns/burnups, etc. Or they're mad at some idiot manager or executive, often rightfully so, for misunderstanding what Scrum even is or misusing it to abuse people. Don't blame the tool when someone misuses the tool.
Some of the worst words ever written in software were when Jeff Sutherland talked about "twice the work in half the time."
All Scrum says is to pick a goal to accomplish in 1-4 weeks, build a backlog of stuff you need to do to accomplish the goal, go do it, show it to the stakeholders, and retrospect. You limit WIP by focusing on one goal and only pulling in what's necessary to get there in 1-4 weeks.
Kanban is a perfectly valid way of doing things as well, but half the Scrum-bashers out there are taking big whacks at a strawman, because 80 percent of the time, they're not actually attacking Scrum. They're attacking some ancillary practices someone tacked on like planning poker, story points, burndowns/burnups, etc. Or they're mad at some idiot manager or executive, often rightfully so, for misunderstanding what Scrum even is or misusing it to abuse people. Don't blame the tool when someone misuses the tool.
Some of the worst words ever written in software were when Jeff Sutherland talked about "twice the work in half the time."
if you look closely, I didn't say Scrum IS agile cosplay.... I said it encourages it. IMHO The problem with Scrum is that the nature of Scrum encourages the abuse of it. It is ripe for gaming, ripe for making jobs that didn't need to be jobs, adding busywork, etc.
I work in technical diligence, and have personally interviewed about ~60 companies now on their processes among other things. I have definitely seen good, high-functioning Scrum! But I see it abused more, and in my experience every scrum team I've been on suffers those problems, whether mild or extreme. I just don't think choosing a process that sets you up for organizational process abuse is a good plan.
Left to my own devices, I would use a combination of Kanban and XP, with Scrum retrospectives. Figuring out how many things can fit precisely in the next two weeks would be the first thing on the chopping block - mostly a waste of time and gamed all the time.
Of course the real elephant in the room is that agile at its fundamental core is predicated on good automated testing and most teams don't have good automated testing. I would estimate ~10-20% of teams I talk to are actually doing agile as it was intended in the manifesto. (And these are companies that are getting major investments or aquisitions, or we wouldn't be talking to them). :-/
I work in technical diligence, and have personally interviewed about ~60 companies now on their processes among other things. I have definitely seen good, high-functioning Scrum! But I see it abused more, and in my experience every scrum team I've been on suffers those problems, whether mild or extreme. I just don't think choosing a process that sets you up for organizational process abuse is a good plan.
Left to my own devices, I would use a combination of Kanban and XP, with Scrum retrospectives. Figuring out how many things can fit precisely in the next two weeks would be the first thing on the chopping block - mostly a waste of time and gamed all the time.
Of course the real elephant in the room is that agile at its fundamental core is predicated on good automated testing and most teams don't have good automated testing. I would estimate ~10-20% of teams I talk to are actually doing agile as it was intended in the manifesto. (And these are companies that are getting major investments or aquisitions, or we wouldn't be talking to them). :-/
Very fair points. There's a lot of cheap Agile-bashing online, on LinkedIn, etc. and it often comes down to folks missing many of the points you make here.
Scrum isn't the be-all and end-all, but like many things people like to deride, it ultimately comes down to someone saying "that Agile Manifesto sounds great, but what do I actually need to DO?"
Scrum isn't the be-all and end-all, but like many things people like to deride, it ultimately comes down to someone saying "that Agile Manifesto sounds great, but what do I actually need to DO?"
>Don't blame the tool when someone misuses the tool.
Sure, but just like when finding the fault with everything indicates the fault is in you if almost everyone misuses a tool the fault is in the tool.
Sure, but just like when finding the fault with everything indicates the fault is in you if almost everyone misuses a tool the fault is in the tool.
You can't win. Scrum is "purposely incomplete," so everyone complains that it's too theoretical and not prescriptive enough, so people extend it and expand on it and then get told "that's too heavyweight; we don't need a detailed framework."
As I’ve read your replies, it sounds like you’re defending Agile, not Scrum. Scrum is more prescriptive. I’ve never worked in a Scrum shop or even heard of one that didn’t have all the features commonly associated with it: burndown charts, backlog refinement with some kind of pointing consensus, retros, and a scrum master that drives all of these.
Could you provide some material that explains how to do Scrum in a different way?
Could you provide some material that explains how to do Scrum in a different way?
Yeah, the literal document by Ken Schwaber and Jeff Sutherland that says what Scrum is.
https://www.scrum.org/resources/scrum-guide
Some quotes to keep in mind:
> As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.
> Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Burndown charts can be used in Scrum, but are not Scrum. Backlog refinement is an ongoing activity in Scrum, but its precise form is left undefined. Story points can be used in Scrum, but are not Scrum. The Scrum Master is a role which is explicitly defined in the Scrum Guide, but there is nothing there claiming they are there to "drive" anything, only be "true leaders who serve the Scrum Team and the larger organization." The retrospective is defined in the Scrum Guide, but its precise form is left undefined.
https://www.scrum.org/resources/scrum-guide
Some quotes to keep in mind:
> As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.
> Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Burndown charts can be used in Scrum, but are not Scrum. Backlog refinement is an ongoing activity in Scrum, but its precise form is left undefined. Story points can be used in Scrum, but are not Scrum. The Scrum Master is a role which is explicitly defined in the Scrum Guide, but there is nothing there claiming they are there to "drive" anything, only be "true leaders who serve the Scrum Team and the larger organization." The retrospective is defined in the Scrum Guide, but its precise form is left undefined.
That’s great, but it’s still too vague. If the industry is geared towards a specific implementation of these nebulous descriptions, with all of their scrum conferences and scrum master certification courses, then the common implementation becomes a defining characteristic.
A scrum master should be a true leader… well, part of being a true leader is being direct and firm when the going gets tough. Push eventually comes to shove. A team isn’t tracking to their goal for the sprint? Push. A team repeatedly fails to meet a prior high water mark for velocity? Shove.
Can you provide some examples of places you’ve worked at that do Scrum in different ways than the common cliché?
A scrum master should be a true leader… well, part of being a true leader is being direct and firm when the going gets tough. Push eventually comes to shove. A team isn’t tracking to their goal for the sprint? Push. A team repeatedly fails to meet a prior high water mark for velocity? Shove.
Can you provide some examples of places you’ve worked at that do Scrum in different ways than the common cliché?
Who complained Scrum is not agile and Scrum should be more prescriptive?
> … indicates the fault is in you if almost everyone misuses a tool the fault is in tool
Or, more likely I think, because the tool is popular and is used by many companies, is statistically more likely to find it misused.
Or, more likely I think, because the tool is popular and is used by many companies, is statistically more likely to find it misused.
statistically more likely to find it misused does not seem to match up with almost everyone misuses, although I guess you could argue there was some sort of law that once a tool moves beyond only expert usage to ubiquitous usage all non expert users added in ubiquitous phase will misuse tool therefore making it seem that it is the tool's fault.
I would argue however this is not the case for well-designed tools, and then people who are not experts can become experts with such and not misuse, keeping the percentage of misuse of a well-designed tool at an even level as usage increase.
The percentage of misuse rising at a rate nearly equal to its usage rate indicates a poorly designed tool / that something is lacking.
I would argue however this is not the case for well-designed tools, and then people who are not experts can become experts with such and not misuse, keeping the percentage of misuse of a well-designed tool at an even level as usage increase.
The percentage of misuse rising at a rate nearly equal to its usage rate indicates a poorly designed tool / that something is lacking.
Is this the book you're referring to? https://www.microsoftpressstore.com/store/agile-project-mana...
Yup!
OP, please don't leave us hangin'.
I like to think of scrum as more a "build up to" than a start at type process. Start with kanban and add as you have time and see fit.
Need to forecast when something will be done? Do sprint planning and assign some story points
Want to track cadence over time? Set a sprint start/stop date so you can measure in time periods
Feeling comfortable in your process and want to continue to look for improvements? Add retros
Working on high collaboration work and need progress updates? Change frequency of stand-ups
Later, you might be in a crunch to complete a big project and sprint planning is redundant since you already have a decent amount planned
Need to forecast when something will be done? Do sprint planning and assign some story points
Want to track cadence over time? Set a sprint start/stop date so you can measure in time periods
Feeling comfortable in your process and want to continue to look for improvements? Add retros
Working on high collaboration work and need progress updates? Change frequency of stand-ups
Later, you might be in a crunch to complete a big project and sprint planning is redundant since you already have a decent amount planned
Sprints are not needed to measure cycle time and forecast.
> Kanban actually helps development go faster.
I agree, but was interesting to see mgmt at a startup I was at fight against this in favor of their "scrum" - they liked sprints because they'd push devs to commit to more work, and then scold people when they didn't finish enough. They were convinced they were speeding things up.. I left shortly after but was first time I'd seen "agile" abused this way.
I agree, but was interesting to see mgmt at a startup I was at fight against this in favor of their "scrum" - they liked sprints because they'd push devs to commit to more work, and then scold people when they didn't finish enough. They were convinced they were speeding things up.. I left shortly after but was first time I'd seen "agile" abused this way.
It happens all the time. And then that encourages the weasels on the dev team (every team has some!) to game the system that way, overpointing the tasks they know they can take and kick out quickly to look like rockstars.
IMHO with Scrum it takes very few bad apples for the whole thing to fall down.
IMHO with Scrum it takes very few bad apples for the whole thing to fall down.
^this on so many levels.
IMO, a company that does one well will do their other one well.
I’ve personally found that the lack of barriers on Kanban allows teams to get sloppy with the work they accomplish. Having a cycle or cadence give an intentional space for the team to scrutinize their work.
I’ve personally found that the lack of barriers on Kanban allows teams to get sloppy with the work they accomplish. Having a cycle or cadence give an intentional space for the team to scrutinize their work.
Personally I find myself radically under-extended by the typical one-thing-at-a-time mentality. One at a time feels like accepted dogma, and pushback feels extreme & immediate if I as a dev attempt anything else. Businesses really want exact control & certain knowledge over how I spend every minute of developer time.
And I think it's such a waste, in my view. When I write code or make designs, usually the first couple cuts aren't great! They usually work, but how I lay out interfaces & how the code is structured tends to be pretty so so. Insight is garnered over time & experience.
Hammock Driven Development (Rich Hickey) speaks to me a lot. Sit back and reflect; consider what we are doing, how it's going. Reconsider the possibilities. https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
Now, if work wants to pay me to spend 2/3rds my time just reflecting & pondering one thing at a time, I think that would work. But what makes sense to me is to have a couple things in flight, ideally staggered at slightly different phases of development, and to shift between them as the whims take me. Give myself time to decompress & reflect on one thing, by picking up another item that I've been pondering for a while.
It feels so unnatural & suboptimal, what we do to developers. The expectation of constant productivity in one task feels like such a recipe for bad code. I have no idea how so many people do it. It boggles my mind seeing folks able to stay to task, able to power through, without these pauses & times for reflection.
I wish so much there was some affordances, some option, something available for those of us who don't work well one task at a time. I want to be juggling more of the world at once, switching on and off tasks, having intervals & spacing between working specific areas of the code. I just don't see this perspective mirrored at all in the world, don't see anything at all that reflects what works for me, that reflects how hard it is for me to feel good about my work when I'm managed down, as though a machine that just has to turn a crank until it's done. My mind just is not that fast & direct, not that quick to settle and resolve the complexities of system; I need some dwell times built in. I don't know what would happen to velocity, but quality would be much higher & I'd be so much better able to flow, to latch onto tasks I was much more primed for. Please, someone, give the Hammock Driven Devs a chance.
And I think it's such a waste, in my view. When I write code or make designs, usually the first couple cuts aren't great! They usually work, but how I lay out interfaces & how the code is structured tends to be pretty so so. Insight is garnered over time & experience.
Hammock Driven Development (Rich Hickey) speaks to me a lot. Sit back and reflect; consider what we are doing, how it's going. Reconsider the possibilities. https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
Now, if work wants to pay me to spend 2/3rds my time just reflecting & pondering one thing at a time, I think that would work. But what makes sense to me is to have a couple things in flight, ideally staggered at slightly different phases of development, and to shift between them as the whims take me. Give myself time to decompress & reflect on one thing, by picking up another item that I've been pondering for a while.
It feels so unnatural & suboptimal, what we do to developers. The expectation of constant productivity in one task feels like such a recipe for bad code. I have no idea how so many people do it. It boggles my mind seeing folks able to stay to task, able to power through, without these pauses & times for reflection.
I wish so much there was some affordances, some option, something available for those of us who don't work well one task at a time. I want to be juggling more of the world at once, switching on and off tasks, having intervals & spacing between working specific areas of the code. I just don't see this perspective mirrored at all in the world, don't see anything at all that reflects what works for me, that reflects how hard it is for me to feel good about my work when I'm managed down, as though a machine that just has to turn a crank until it's done. My mind just is not that fast & direct, not that quick to settle and resolve the complexities of system; I need some dwell times built in. I don't know what would happen to velocity, but quality would be much higher & I'd be so much better able to flow, to latch onto tasks I was much more primed for. Please, someone, give the Hammock Driven Devs a chance.
> But what makes sense to me is to have a couple things in flight, ideally staggered at slightly different phases of development, and to shift between them as the whims take me. Give myself time to decompress & reflect on one thing, by picking up another item that I've been pondering for a while.
This is exactly how it works best for me, as well. A few problems being tackled and solved in parallel, out-of-phase.
This is exactly how it works best for me, as well. A few problems being tackled and solved in parallel, out-of-phase.
isnt this more of a mythical man month issue
"adding manpower to a software project that is behind schedule delays it even longer"
we need more doctors and more cashiers
more doctors, and more cashiers will solve the queue issue at hospitals or at stores
problem is .. "mythical man month" .. adding more developers wont solve the problem
this article possibly misses the point, it doesnt suggest adding more devs whic is good i guess, it just suggest doing less work .. because you will do less anyways, so why do it while stressed, when you can do it while relaxed .. so you end up doing more or less the same, but with higher morale, all of this is good, but it doesnt solve the real problem .. "HOW TO DO MORE"
(you can of course decentralize your team, decouple your products, add more teams, etc.. but .. well)
"adding manpower to a software project that is behind schedule delays it even longer"
we need more doctors and more cashiers
more doctors, and more cashiers will solve the queue issue at hospitals or at stores
problem is .. "mythical man month" .. adding more developers wont solve the problem
this article possibly misses the point, it doesnt suggest adding more devs whic is good i guess, it just suggest doing less work .. because you will do less anyways, so why do it while stressed, when you can do it while relaxed .. so you end up doing more or less the same, but with higher morale, all of this is good, but it doesnt solve the real problem .. "HOW TO DO MORE"
(you can of course decentralize your team, decouple your products, add more teams, etc.. but .. well)
[deleted]
I think that for programmers, if you’re working on more than 2 features, you’re working on too much.
Cal Newport’s latest basically says: Take in fewer things. Work at a natural pace. Produce at the highest quality. I think that’s correct.
Cal Newport’s latest basically says: Take in fewer things. Work at a natural pace. Produce at the highest quality. I think that’s correct.
> if you’re working on more than 2 features
(Honest question because I've always worked in R&D...)
What counts as a feature when you're starting from scratch?
(Honest question because I've always worked in R&D...)
What counts as a feature when you're starting from scratch?
2 features here really mean 2 development tasks however a task is defined for your team. The idea is to have one to work on while the other is in the background (maybe being worked on by your subscience) and to take a new one once one is done, even if it isn't worked on immediately.
The main goal of work in progress limits to get work to done rather than starting new work (that doesn't get to done).
Ideally in Scrum your sprint commitment is a work in progress limit but in practice it isn't treated as such for reasons. Kanban can allow expedited issues to address an "emergency" issue but even that has a WIP of 1 so emergencies have to be prioritized.
The main goal of work in progress limits to get work to done rather than starting new work (that doesn't get to done).
Ideally in Scrum your sprint commitment is a work in progress limit but in practice it isn't treated as such for reasons. Kanban can allow expedited issues to address an "emergency" issue but even that has a WIP of 1 so emergencies have to be prioritized.
Anything that’s not a bugfix? That helps cover that infrastructural kind of work that’s not immediately visible to an end-user.
This sounds about right. I can switch tasks whenever I'm waiting for feedback on one, or I need to let a problem with one simmer unconsciously. Sometimes I'll pick up a quick chore if I don't have a block of time or energy to get into a meaty part of one. But sometimes you just gotta power through it regardless.
A good point is made.
If you're in a hole, the best way out is not to keep digging. It's hard to see that you have to accept a delay but a delay is exactly what you need when you're not making good progress. Slow down, finish shit, move on. Same with load. Sometimes just gotta do less at once.
- the worst code quality is when engineers who aren't already experts in a specific thing can't experiment. This is multiplied 10x for junior engineers.
- the most qa rejections happen when engineers need to work 10-12 hours straight to complete a feature and it will always be sub par even at the end. You pay shortly for problems because you didn't let anyone think deeply.
- at some point you need to be able to declare bankruptcy and abandon work because otherwise you'll sink.
If you're in a hole, the best way out is not to keep digging. It's hard to see that you have to accept a delay but a delay is exactly what you need when you're not making good progress. Slow down, finish shit, move on. Same with load. Sometimes just gotta do less at once.
- the worst code quality is when engineers who aren't already experts in a specific thing can't experiment. This is multiplied 10x for junior engineers.
- the most qa rejections happen when engineers need to work 10-12 hours straight to complete a feature and it will always be sub par even at the end. You pay shortly for problems because you didn't let anyone think deeply.
- at some point you need to be able to declare bankruptcy and abandon work because otherwise you'll sink.
Somewhat related. I'm annoyed when people complain about their workload.
Staffing is a management problem. If you don't have the budget to hire people, just do your best and let the work pile up. It's literally not your problem.
The worst thing you can do is to go "above and beyond", not only do you burn out but you're signaling to management that your workload is fine. Because all most people see is the bottom line -- is xyz task done or not.
Staffing is a management problem. If you don't have the budget to hire people, just do your best and let the work pile up. It's literally not your problem.
The worst thing you can do is to go "above and beyond", not only do you burn out but you're signaling to management that your workload is fine. Because all most people see is the bottom line -- is xyz task done or not.
And companies seem to rarely even recognize when someone is going above and beyond anymore
Forget actually rewarding it, they won't even acknowledge it, to them it's just what they expect
Forget actually rewarding it, they won't even acknowledge it, to them it's just what they expect
This is incredibly useful advice that essentially everyone who gets to make decisions in this space hates
This article makes sense to me as a developer and an occasional manager of developers and a former student of psychology and honestly if you meet and talk to people who do actual work in any capacity sometimes in your life and had any honest assessment of their day-over-day work over any appreciable period of this time you will have a hard time avoiding this conclusion
But businesspeople and especially high-level investors are rewarded for ignoring it. I've been in a few C-suite and board meetings and while you occasionally see the folks there talk about their underlings, they tend to mostly talk about abstract measures of outputs, with "velocity" being a popular term in tech orgs in particular. If they mention a worker by name, they tend to be high-ranking, perhaps a manager, but usually they are getting a lot done fast, or used to be and now aren't. Seldom is the latter kind of conversation had with remorse, sympathy, or the slightest hint that the prior state was a direct cause
Developers, especially experienced ones, often know what they need to get work done. They are often realistic about how much work to take on. They are incentivised to take on too much anyway, because the culture of business is fundamentally deeply broken
As far as I can tell, there has been no point since the invention of factories and metrics at which this has not been true, the rule rather than the exception among the entire classes of owners and high-level managers. And what's worse is that often competent ones of these can get some clout by delivering results by realizing this, but as more of them are added to the decision-making process, their ability to resist this tide, either socially or through direct loss of power, diminishes
This article makes sense to me as a developer and an occasional manager of developers and a former student of psychology and honestly if you meet and talk to people who do actual work in any capacity sometimes in your life and had any honest assessment of their day-over-day work over any appreciable period of this time you will have a hard time avoiding this conclusion
But businesspeople and especially high-level investors are rewarded for ignoring it. I've been in a few C-suite and board meetings and while you occasionally see the folks there talk about their underlings, they tend to mostly talk about abstract measures of outputs, with "velocity" being a popular term in tech orgs in particular. If they mention a worker by name, they tend to be high-ranking, perhaps a manager, but usually they are getting a lot done fast, or used to be and now aren't. Seldom is the latter kind of conversation had with remorse, sympathy, or the slightest hint that the prior state was a direct cause
Developers, especially experienced ones, often know what they need to get work done. They are often realistic about how much work to take on. They are incentivised to take on too much anyway, because the culture of business is fundamentally deeply broken
As far as I can tell, there has been no point since the invention of factories and metrics at which this has not been true, the rule rather than the exception among the entire classes of owners and high-level managers. And what's worse is that often competent ones of these can get some clout by delivering results by realizing this, but as more of them are added to the decision-making process, their ability to resist this tide, either socially or through direct loss of power, diminishes
The worst is when a big issue is taking too long, some higher up wants it broken out into smaller tasks so they can be closed independently/faster. Eventually the issue becomes a fractal of issues assigned to multiple people and progress comes to a halt.
Sometimes things take time, and can't be delegated.
Sometimes things take time, and can't be delegated.
I think the wisdom that headcount doesn't make a product faster has managed to reach some people, but somehow not the wisdom of don't burn out your people. Like no matter how much you talk about burnout, there is no adequate valve in play that enforces this as a true incentive. The very closest business people to having the worker perspective are "technical" startup founders (IE those founders doing the kind of work they may later measure their employees about), who take youth and energy into their passion project and by the time they burn out they have underlings, money, and power, or more often have simply failed out. In the former case they no longer need to be very productive in a labor-y sense that often and will remember a success story that was for them personally about unsustainable and generally unscalable hard work. In the latter case, they either have the support network to recover from their failure and maybe even try again. Those who fail to ever create a successful business are not taken seriously by businesses. Business people and investors who have not been technical founders are even less likely to "get" this on an experiential level, and may well get by on burning people out over and over, with each instance being excused as inevitable churn, conflict of personality, or generally speaking the fault of the employee. Since financiers care more about the short term and the appearance of "growth" rather than the long-term sustainability of the business, let alone the fates of the workers, burnout and slowing projects to a halt due to prioritizing being busy is an externality at best. As we can see basically all over the economy, the investor incentive barely can be said to align with that of the business, let alone its workers
> Sometimes things take time, and can't be delegated
This is something I keep saying to our team, but we have some members who want to keep breaking things into more and more tickets. Their argument is it allows more bits to be worked on in parallel but I point out that it means context must be rediscovered by multiple people. Sometimes it’s okay for one ticket to be a large-ish do-it ticket and we don’t need a design+breakdown for every aspect of a feature.
This is something I keep saying to our team, but we have some members who want to keep breaking things into more and more tickets. Their argument is it allows more bits to be worked on in parallel but I point out that it means context must be rediscovered by multiple people. Sometimes it’s okay for one ticket to be a large-ish do-it ticket and we don’t need a design+breakdown for every aspect of a feature.
Thing is that advice probably tends to come from a good place.
There’s actually a lot of evidence that smaller tasks lead to higher velocities
There’s actually a lot of evidence that smaller tasks lead to higher velocities
This is an astute observation. I have myself seen this at many employers now.
It almost seems like execs and board members cannot think beyond the factory mindset. And layers and layers of management have no desire or incentive to pushback. Leading to the best engineers getting tired of the grind.
The either burnout, or withhold their best, or stop caring, or just do enough to keep the ship running - all of which "appears" as a drop in "velocity". This leads to PIPs and firings from clueless manager that is only looking at Jira points to inform themselves.
At some point, the entire organization moves away from the engineering and people mindset to the KPI-factory mindset with poor decisions everywhere due to self-interest - leading the organization to become a worse form of IBM.
It really is astonishing to me to see it play over and over. It is clear that the upper echelons of execs and board members and upper management don't care enough about the company to sustain a good culture.
It almost seems like execs and board members cannot think beyond the factory mindset. And layers and layers of management have no desire or incentive to pushback. Leading to the best engineers getting tired of the grind.
The either burnout, or withhold their best, or stop caring, or just do enough to keep the ship running - all of which "appears" as a drop in "velocity". This leads to PIPs and firings from clueless manager that is only looking at Jira points to inform themselves.
At some point, the entire organization moves away from the engineering and people mindset to the KPI-factory mindset with poor decisions everywhere due to self-interest - leading the organization to become a worse form of IBM.
It really is astonishing to me to see it play over and over. It is clear that the upper echelons of execs and board members and upper management don't care enough about the company to sustain a good culture.
The core idea here is the subject of “The Goal” by Eli Goldratt. It’s a short novel and presents the case very clearly, although in terms for a factory not a software shop or a grocery store checkout line. It’s a great read, I recommend it.
Since it’s a business book, perhaps easier to sell to management than a blog post?
https://en.m.wikipedia.org/wiki/The_Goal_(novel)
Since it’s a business book, perhaps easier to sell to management than a blog post?
https://en.m.wikipedia.org/wiki/The_Goal_(novel)
If you want a more software focused take on it, there’s The Phoenix Project.
https://www.goodreads.com/book/show/17255186-the-phoenix-pro...
https://www.goodreads.com/book/show/17255186-the-phoenix-pro...
LOL “the company’s new initiative, the Phoenix Project, is critical to the future of Parts Unlimited, but is massively over budget and very late. Bill has 90 days to fix the mess or the entire department will be outsourced”
It’s such a boneheaded ultimatum that you can just tell that it actually happens all the time.
It’s such a boneheaded ultimatum that you can just tell that it actually happens all the time.
> Like the radio cookie tin the Germans were searching for, the problem is painfully obvious and immediately visible: we’re overextending ourselves with work.
At my organization, I think the reason is organizational structure and focus time. When I look at all the WIP tickets I have open, most of them would be easy to close, if only I could get unblocked on them.
Structurally, if you have a lot of managers with control over their little fiefdoms, and you need to get sign off from all of them to do something, that can take weeks: I have a couple tickets right now that can't be closed until I either find time for a meeting with 7 busy people, or schedule 7 individual meetings. In the middle of summer, with vacations and all, that's not easy.
Engineers at our organization, which is remote first, have done a great job of protecting their focus time. But one negative consequence of this is that they can't be interrupted even when they should be. If I need to ask the Lord of the Backend Engineers a question, I know he's not going to respond to me until the last half hour of his day, when he does all the stuff he considers beneath him, including communicating with other people. And it's probably going to be a terse, one-sentence response that requires another followup the next day.
I really don't think there's too much work for any reasonable company, I think the lack of throughput is due to communication issues, or in a larger sense a cultural issue related to how we expect to interact with each other. I'm not ready to say this is a remote work problem, because my last organization was 100% remote, and didn't have this issue at all.
At my organization, I think the reason is organizational structure and focus time. When I look at all the WIP tickets I have open, most of them would be easy to close, if only I could get unblocked on them.
Structurally, if you have a lot of managers with control over their little fiefdoms, and you need to get sign off from all of them to do something, that can take weeks: I have a couple tickets right now that can't be closed until I either find time for a meeting with 7 busy people, or schedule 7 individual meetings. In the middle of summer, with vacations and all, that's not easy.
Engineers at our organization, which is remote first, have done a great job of protecting their focus time. But one negative consequence of this is that they can't be interrupted even when they should be. If I need to ask the Lord of the Backend Engineers a question, I know he's not going to respond to me until the last half hour of his day, when he does all the stuff he considers beneath him, including communicating with other people. And it's probably going to be a terse, one-sentence response that requires another followup the next day.
I really don't think there's too much work for any reasonable company, I think the lack of throughput is due to communication issues, or in a larger sense a cultural issue related to how we expect to interact with each other. I'm not ready to say this is a remote work problem, because my last organization was 100% remote, and didn't have this issue at all.
I don't know if I'm bought in on their reasons why this is the case, but the observations seem true to me. The times I've moved the fastest are also the times when everyone is not fully busy.
This is true of large teams, small teams, and every type in between, in my experience.
This is true of large teams, small teams, and every type in between, in my experience.
I have led a team in a transition from an over-done scrum to minimal Kanban process and talked to many others who did the same, from small startups to AAA game companies, and they all loved it. I've never heard one dev say they thought it was more productive to have scrum. As far as I can see, Scrum makes middle managers, "scrum masters" and people who don't care how much work actually gets done happy. Kanban actually helps development go faster.
If anyone's interested, Microsoft press has a great light book on. The WIP limits are a key part.