Unfortunately, "Dark Agile" has taken over much of the industry -- by perverting "Tasks" within a "User Story" to be the old pre-agile phases of [Gather Requirements, Architecture, Design, Detailed Design, Coding, Code Review, QA Testing, Customer Demo, Customer Acceptance, Deploy] sequence of steps done by different people with "Throw it over the wall!" process, documentation, and meetings between them. This approach encourages and nearly requires micro-management by "bosses," even if they'd prefer a more empowering management style. It forces dysfunction on everyone in the team.
This is one of the main things that the agile community banded together to fight. And now it's being done *more severely than before*, and also under the *false* banner of "agile." [It's "Dark Agile."]
This is such a big topic, and all you do is give a little teaser. I like it, it makes me think.
Some of it relates to what the business values, what the engineer values, and what incentives are in place. One example where the sign-up system doesn't work well (at Facebook at least) is for maintaining system. This is a big pity as it means some useful systems just degrade slowly over time, but it's not really a flaw in the sign-up system per se as many engineers would love to continue to care for a thing they built.
However, incentivising "impact" means such work is much less valued than building a new thing - so here, the problem (imo) is that the incentive system is not aligned with what the business actually wants in the long term.
Much more can be said about this topic, it's a great way into many interesting topics :)
It's only intended to be a teaser. There's a whole "perfect task assignment is impossible, even given one criterion to optimize for" discussion. Then the whole "long- vs short-term". Then we add the feedback loops.
Incentivizing impact is fine. Defining "impact" to mean "adding upside" in an organization that has accreted downside is a management failure.
A question occurs to me. Why one or the other? Why not assign the person who is best at the particular task and and ask for a volunteer who wants to learn? Would that not accomplish both goals?The task get's done well and you get the knowledge transfer.
"Why not assign the person who is best?" 1. Me as the manager doesn't *know* who is "best". 2. What does "best" even mean? What criteria? Finished fastest? Learns most? Builds so it's easiest to build upon? Cheapest now? Long-term? 3. I already said why, because assignment bleaches responsibility, motivation. If this doesn't bother you, go ahead, but I think you're wasting resources.
Is "best" something the team can/should decide? What information do they need to decide what "best" is. Best for now? Best for later? Best is going to change based on the circumstances, as you say. Is the manager's job to provide the team with the information (if they don't already have it) to make the call themselves, and the 'air cover' to get on with it?
I was thinking along similar lines - the manager facilitates a discussion among the team about who does the work. The problem always being that the second the manager drops out of facilitation mode, anything they say (due to role power) could effectively amount to assignment.
It's not a bad idea but I think I would frame it as "This thing needs to be done. Who would like to work on it? You can pair or swarm on it."
By framing it as an invitation it you can leave it open to Senior Jane taking the lead and Junior Joe observing and with Joe taking the lead and Jane mentoring them through the process. The work still gets done (hopefully), knowledge is still gained (hopefully) and freedom to allow engineers to define their process is preserved (hopefully).
“Assignment bleaches responsibility” summarizes it nicely.
Would also love to hear your thought on two variations I’ve seen: “coerced sign-up” and “refuse-able assignment”. The former meaning when people/teams are encouraged to select particular work, and the latter meaning when they are allowed to refuse assigned work.
We are talking about the power dynamics in the workplace. Do ICs have power or not? If so, why assign? They know better how to divide the work. “Refuseable” sounds like window dressing to protect the old power dynamic.
“Do ICs have power of not?” IME it’s not as cut and dry as this. For example, the experience-level of the IC can be a factor.
One with more experience can “refuse” assignment more easily/confidently both because they are able to articulate why it’s the wrong assignment, and also because they carry more weight being the more experienced/senior practitioner.
As a manager, you can also choose the least prepared person for the job if it isn't super critical. There are also incentives for doing that if you are concerned about the long term health of your team
As a manager, I sometimes will ask the team to ensure that at least two people are working on a task of high importance to ensure that new knowledge spreads faster.
Sometimes it is difficult to find someone to work on some of the less interesting tasks. Planning a “mob programming” session works to get those started.
Not a fan of task assignment within a team (assigning tasks to teams is another matter in my opinion)
Unfortunately, "Dark Agile" has taken over much of the industry -- by perverting "Tasks" within a "User Story" to be the old pre-agile phases of [Gather Requirements, Architecture, Design, Detailed Design, Coding, Code Review, QA Testing, Customer Demo, Customer Acceptance, Deploy] sequence of steps done by different people with "Throw it over the wall!" process, documentation, and meetings between them. This approach encourages and nearly requires micro-management by "bosses," even if they'd prefer a more empowering management style. It forces dysfunction on everyone in the team.
This is one of the main things that the agile community banded together to fight. And now it's being done *more severely than before*, and also under the *false* banner of "agile." [It's "Dark Agile."]
There is this „Take the first task” strategy too.
We prioritize the tasks/stories and whoever is free takes the first from the top of the backlog.
This way it’s not directly assigned. But it’s also not really sign up.
https://blog.arkency.com/2013/10/take-the-first-task/
This is such a big topic, and all you do is give a little teaser. I like it, it makes me think.
Some of it relates to what the business values, what the engineer values, and what incentives are in place. One example where the sign-up system doesn't work well (at Facebook at least) is for maintaining system. This is a big pity as it means some useful systems just degrade slowly over time, but it's not really a flaw in the sign-up system per se as many engineers would love to continue to care for a thing they built.
However, incentivising "impact" means such work is much less valued than building a new thing - so here, the problem (imo) is that the incentive system is not aligned with what the business actually wants in the long term.
Much more can be said about this topic, it's a great way into many interesting topics :)
It's only intended to be a teaser. There's a whole "perfect task assignment is impossible, even given one criterion to optimize for" discussion. Then the whole "long- vs short-term". Then we add the feedback loops.
Incentivizing impact is fine. Defining "impact" to mean "adding upside" in an organization that has accreted downside is a management failure.
A question occurs to me. Why one or the other? Why not assign the person who is best at the particular task and and ask for a volunteer who wants to learn? Would that not accomplish both goals?The task get's done well and you get the knowledge transfer.
"Why not assign the person who is best?" 1. Me as the manager doesn't *know* who is "best". 2. What does "best" even mean? What criteria? Finished fastest? Learns most? Builds so it's easiest to build upon? Cheapest now? Long-term? 3. I already said why, because assignment bleaches responsibility, motivation. If this doesn't bother you, go ahead, but I think you're wasting resources.
Is "best" something the team can/should decide? What information do they need to decide what "best" is. Best for now? Best for later? Best is going to change based on the circumstances, as you say. Is the manager's job to provide the team with the information (if they don't already have it) to make the call themselves, and the 'air cover' to get on with it?
good point.
I was thinking along similar lines - the manager facilitates a discussion among the team about who does the work. The problem always being that the second the manager drops out of facilitation mode, anything they say (due to role power) could effectively amount to assignment.
It's not a bad idea but I think I would frame it as "This thing needs to be done. Who would like to work on it? You can pair or swarm on it."
By framing it as an invitation it you can leave it open to Senior Jane taking the lead and Junior Joe observing and with Joe taking the lead and Jane mentoring them through the process. The work still gets done (hopefully), knowledge is still gained (hopefully) and freedom to allow engineers to define their process is preserved (hopefully).
I sometimes stumble upon another manager incentive to assignment.
In this case, the manager and the team are aware the risk of assigning to the "best":
- experts tend to burnout or leave
- planning challenges: topic A expert's planning is filled with low priority stuff while topic B expert is up their neck with work
- bus factor, mainly since the pandemic
The challenge is when the most benevolent person is always taking the work that nobody wants.
How do we build that solidarity and empathy to make people sign-up for work just for the well-being of that benevolent person?
Of course, I'd also address, what is that work that nobody wants to do 😅
Hahaha! I was about to write a comment about how it is all about incentives then I saw the subtitle "An Incentives Perspective".
A common problem is career perspective and promotions:
- Management-axis: You're the best at building bridges! We'll name you manager.
- Expertise-axis: You're the best at building bridges! You are going to build them all! Could you write a book about that what you're at it?
- Coaching-axis: You've been really good at showing others how to build the best bridges! We'll promote you as a coach.
There are around 10 different job titles on the management-axis in most companies but no job title on the coaching-axis.
“Assignment bleaches responsibility” summarizes it nicely.
Would also love to hear your thought on two variations I’ve seen: “coerced sign-up” and “refuse-able assignment”. The former meaning when people/teams are encouraged to select particular work, and the latter meaning when they are allowed to refuse assigned work.
We are talking about the power dynamics in the workplace. Do ICs have power or not? If so, why assign? They know better how to divide the work. “Refuseable” sounds like window dressing to protect the old power dynamic.
“Do ICs have power of not?” IME it’s not as cut and dry as this. For example, the experience-level of the IC can be a factor.
One with more experience can “refuse” assignment more easily/confidently both because they are able to articulate why it’s the wrong assignment, and also because they carry more weight being the more experienced/senior practitioner.
As a manager, you can also choose the least prepared person for the job if it isn't super critical. There are also incentives for doing that if you are concerned about the long term health of your team
As a manager, I sometimes will ask the team to ensure that at least two people are working on a task of high importance to ensure that new knowledge spreads faster.
Sometimes it is difficult to find someone to work on some of the less interesting tasks. Planning a “mob programming” session works to get those started.
Not a fan of task assignment within a team (assigning tasks to teams is another matter in my opinion)
While I do have my personal preference, I wonder if the same incentive tradeoff persists when you go one or more abstraction levels higher.
Is a team more committed when they choose their own overarching goals or projects?
Isn’t it actually supposed to be the balance that’s maintained between top down and bottom up management?