Category Archives: Conferences

Distributed development keynotes

Attended UX Lausanne for the second time this year – and while it was rather small (which is actually good as you’re better connected to speakers in terms of Q&A and follow-up), it was not solely on UX but a lot on workflow and project development – something that seems to be called Product Experience.

One of the talks was given by a guy from Automattic company (Davide Casali) – first I thought they’re WordPress authors, but turned out they’re (large) contributors and maintainers of WordPress.com – that has a distributed nature, i.e. everyone works remotely. Like, everybody – few colleagues might use same shared space, but even then they’re not in the same team. Now that is definitely not the case for everyone, but nowadays many companies allow at least temporary remote work, thought of sharing key points here – I think they’re quite interesting and some of them could be used in different cases.

So here are their principles:

  • before creating new team (or starting new project), meet live to have “Minimum Viable Discussion” to quickly understand key points, sort out initial discrepancies in domain knowledge and prepare brief plan for the closest next steps
  • transparently share all changes, specs and discussions – “if it’s not transparently shared, it doesn’t exist” (more office-bound sticky-note-flavor version of this proverb was “if it’s not on the wall, it doesn’t exist”)
  • have few communication spaces for different needs:
    • Real-time channel (like Slack or Jabber or, sigh, Facebook) for immediate personal and team communication
    • Team space on some shared documents resource – they, as WordPress-targeted company, use a P2 theme for WordPress that allows posting comment to posts and comments to comments – basically to host a discussion on the subject. Point is to have something that could be subscribed to or viewed by any employee, and that team members would overview daily to see/discuss updates or refer to while developing
    • “Stable” documentation storage for more permanent things like articles or specs of deployed products etc.
  • each team (BTW they also have small teams, 4-5 people of different skills) focuses and collaborates on one thing (project or task)
  • Independent individuals, i.e. everyone maintains own priorities. Tasks are managed with any suitable tracker (they use Trello)
  • “zero waste” in terms of no bureaucracy regarding e.g. permissions or access
  • standup-kind updates are posted to team channel each time team member becomes available – along with overview of the progress, provides an indication when person becomes available
  • live meetups ~4 times a year – 3-5 days of work, discussions and some off-work time together
  • teammates (but not projects) are usually picked from within few timezones from one another to aid live communication
  • everyone can follow any other team by subscribing to their shared documentation channel

This is all “JFTR”, but some could really consider utilising part of these practices for daily work and communication improvements.

Also another reference to keep, https://www.helpscout.net/blog/agile-remote-teams/

SECR-2013 notes at the end of 2013

Haven’t updated this place for a while – need to get back on this new habit, really. Well, at least
I hope I do so in upcoming year (should be a big one anyways). So a quick update just before I tear the old calendar down from the wall (and I pity that, it’s the Futurama genuine 2013 calendar) – some records that date back as far as late October, some points I squeezed from that SECR conference I attended back then. These are quick and without any verbose explanation – rather “FTR” stuff to keep.

OPs/delivery:

  • monitor user delivery/connection time, detect slow (comparing to others or expected), direct them to closer/… node/instance by default. Meaning, you have logs, so you have the time of requests processing. So if you have some requests of one kind taking (under circumstances – be it another location or another browser or something) – taking longer that requests of the same king in other set of circumstances, you might need to adjust delivery rules – redirect traffic, test under different environment etc.
  • config/(code?) deployment through the Dropbox – as simple as it sounds, “simple parts” (I’m thinking configs, but might be updates as well) distribution via Dropbox.

Initial project stage:

  • “visual brief” – ask the basic associations, like “fast”, “pretty”, … – give some appropriate images to pick from, iterate. Like, ask customer what impression his product is aiming to project. Say the answer is “paramount”. Then suggest few images – mountain, the Sun, the Earth and the Moon, big teacher and small student – and ask customer to pick one (or few). And then iterate with styles and colors and other ideas.
  • moodboards (MoodShare…) – pick lots of stuff on the screen, let customer select, SCAMPER (http://www.mindtools.com/pages/article/newCT_02.htm)

CI

  • try test using DB/ssh connect (separate config) to run local changes against test instance remotely
  • togglers: big-feature switches, allow to disable/enable particular features separately, config- (or environment-) controlled way (triggers in cookies, ENV, config, URL etc.
  • same tests on CI and local, local ran for feature-related validations (branches), CI for default
  • think performance tests

KPI (http://management.about.com/cs/generalmanagement/a/keyperfindic.htm):

  • measure what you want to adjust (meaning parameters selected fro KPI estimation)

Dev points:

  • make user feedback easy (put feedback interface at a clearly visible place, make it simple)
  • get a cool team (people that fit together (this is important), motivated (not just money, also interested in what they’re doing), productive)
  • make internal communication easy (chat, video, whatever – to let teams or team members connect without any hassle)

QA:

  • ask testers to write test cases descriptions right after ticket is created (confirmed, put to backlog) and discuss/adjust along the way. I think this one is really beneficial if used the right way, although no personal experience here yet.

Well, that’s it for now – and probably for this year, too. See me (for I think I’m the only reader – or at least a writer – of this blog) in 2014!