6 ms·

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

pjmlp 5y ago
That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery. Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios. EDIT: several typos
- Clewza313 5y ago
  This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this. Of course, this isn't applicable/possible for all types of software (you can't really iterate your way to an MVP nuclear reactor) but there's less of this than you'd think.
  - nicoburns 5y ago
    One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"
    - pjmlp 5y ago
      Because that isn't something their management levels will even consider a possibility, given security concerns, politics, and whatever might come up if the project goes south and a lawsuit is bound to happen. These agile ideas only work in an ideal world of "we are all friends here".
      - nicoburns 5y ago
        I'm sure this is true of some companies, but I've definitely seen this done well in a few places. Often software agencies.
    - 2sk21 5y ago
      This is a good point. However in practice we wind up with a number of gatekeepers between the developer and the actual users. These gatekeepers are both on the customer side and the developer side. For example on the developer side, sales people typically do not like being disintermediated since it reduces their relevance. On the customer side, managers often do not want outside developers bothering their workers.
      - pydry 5y ago
        As a developer I've had plenty of pointless and unpleasant customer interactions thrust upon me. It's not a good thing. I have always appreciated product managers who effectively intermediated customers, had deep domain knowledge, managed stakeholder expectations, learned how to interpret what they said (and ignore what isnt relevant), asked the right questions, prioritize effectively and output to me a nice set of, de-noised, ordered, precise answers to the question "what do I do next?" It's a rare skill. It boosts my productivity immensely when done right. It removes cognitive load from the developer. Even when POs make mistakes and misinterpret requirements I still appreciate that being somebody else's problem. It quells my anxiety immensely and lets me focus on developing the thing right without having to worry about whether Im developing the right thing.
  - walshemj 5y ago
    Co located teams is what you really need (sorry WFH fans)
    - pjmlp 5y ago
      Try to sell that to corporations with distributed teams, on the RFP answer. The majority will rather pick other vendor that doesn't propose such change into their internal processes. Unless they are asking for consultation on how to change work processes, that is.
      - walshemj 5y ago
        That would not be Agile then - Agile trades off almost every thing for speed.
        pjmlp 5y ago
        Hence why it is in its current adoption state.
    - detaro 5y ago
      The best "agile" experience I've had was with a team spread across the continent. Good communication & process != co-located. (And if your customer is external, it even puts them on a more equal footing)
      - walshemj 5y ago
        Ok it might be "good" but its not the best "communication & process " you get with collocated teams. The skunkworks teams the developed the Apple MAC is one very good example.
- heisenbit 5y ago
  Agile willfully closing eyes to skill mismatch is a wider problem. Complex projects have a need for specialization and I cringe every time when new teams or scrum ‚masters‘ ignore that.
  - pjmlp 5y ago
    Yep, just pick whatever ticket you feel like working on, for example.
tarsinge 5y ago
We kind of successfully to that in my shop, the early stage product usually being graphic mock-ups (wireframes may not be enough when the client really lacks product vision) to iterate fast.
AndrewKemendo 5y ago
And in the process you have burned out the client who hired you so that they didn't have to make decisions. "I thought this was your job" is something I've heard a few times from clients when we have sent over wire frames or beta applications.

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

pjmlp 5y ago

That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery. Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios. EDIT: several typos

Clewza313 5y ago
This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this. Of course, this isn't applicable/possible for all types of software (you can't really iterate your way to an MVP nuclear reactor) but there's less of this than you'd think.
- nicoburns 5y ago
  One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"
  - pjmlp 5y ago
    Because that isn't something their management levels will even consider a possibility, given security concerns, politics, and whatever might come up if the project goes south and a lawsuit is bound to happen. These agile ideas only work in an ideal world of "we are all friends here".
    - nicoburns 5y ago
      I'm sure this is true of some companies, but I've definitely seen this done well in a few places. Often software agencies.
  - 2sk21 5y ago
    This is a good point. However in practice we wind up with a number of gatekeepers between the developer and the actual users. These gatekeepers are both on the customer side and the developer side. For example on the developer side, sales people typically do not like being disintermediated since it reduces their relevance. On the customer side, managers often do not want outside developers bothering their workers.
    - pydry 5y ago
      As a developer I've had plenty of pointless and unpleasant customer interactions thrust upon me. It's not a good thing. I have always appreciated product managers who effectively intermediated customers, had deep domain knowledge, managed stakeholder expectations, learned how to interpret what they said (and ignore what isnt relevant), asked the right questions, prioritize effectively and output to me a nice set of, de-noised, ordered, precise answers to the question "what do I do next?" It's a rare skill. It boosts my productivity immensely when done right. It removes cognitive load from the developer. Even when POs make mistakes and misinterpret requirements I still appreciate that being somebody else's problem. It quells my anxiety immensely and lets me focus on developing the thing right without having to worry about whether Im developing the right thing.
- walshemj 5y ago
  Co located teams is what you really need (sorry WFH fans)
  - pjmlp 5y ago
    Try to sell that to corporations with distributed teams, on the RFP answer. The majority will rather pick other vendor that doesn't propose such change into their internal processes. Unless they are asking for consultation on how to change work processes, that is.
    - walshemj 5y ago
      That would not be Agile then - Agile trades off almost every thing for speed.
      - pjmlp 5y ago
        Hence why it is in its current adoption state.
  - detaro 5y ago
    The best "agile" experience I've had was with a team spread across the continent. Good communication & process != co-located. (And if your customer is external, it even puts them on a more equal footing)
    - walshemj 5y ago
      Ok it might be "good" but its not the best "communication & process " you get with collocated teams. The skunkworks teams the developed the Apple MAC is one very good example.
heisenbit 5y ago
Agile willfully closing eyes to skill mismatch is a wider problem. Complex projects have a need for specialization and I cringe every time when new teams or scrum ‚masters‘ ignore that.
- pjmlp 5y ago
  Yep, just pick whatever ticket you feel like working on, for example.

tarsinge 5y ago

We kind of successfully to that in my shop, the early stage product usually being graphic mock-ups (wireframes may not be enough when the client really lacks product vision) to iterate fast.

AndrewKemendo 5y ago

And in the process you have burned out the client who hired you so that they didn't have to make decisions. "I thought this was your job" is something I've heard a few times from clients when we have sent over wire frames or beta applications.