Comment by harryf | Hacker News Reader

Comment by harryf | Hacker News Reader

This is a great document, especially with the DoD name on it to give it weight.

> Key flags that a project is not really agile: Nobody on the software development team is talking with and observing the users of the software in action; we mean the actual users of the actual code.

This one is a largely a "comfort zone" problem IMO;

- Recruiting users, especially for B2C products is tricky

- Management get nervous about "unwashed developers" talking to customers

- Developers have to leave cosy offices

- In remote teams it's even harder

- It's tricky to schedule without disrupting normal work

- Imagining the world and designing features for it in a cosy office is a great ego trip

- Nobody really knows how best to interact with users

- Business people get nervous about developers having opinions

... etc.

Many places I've seen even Product "Owners" never talking to users and basically spending all time managing the backlog.

All very comfy and getting out of that comfort zone takes significant effort.

I once gave a talk about the fundamental flaw of much mobile app development which is summarized in this slide - https://i.imgur.com/v1qmR8m.jpg ... the "older generation" making apps on big screens, fast networks while sat a desk for a younger generation on the move, that barely knows what a mouse is.

One of my favorite software jobs was working on an in-store UI for creating custom apparel, not because of the software stack but because I got to sit in the store, in the mall and work, observe, and help people use the software. Seeing their struggles and questions and ideas was truly the most inspired I have ever felt working with any software.

> Nobody on the software development team is talking with and observing the users of the software in action

On every new project (usually internal enterprise software) I plead to let me talk to the users. Every time in vain.

If the customers are within your organization, can't you directly reach out to them? Don't ask for permission from a manager.

Tread with care. There are organizations where "going around management" gets you flagged as a loose cannon.

It probably won't get you fired outright, but does destroy the goodwill that you will need to make meaningful changes down the road.

Now, if you can do it without rocking the boat (perhaps without management ever finding out) then go for it.

It doesn't hurt to cc management at times or find a way to keep them in the loop on your immediate findings etc. That way it's just a demonstration of 'showing initiative' while still being a team player.

Can you talk to the people who talk to the customers (The sales team)? It's indirect, and you need to isolate what's "real" and what's "If I had X feature I think I could close more sales"[1], but it's better than nothing.

[1]which does have value, but not necessarily value to the customer.

as fouc noted in a sibling comment, you shouldn't need to ask for permission to talk to customers if the organization is truly agile. however, the product owner (which i've been in various capacities) should bring a lot of customer information to the table so you can focus most of your time on development.

it's unfortunate that your organizational structure prevents you from doing so.

Even if a "Product Owner" brings a lot of customer information, it is still damn important for those developers who are genuinely willing (and able), to interact with customers—even if it is only via medium-bandwidth tools like video calls. Developers should not worry about spending some time talking to users.

we are not "disagreeing" that develoeprs have freedom to talk to customers. but if a developer spends most of their time doing something other than development, there are other inefficiencies going on.

Understanding the problem is development.

I know we agree on some level. Still, I can't help but feel like you have a somewhat narrow definition of "developer". A thoughtful senior developer who is in it for the long-run (read 15–30 years), and thinks in terms of "building a craft" will (and must) aim for a more well-rounded set of skills (that does not involve "development" in the narrow sense of hurling code)—e.g. giving high-quality technical talks that provide durable value, high-bandwidth interactions with customers and users, writing specifications, bringing multiple technical teams together to architect features and solutions (which requires careful and effective communication), and so forth.

Related: You might've already come across it, if not, I suggest reading this paper (it's not about any specific technical topic, but more about the thought processes) from Peter Naur, titled: Programming as Theory Building.

[1] http://pages.cs.wisc.edu/~remzi/Naur.pdf

I’ve been the Software Engineer on customer sites and visting call centers with 100s of users in international locations. It was a very good experience every time. I’m certainly not the unwashed developer type but some of the non IT folk did share some of the points you raised.

The experience was great and I’m trying to do the same at my new job. If anyone has the chance or can convince their managers I’d jump on it immediately.

I noticed that they very assiduously avoided the whole "Working software over comprehensive documentation" angle and didn't say anything crazy like "maybe CDRLs of stupendous quantity and length due at regular intervals to the DoD might negatively impact development."

You are correct. As a company grows, process starts taking over talking to users. Change becomes a disturbance and backlog grooming more important. I say measure traction with the user and make that the focal point. The rest is secondary.

Reply on news.ycombinator.com