Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Talking to your customers: a disruptive Agile framework

lucasfcosta.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Talking to your customers: a disruptive Agile framework

#51

Post by meheleventyone »

pydry wrote: post #39
kthejoker2 wrote: post #31

Earlier quoted context omitted.

The manifesto isn't vague. It's an opionated set of criteria preferences for evaluating ways of working (on software.) You can easily uncover in an job interview if they honor those preferences. * How is the customer involved in shaping the software? Give specific examples. * Who decides what will be developed? Where does my role fit in? * Will I be able to ship production code my first week? (Why not?) Et cetera. Ev…

I first realized the problem when somebody hit me with: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." and "Individuals and interactions over processes and tools" to argue that writing code comments, tests and documentation wasnt worth investing in when we can all just talk. This was after a series of disasters that code comments, test…

The following on bit from those statements is: “That is, while there is value in the items on the right, we value the items on the left more.”

So your colleagues view was a pretty extreme one compared to the moderation shown there. But like any philosophy you end up with fundamentalists taking things too far even in the face of reality being more complex. It’s terrifyingly dogmatic to argue from scripture rather than pragmatics.

Re: Talking to your customers: a disruptive Agile framework

#52

Post by JohnFen »

buscoquadnary wrote: post #11
allenleee wrote: post #8

I believe this approach will lead you to very incremental solutions. It lowers the cost of failure (downside), but also the potential impact of success (upside). This approach determines your mindset as a product designer and destroys your potential product/business upside upfront. Most users get pitched "understandable ideas" because builders think they have to prove market fit before building product depth. The mos…

That's the exact idea behind Agile. Sure it may limit some impact of success, but I bet you way more people are blowing millions of dollars trying to pull big products out of their hat. And for the record the number of "visionaries" is incredibly small, and pretty much everyone I've ever met that considered themselves a "visionary" is a con artist that talks a good game, has the technical acumen of day old mayonnaise…

The pioneers get all the arrows.

If your goal is to maximize profit and marketshare, you don't want to be the first to do a thing. You want to be the second or third. That's where the money is.

Being a pioneer, though, is far more enjoyable.

Re: Talking to your customers: a disruptive Agile framework

#53

Post by BasilPH »

"The Mom Test"[^0] is an excellent and short book about how to conduct those talks that I can highly recommend. It teaches you how to truly listen, and not bias the person you're interviewing.

Two points that stuck with me:

- Humans are bad at estimating, so make your questions very concrete. Don't ask "How often do you look up recipes on your iPad", but rather "How often did you use your iPad for recipes last week?".

- Nobody likes telling somebody else that their baby is ugly. Show the prototypes at the end of the interview, once you learned everything about the problem they had to tell you. If you show them your solution too early, you'll bias them.

[^0]: https://www.momtestbook.com

Re: Talking to your customers: a disruptive Agile framework

#54

Post by Jwarder »

satyrnein wrote: post #28
brutuz wrote: post #14

Talking is cheap and could be very misleading if your customer/user haven't put their skin into the game.

Learned this one the hard way. If you ask the equivalent of "what could I add to make this more useful?" you will get a lot of worthless suggestions like "I don't know, maybe make it sortable by the other column, too?" that don't move the needle at all on engagement.

As has been said before: Users are almost always right when they say a problem exists; but they are almost always wrong when they suggest a solution.

Re: Talking to your customers: a disruptive Agile framework

#55

Post by pydry »

meheleventyone wrote: post #51
pydry wrote: post #39

Earlier quoted context omitted.

I first realized the problem when somebody hit me with: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." and "Individuals and interactions over processes and tools" to argue that writing code comments, tests and documentation wasnt worth investing in when we can all just talk. This was after a series of disasters that code comments, test…

The following on bit from those statements is: “That is, while there is value in the items on the right, we value the items on the left more.” So your colleagues view was a pretty extreme one compared to the moderation shown there. But like any philosophy you end up with fundamentalists taking things too far even in the face of reality being more complex. It’s terrifyingly dogmatic to argue from scripture rather than…

I dont think it was dogmatism. I think they genuinely didnt think we had time to write tests, etc. and when I argued that we should do it to be more "agile" because we'd all committed to being agile up front (in theory) they googled what the principles and said "look, thats not what agile says".

I agree that arguing from scripture is awful. I havent tried to do it since. I would like to see some other sort of anti-waterfall set of principles that I could get behind though.

Re: Talking to your customers: a disruptive Agile framework

#56

Post by horsawlarway »

ownagefool wrote: post #21
teucris wrote: post #13

I’ve been whining about the constant agile-bashing for a while…I understand that implementing agile often leads to the MSDM model (many small death marches) but I never quite got the loathing agile gets from the tech community. I think this gives me a glimpse. To me, agile is about adjusting your planning so you can get customer feedback and adjust your project accordingly. Without that, much of what I value from agi…

agile is fine. The problem is the brand has been captured by consultants selling something that doesn't jive with the original ethos. You were supposed to talk to the customers. Now you have dedicated POs that determine what the team will work on, but they're also too junior to talk to the customers. It's okay though, you have dedicated PMs that'll talk to the customers, right? Only they're typically to busy pushing…

This roughly matches my experience.

In general - I consider "agile/scrum master training" on a resume as a pretty serious black mark, for basically the same reason: The training is all from consultants who preach bs to sell courses and products to management - very rarely does the training encourage simple acts like "talk to your customers" or "let your devs shadow a user" or even "treat your team like people". It's all process over people - the opposite of the intent.

Re: Talking to your customers: a disruptive Agile framework

#58

Post by Cederfjard »

Arcanum-XIII wrote: post #20
teucris wrote: post #13

I’ve been whining about the constant agile-bashing for a while…I understand that implementing agile often leads to the MSDM model (many small death marches) but I never quite got the loathing agile gets from the tech community. I think this gives me a glimpse. To me, agile is about adjusting your planning so you can get customer feedback and adjust your project accordingly. Without that, much of what I value from agi…

The main problems I’ve seen are: - followed as a religion, especially when it doesn’t make sense (daily stand up for a team working in the same room and collaborating all day long? One day lost every 2 week for planning and review? Trying to do a stand up with too many people?) - using it as an excuse to not prepare the project and without clear objective - trying to fit agile in a fixed schedule (like trying to sync…

You can follow agile methodologies while working on a fixed schedule, but if the timeframe isn’t flexible, then the scope needs to be. Fill up the backlog, prioritize it by importance, and what’s done by the deadline is what’ll be delivered. If you get work done reliably and at a consistent pace while tracking velocity or throughput, you can use that data to get an idea of what you’ll manage to deliver.

Re: Talking to your customers: a disruptive Agile framework

#59

Post by bluefirebrand »

pc86 wrote: post #47
rfrey wrote: post #44

Earlier quoted context omitted.

"I'm calling you unsolicited from Microsoft"... bold, I'd immediately assume a scam, say no thank you, and hang up.

I'm sure they get a lot of hang ups, but there is a clear difference between someone who can barely speak English calling you from a call center "to discuss the account" or whatever, and a native speaker calling from (presumably) their home or a quiet office, using your name, and who already knows what products within Azure you're using. It's pretty obvious from the get go it's not a scam.

Even if it wasn't someone from Azure, it's unclear what scam "Do you have a few minutes to answer some questions about how you use our product so we can better understand your use cases" could possibly be.
Post reply on HN