CritiqueDontReact to the develop"> Must Be Present

Must Be Present

It’s a common misconception that developers write software for users. Developers write software with users. You “must be present” to win. You must share what you need, attend demos, and provide effective feedback (see CritiqueDontReact to the development team. You are a part of the team.

Pain Points

  • The team spends time building features you don’t want
  • The team makes assumptions about features due to a lack of your involvement
  • You don’t attend demos, but complain about screen layout and work flow after you receive the feature

Benefits

  • You get what you need to make your work easier and better
  • You spend less time fuming and wondering what dolt decided to implement the feature in a way that makes your work more difficult
  • The flow of new Working Tested Features (WTFs) improves due to less rework
  • You create a relationship with the developers leading to trust.

Assessment

  • You are actively engaged in the development effort, provide timely feedback, and ensure views are those of the collective body of business users—not just the view of a single individual (100pts)
  • You make an effort to be available and allow time to meet with the team (20pts)
  • You rarely show up for demos (-20pt)
  • The only feedback you provide occurs after a feature is in production, and you blame the developers for problems (-500pts)

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this practice:

Setup

  1. Pick an upcoming feature that impacts your work
  2. Find and contact the developers working on that feature

Trial

  1. Propose using AnswersFromExperiments to engage with them
  2. The developers have a daily TeamSync. Join it during the experiment
  3. In addition to the TeamSync find ways to stay in touch and be available to answer their questions
  4. Run the experiment. Use the feedback suggestions in CritiqueDontReact

Evaluate Feedback

  1. Did you stay in touch with the development team?
  2. Did the feature provide the value you need?
  3. What could you do to improve the dialog for next time?

What Does it Look like?

The basic software development work flow is deceptively simple. It looks like

BasicWorkFlow.png

You tell the developer what you want to make your work easier or better. After a while (the two   on the Developer to User arrow means “delay”) you get what you want. Or not.

The problem occurs when someone else tells the user what you want. Historically, software development has many people who are happy to talk with you and then tell the developers what they think you want.

Thirty years ago we had systems analysts, business analysts and others translating user needs into requirement documents. Developers would read these documents, make assumptions about what the analysts meant and create the necessary screens/code/databases to fulfill their understanding. Testers would then read the documents, run the system and try to resolve the differences between their understanding and the developers’ understanding. Eventually (often a year or more) the user finally sees the system, and wonders what happened.

This leads to a game of “telephone.”1

What you want gets garbled as it passes through multiple people. Not maliciously, but none the less, you don’t get what you want or need.

In more modern times, we have Product Owners telling teams what you want. Teams aim for continuous delivery. Teams schedule demos to show the features (not systems) they’ve finished and tested. And without you talking directly to the developers and attending the TeamSync and demos, you’re still playing a “telephone” game.

This is one more reason to RemoveProxiestoPeople.

Feedback determines the rate of software development. Quick feedback loops lead to quicker delivery of WTFs.

Warning Signs

  • You’ve never met the developers
  • The delivery rate of WTFs slows as developers change existing code to align the feature with your needs
  • WTFs don’t provide user value

How To Fail Spectacularly

  • Ignore the developers
  • Blame the developers for not providing value
  • Treat developers with hostility and contempt
  • Treat users with hostility and contempt

  (Provide Useful Feedback) Next→


  1. See https://en.wikipedia.org/wiki/Telephone_(game) 

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.