5 ms·

This type of cargo culting for sure exists, but I haven’t encountered this behavior in my career. Even all the ”agile” people I know are focused on delivering v

This type of cargo culting for sure exists, but I haven’t encountered this behavior in my career. Even all the ”agile” people I know are focused on delivering value to the end customer and the business. Meaning, they’re really interested in building software and features that people actually use.

a_c 3y ago
As someone building something to tackle this problem, I'm under the impression that your situation is rare. Google famously kills product loved by customer. Reddit is committing suicide. facebook (almost) never built anything useful. I would love to learn from you how your team build software that matters if you don't mind.
- danjac 3y ago
  Agile is a process (or a school of processes) for planning and building software to meet business goals. We can debate whether or not it's good at that, but ultimately if the business goals are misguided, or user-hostile, or both, agile isn't really to blame here.
  - lisasays 3y ago
    However if agile is used as a foil -- to project an aura of managerial competence, and keep everyone distracted while no one talks about the real problems that need to be solved -- then it also deserves blame.
- cheeseface 3y ago
  I think those big companies are poor examples, as big companies have always more problems with aligning people around customer needs/business priorities. There's a lot more of corporate politics that takes time and a lot more money to waste (when the core business itself is highly profitable). If you look at the smaller companies (e.g. Linear.app) it is immensely hard to argument that they would not be building "useful software." In our case, we stay close to the customer. Some ways we achieve this: - We have a shared Slack channels with at least 20 customers. All engineers are on these channels and see the communications that is going on. - All engineers work with customer support 1 week every X weeks. All engineers are on the support channel too and see the topics of the tickets / customer requests. - We gather customer feedback for feature requests and all new features are based on business priorities informed by this feedback. - PMs and Designers regularly talk with customers when doing product research. When we have an idea of what we might want to build, 1-2 engineers join them in shaping an Epic (size: 1-2 months) or a Story (size: ~2 weeks). One of these engineers will lead the Epic/Story, which means that they amass a lot of context of the both problems of the customers and the technical details of the solution. Usually they are able to do much of the scoping/product decisions quite quickly after the Epic/Story has started. - Engineers watch a sales / customer success call every two weeks and then join to discuss the contents of the call together.

a_c 3y ago

As someone building something to tackle this problem, I'm under the impression that your situation is rare. Google famously kills product loved by customer. Reddit is committing suicide. facebook (almost) never built anything useful. I would love to learn from you how your team build software that matters if you don't mind.

danjac 3y ago
Agile is a process (or a school of processes) for planning and building software to meet business goals. We can debate whether or not it's good at that, but ultimately if the business goals are misguided, or user-hostile, or both, agile isn't really to blame here.
- lisasays 3y ago
  However if agile is used as a foil -- to project an aura of managerial competence, and keep everyone distracted while no one talks about the real problems that need to be solved -- then it also deserves blame.
cheeseface 3y ago
I think those big companies are poor examples, as big companies have always more problems with aligning people around customer needs/business priorities. There's a lot more of corporate politics that takes time and a lot more money to waste (when the core business itself is highly profitable). If you look at the smaller companies (e.g. Linear.app) it is immensely hard to argument that they would not be building "useful software." In our case, we stay close to the customer. Some ways we achieve this: - We have a shared Slack channels with at least 20 customers. All engineers are on these channels and see the communications that is going on. - All engineers work with customer support 1 week every X weeks. All engineers are on the support channel too and see the topics of the tickets / customer requests. - We gather customer feedback for feature requests and all new features are based on business priorities informed by this feedback. - PMs and Designers regularly talk with customers when doing product research. When we have an idea of what we might want to build, 1-2 engineers join them in shaping an Epic (size: 1-2 months) or a Story (size: ~2 weeks). One of these engineers will lead the Epic/Story, which means that they amass a lot of context of the both problems of the customers and the technical details of the solution. Usually they are able to do much of the scoping/product decisions quite quickly after the Epic/Story has started. - Engineers watch a sales / customer success call every two weeks and then join to discuss the contents of the call together.