Talking to your customers: a disruptive Agile framework • Hacker News Board

Re: Talking to your customers: a disruptive Agile framework

#31

Post by kthejoker2 » Thu, Aug 18, 2022, 9:25 AM UTC

pydry wrote: post #29

agos wrote: post #27

Earlier quoted context omitted.

I don't want to say "no true scotsman", but agile has no requirements on stand ups, schedules, or estimates.

Agile has always been extremely vague about what it is. This is at the heart of the problem. This allows everyone to project their own desires on to it - from CEO to PM to programmer to consultant. I get why this happened - the original consultants probably felt that defining it in a way that would alienate people (especially leaders with the budget to hire them) wouldnt be good business. Nonetheless it led to all th…

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.

Even better: come up with your own manifesto of preferences for ways of working.

And then score potential employers and your teams against them.

Re: Talking to your customers: a disruptive Agile framework

#32

Post by RandomLensman » Thu, Aug 18, 2022, 9:31 AM UTC

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…

To be fair, a lot of software development is for inhouse, sometimes specialized, things. The tech side being the visionary there is potentially quite difficult without specialized knowledge (e.g., via some hybrid roles as seen in some industries).

Re: Talking to your customers: a disruptive Agile framework

#33

Post by jrib » Thu, Aug 18, 2022, 9:32 AM UTC

withinboredom wrote: post #23

I have brought up talking, like picking up the phone and saying hi, at every workplace I have ever been. The response has always been hilarious, after they also think it is “such a great idea.” - we have sales for that - we should see if we can get a special team for this - let’s just email everyone a survey From my personal Azure account, Microsoft has called me a handful of times, with a product manager and enginee…

I've had Atlassian's bitbucket team reach out to me after I expressed frustration in a survey.

It was a manager and a developer on the call. They listened intently. I think the call lasted at least 30 minutes.

I think bitbucket improved a lot over the last few years. I like to think that practice of talking with users was a significant part of that.

Re: Talking to your customers: a disruptive Agile framework

#34

Post by n0w » Thu, Aug 18, 2022, 9:38 AM UTC

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…

> Remember: it’s your job to come up with the solution, not the customer’s. When you go back to ask them questions, ensure you’re not simply asking them to design the solution for you. If they could do that, they’d probably have done it already. If they could have done it but didn’t, it’s because the problem doesn’t matter much.

You talk to customers to better understand the problems they face and how valuable a solution might be.

Not for ideas or suggestions.

Once you've built a thing, you talk to customers to understand _how well_ your thing solves their problem.

None of this necessitates incremental solutions.

Re: Talking to your customers: a disruptive Agile framework

#35

Post by whoevercares » Thu, Aug 18, 2022, 10:02 AM UTC

This is a quite ok framework for greenfield project in Big Tech IMO, where we have this exact problem - debating the strategy from Q1-Q3 and starting coding in Sept and deliver craps

Re: Talking to your customers: a disruptive Agile framework

#36

Post by Lutger » Thu, Aug 18, 2022, 10:28 AM UTC

n0w wrote: post #34

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…

> Remember: it’s your job to come up with the solution, not the customer’s. When you go back to ask them questions, ensure you’re not simply asking them to design the solution for you. If they could do that, they’d probably have done it already. If they could have done it but didn’t, it’s because the problem doesn’t matter much. You talk to customers to better understand the problems they face and how valuable a solu…

Exactly. This is the most important part people just don't get. Customers are really, really bad at solving their own problems. In my domain, they all come up with a crude and barely functioning variant of excel in a web browser.

Listening to a customer is not some manual variant of a mechanical A/B test. You really need to immerse yourself in their world and peel off all the things they say that gets in the way of the problem. Its a skill of empathy.

I think the real 10x leaps that 'create new markets' don't just conjure up problems out of thin air: they are novel ways of solving a familiar problem. At best, they solve problems for which people have come to accept the lack of a good solution and thus don't articulate as problems anymore.

In the most extreme case, an innovation creates a new problem in the sense that suddenly a desirable alternative for the status quo can be imagined where it couldn't before. To me, that still implies the innovator just deeply listened to the customer and discovered a potential problem others failed to recognize.

Re: Talking to your customers: a disruptive Agile framework

#37

Post by Lutger » Thu, Aug 18, 2022, 10:44 AM UTC

mkl95 wrote: post #25

I used to do this when I was leading the development of an internal tool used by a small research department. Researchers were initially using a clunky prototype that had not received any end user feedback. By meeting them regularly I was able to fix their pet peeves, add the features they needed, and remove useless stuff. Doing this for an internal tool is of course relatively easy, but ever since I have been wonder…

Yes it works, and it works really well in my experience, but only if the context is right.

The trick is you need to get the real end users on board at least, in addition to and alignment with the one who is calling the shots and/or owning the budget.

Most of the time in business, the person making the decisions is not the one who has to live with the consequences. So for B2B the ability of the decision makers to do sensible things is your limiting factor. You need to really partner up with the decision maker(s), and get a feel for whose problems you are actually solving.

Sometimes there's this political layer over the actual problems that is making things more complex, and which is not actually explicit. Not understanding this layer can lead to a lot of frustration in my experience.

Re: Talking to your customers: a disruptive Agile framework

#38

Post by jordanbeiber » Thu, Aug 18, 2022, 10:53 AM UTC

doctor_eval wrote: post #30

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 agile manifesto is great. So-called capital-A “Agile” - including the thing that people call Scrum, SaFE, all the other hard coded nonsense - are just turnkey processes, churned out by authors who got lucky, that tend to be implemented as silver bullets, with almost no regard for the actual principles and value of the manifesto from which they draw their name.

Ken Schwaber on SAFE - unsafe at any speed:

https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-s...

> Keep the values, keep the principles, think for yourself. A core premise of agile is that the people doing the work are the people who can best figure out how to do it.

Re: Talking to your customers: a disruptive Agile framework

#39

Post by pydry » Thu, Aug 18, 2022, 10:59 AM UTC

kthejoker2 wrote: post #31

pydry wrote: post #29

Earlier quoted context omitted.

Agile has always been extremely vague about what it is. This is at the heart of the problem. This allows everyone to project their own desires on to it - from CEO to PM to programmer to consultant. I get why this happened - the original consultants probably felt that defining it in a way that would alienate people (especially leaders with the budget to hire them) wouldnt be good business. Nonetheless it led to all th…

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, tests and documentation would all have helped with. It's perhaps hard to imagine that this would be controversial but it was - the fact it was 10 years ago and we were under pressure to deliver can perhaps partly explain why.

Try as I might I couldnt argue that his interpretation was wrong. I stared at the words and was shocked when I realized that it was actually perfectly valid.

I have my own understanding of "good agile" and no doubt a lot of developers share it after many decades of good experiences and bad experiences and it arguably means putting processes and tools over individuals and interactions some of the time - like using a linter/autoformatter over arguing about formatting.

I dont know what we need but probably it looks a lot more like an updated version of the joel score than the vague soft focus angel tinged* crap that is the agile manifesto.

For what it's worth, I think your list is also a bit vague.

* I swear that the of the agile manifesto web design was also stolen from a baptist church.

Re: Talking to your customers: a disruptive Agile framework

#40

Post by tchock23 » Thu, Aug 18, 2022, 11:03 AM UTC

withinboredom wrote: post #23

I have brought up talking, like picking up the phone and saying hi, at every workplace I have ever been. The response has always been hilarious, after they also think it is “such a great idea.” - we have sales for that - we should see if we can get a special team for this - let’s just email everyone a survey From my personal Azure account, Microsoft has called me a handful of times, with a product manager and enginee…

Andrew Mason reached out to me to do an interview about his new startup Descript.

Dude is worth a lot of money from his Groupon days and here he is doing one on one calls with his customers.

I think it’s a big reason why Descript is a great product.

Even if he isn’t the one doing that forever, it sets a huge cultural expectation that listening to customers matters.