5 ms·

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 developm

by harryf 8y ago

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 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.

martin_drapeau 8y ago
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.
perfunctory 8y ago
> 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.
- fouc 8y ago
  If the customers are within your organization, can't you directly reach out to them? Don't ask for permission from a manager.
  - wtracy 8y ago
    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.
    - fouc 8y ago
      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.
- spamizbad 8y ago
  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.
- clairity 8y ago
  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.
  - kashyapc 8y ago
    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.
    - clairity 8y ago
      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.
      - wbl 8y ago
        Understanding the problem is development.
      - kashyapc 8y ago
        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 http://pages.cs.wisc.edu/~remzi/Naur.pdf
superfamicom 8y ago
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.
wil421 8y ago
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.
otakucode 8y ago
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."

by harryf 8y ago

martin_drapeau 8y ago

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.

perfunctory 8y ago

> 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.

fouc 8y ago
If the customers are within your organization, can't you directly reach out to them? Don't ask for permission from a manager.
- wtracy 8y ago
  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.
  - fouc 8y ago
    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.
spamizbad 8y ago
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.
clairity 8y ago
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.
- kashyapc 8y ago
  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.
  - clairity 8y ago
    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.
    - wbl 8y ago
      Understanding the problem is development.
    - kashyapc 8y ago
      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 http://pages.cs.wisc.edu/~remzi/Naur.pdf

superfamicom 8y ago

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.

wil421 8y ago

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.

otakucode 8y ago

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."