6 ms·

At the company I work at, we're definitely not autonomous. If as a team we have a goal, as a dev, I don't know what it is. We have roadmapped (read: itineraried

At the company I work at, we're definitely not autonomous. If as a team we have a goal, as a dev, I don't know what it is. We have roadmapped (read: itineraried) work items, basically handed to our team to produce. Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery. So what does it look like? Well, as devs, we have specific feature requirements handed to us with little-to-no prior input, we're always behind schedule so we're never afforded the time and space to do things right, it's always "we'll fix it later". We occassionally have some kind of "our competitor is doing this, we have to do this" piece of work that comes in and shifts all of our roadmap items later of course. No one ever stops to ask whether we're having the impact we anticipated, or whether it's even worth keeping the work. Combine this with a replatforming-through-new-work effort on the go, you've got a slow mutation from the old platform into an even uglier new platform that doesn't get the right effort applied to it. But hey, we're "agile", we have mission teams, we have two-pizza teams, we're goal oriented. I mean, we say these things, but in reality it's planned out work, with deadlines, delivered by multiple generic teams named after areas of the customer journey that end up being the center of philosophical debate about whether this bit of work lives with _this team_ or _that team_. Although I don't think the team size or the number of them is necessarily the problem, the article rings true in my experiences - but it's down to culture of the organisation, more than the topology.

cygned 6y ago
> Well, as devs, we have specific feature requirements > Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery. That’s “classical” fixing of all dimensions of the “magic triangle” (scope, budget, time), not agile by any stretch, rather a practice from waterfall management. I argue that there’s a fourth dimension; quality. How do you see the quality of the teams’ work?
- waheoo 6y ago
  I actually prefer a systems lifetime as the 4th dimension. Quality is just a function of the system time to live being fit against the other three constraints. Scope, budget and time. (I'd actually say time is a subset of budget.)
  - WrtCdEvrydy 6y ago
    To be honest, most "deadlines" are really just cost boundaries in the first place. If you're not publicly traded and made an announcement about something going live on a certain date, or have a regulatory body that requires something by a certain date, your deadline is just a cost-cutting measure.
  - ric2b 6y ago
    Quality is part of scope. Is it in scope for this to be maintainable? To be stable? To have a nice UX?
    - waheoo 6y ago
      I guess time to live is scope too but I think it's far too often ignored. Scope generally determines feature coverage, not quality or how long we expect to use the system.
- pjmorris 6y ago
  Johanna Rothman, in 'Manage It', suggests these dimensions to what we usually think of as the 'triangle': features, quality, schedule, cost, team size, team members, and resources (infra, sw, etc...)
matsemann 6y ago
> No one ever stops to ask whether we're having the impact we anticipated "Signs you’re working in a feature factory" sounds relevant to you. https://news.ycombinator.com/item?id=22335738 https://news.ycombinator.com/item?id=22335738
- delusional 6y ago
  I think he knows he's working in a feature factory. What's hard is knowing what you can do to change it. Where I work, we happen to have a pretty relaxed management. While they always have a ton of deadlines and always push for more work, they largely don't care about the outcome, so you can just ignore it. Every once in a while something will be actually important, but mostly it's just dumb roadmaps for features that don't add value. What my team has found helpful is to just ignore those fake tasks, and just create the features we actually believe will be valuable. Hopefully we can leverage our outcomes (and the collected data) to convince management that our way is better. Some day.
mercer 6y ago
Both your comment and the article sound a bit like the inverse of the problem addressed by "Domain Driven Design". In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company. But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains. I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?
jtdev 6y ago
No, this is not “agile”. This is what agile critics think agile is...
JamesBarney 6y ago
This is why I hate Agile. It's much harder to convince management that they won't be getting a pre-determined set of functionality by a certain date (we will have feature x,y and z developed by October 13th) than to convince a team to stop doing upfront planning and design. So almost every project I've been on that was "Agile" was actually waterfall sans upfront planning and design.
- devtul 6y ago
  My understanding about Agile is planning ahead for the next step instead of planning the whole project before starting and then hoping all your assumptions turns out true. The product owner will create and prioritize the stories in the backlog(plan), the team will discuss and break down a story into actionable and weighted tasks(more planning), then they will fit those tasks into the sprint based on their previous performance(even more planning!)
  - undro 6y ago
    I think the business concept missing from Agile is investment/ROI and risk. Until budgeting processes are also Agile, everyone will be operating on the idea that "we paid $x to get 'y', and now you aren't giving us 'y'. What the hell?" Agile works (when it works) because it treats software as a complex system that is best studied and modified through experimentation after accepting a high initial degree of uncertainty (which is slowly reduced through the creation of knowledge). The only comparable things in business terminology are investment and risk. Each iteration (I hate "sprint") needs to be treated as an investment with some risk percentage of failing completely. Until the money is handled that way, business people will keep expecting to get exactly what they think they're paying for, exactly when they feel they were promised they'd get it.
    - jkarneges 6y ago
      > I hate "sprint" Me too. It sounds exhausting.
      - 6y ago
coredog64 6y ago
I think we work at the same company.
kmclean 6y ago
Wow we must have worked at the same place. I could have written this description. I wonder how common it is.

cygned 6y ago

> Well, as devs, we have specific feature requirements > Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery. That’s “classical” fixing of all dimensions of the “magic triangle” (scope, budget, time), not agile by any stretch, rather a practice from waterfall management. I argue that there’s a fourth dimension; quality. How do you see the quality of the teams’ work?

waheoo 6y ago
I actually prefer a systems lifetime as the 4th dimension. Quality is just a function of the system time to live being fit against the other three constraints. Scope, budget and time. (I'd actually say time is a subset of budget.)
- WrtCdEvrydy 6y ago
  To be honest, most "deadlines" are really just cost boundaries in the first place. If you're not publicly traded and made an announcement about something going live on a certain date, or have a regulatory body that requires something by a certain date, your deadline is just a cost-cutting measure.
- ric2b 6y ago
  Quality is part of scope. Is it in scope for this to be maintainable? To be stable? To have a nice UX?
  - waheoo 6y ago
    I guess time to live is scope too but I think it's far too often ignored. Scope generally determines feature coverage, not quality or how long we expect to use the system.
pjmorris 6y ago
Johanna Rothman, in 'Manage It', suggests these dimensions to what we usually think of as the 'triangle': features, quality, schedule, cost, team size, team members, and resources (infra, sw, etc...)

matsemann 6y ago

> No one ever stops to ask whether we're having the impact we anticipated "Signs you’re working in a feature factory" sounds relevant to you. https://news.ycombinator.com/item?id=22335738 https://news.ycombinator.com/item?id=22335738

delusional 6y ago
I think he knows he's working in a feature factory. What's hard is knowing what you can do to change it. Where I work, we happen to have a pretty relaxed management. While they always have a ton of deadlines and always push for more work, they largely don't care about the outcome, so you can just ignore it. Every once in a while something will be actually important, but mostly it's just dumb roadmaps for features that don't add value. What my team has found helpful is to just ignore those fake tasks, and just create the features we actually believe will be valuable. Hopefully we can leverage our outcomes (and the collected data) to convince management that our way is better. Some day.

mercer 6y ago

Both your comment and the article sound a bit like the inverse of the problem addressed by "Domain Driven Design". In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company. But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains. I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?

jtdev 6y ago

No, this is not “agile”. This is what agile critics think agile is...

JamesBarney 6y ago

This is why I hate Agile. It's much harder to convince management that they won't be getting a pre-determined set of functionality by a certain date (we will have feature x,y and z developed by October 13th) than to convince a team to stop doing upfront planning and design. So almost every project I've been on that was "Agile" was actually waterfall sans upfront planning and design.

devtul 6y ago
My understanding about Agile is planning ahead for the next step instead of planning the whole project before starting and then hoping all your assumptions turns out true. The product owner will create and prioritize the stories in the backlog(plan), the team will discuss and break down a story into actionable and weighted tasks(more planning), then they will fit those tasks into the sprint based on their previous performance(even more planning!)
- undro 6y ago
  I think the business concept missing from Agile is investment/ROI and risk. Until budgeting processes are also Agile, everyone will be operating on the idea that "we paid $x to get 'y', and now you aren't giving us 'y'. What the hell?" Agile works (when it works) because it treats software as a complex system that is best studied and modified through experimentation after accepting a high initial degree of uncertainty (which is slowly reduced through the creation of knowledge). The only comparable things in business terminology are investment and risk. Each iteration (I hate "sprint") needs to be treated as an investment with some risk percentage of failing completely. Until the money is handled that way, business people will keep expecting to get exactly what they think they're paying for, exactly when they feel they were promised they'd get it.
  - jkarneges 6y ago
    > I hate "sprint" Me too. It sounds exhausting.
    - 6y ago

coredog64 6y ago

I think we work at the same company.

kmclean 6y ago

Wow we must have worked at the same place. I could have written this description. I wonder how common it is.