Thoughts on software, running and other things

Active async feedbacks

“So…” began Simon, my manager, sitting upright in the chair he’d pulled up as I was planning to get up & head home, “I was thinking from the viewpoint of an elderly person”.

“Like yourself” I quipped. Julian, the developer at his desk nearby, cracked a smile.

“In time, and with luck, sure”, Simon countered. “It’ll be a bit daunting for someone like my mum, who’s not tech savvy, to…” he moved on to comments about the screen shots I’d put on messenger earlier. By the time we’d finished, the design for the work I was doing had changed a bit. Earlier during the day, I’d answered queries about the screenshots and the related workflow on messenger.

Async, short for asynchronous, means not occurring at the same time. This post suggests interacting with stakeholders & team members actively when they can spare the time to validate work being done/designed during a sprint.

While collection of feedback using shared/online docs is quite normal, using it to validate & especially work out the next step/s on work being done at the time is relatively rare in my experience. The above dialogue was in aid of a new piece of work implemented using a JavaScript library not used before by our company & the UX expert’s influence was a bit limited – we’d to go with what the library offered. So it made sense to let everyone know at the earliest the shape of things to come.

But even for normal workflows, where the design is decided in advance, it can be useful to request feedback while doing the work. Various factors come to fore during development – how the flow works in practice (seen first on developer’s machine), the actual layout of things, tech issues encountered etc. – which may necessitate change.

Plus, it’ll bring home the design to everyone who cares to look at the screenshots. Shockingly, not everyone fully reads or comprehends the design docs. This way the customer is not in dark till the UAT.

A good messenger/chat app (we use Slack) is all that’s needed to keep things moving while waiting for everyone to chip in, if they’d like to. Quite often it’s one or two stakeholders who have an interest or relevant input, while others just need to be kept in the loop. Different developers seeking feedback for their work can keep this process as distributed as possible.

The time spent by the developers for this sort of activities will most likely be less or similar to that spent in the usual way of things – formal meetings et al. In any case, the benefits of a two way dialogue with the decision makers cannot be overstated. Keeping them abreast of things, knowing anything they’ve discovered since the last time their input was collected, keeping them updated about how things are progressing etc, all bring true agility to a piece of work and help in shaping & putting together the right product.

On the flip side, you may get cornered at the end of the day by someone for a prolonged discussion – don’t say I didn’t warn you 😄.