First of all, we are encouraging of people asking questions of the wider team.

• There’s nothing worse than discovering a question went unasked, and things weren’t right as a result. So how should we best ask questions?

If it’s urgent

• In the most urgent of cases, just go directly to the person you think might be best positioned to answer the question. Tag them on a message in the appropriate Slack channel, or if you are both in the studio, and they aren’t displaying any of the below “do not disturb” signals, just get their attention.

General, non-urgent queries

The #general channel in Slack is a good place to start.

Project specific

• Track down the appropriate #_[project-name] channel, and ask there. If your query is about a specific card in Favro, comment on the relevant card, making sure you’ve @ tagged the relevant teammates in it.

If you are blocked

• Sometimes you’ll get to a point on a card you’re working on, and you simply can’t progress until you’ve had input from someone else on the team, or from the client. Each of the boards in the Production collection has a ‘Blocked’ collumn. These columns are reviewed by project managers and so dragging your card into this column will indicate the need for a conversation.

“Do not disturb”

• We tried hanging those hotel door-handle whatzits on our ears, but the paper-cuts were a nightmare. Instead, if you want to focus and avoid interruptions, there’s a couple of things you can do - and indeed look for if you need to interrupt someone else.

Slack snooze. Slack lets you snooze notifications. This also puts a little ‘z’ next to your username in the Direct Messages dialogue. This is a great way of telling the team that you are there, but unavailable. This is also particularly helpful for remote teammates.

We are big fans of Slack. If you are unfamiliar, it’s an asynchronous chat application which has replaced internal email for us.

• There’s a channel for all major active projects, these start with an “_”. There’s also a number of general DEV channels targeted at specific themes of conversation. Have a wander through and join any you find interesting. Don’t worry though, you’ll be invited to channels where you need to be more directly involved. There are a number of DEV focused channels you should know about and join…
• #announcements: If there’s something important on the horizon, or if there’s DEV news that affects everyone, it will be posted here.
• #calendar: A channel where a number of automated event-based posts end up. Join this channel to receive reminders about sprint flow events so you don’t miss a beat!
• #coop: A channel where we discuss co-operative, governance and Teal management themes.
• #design: A channel to discuss design issues, processes, techniques, and post inspiration sources.
• #dev: A channel to discuss development issues. It’s also where a range of automated messages generated by third-party tools like Github and Jenkins are posted.
• #devsoc_pr: A channel to join if you’d like to keep up to date with our marketing activity, particularly via social media.
• #general: Our all-purpose, water-cooler channel. If it’s not project related, and there isn’t a more focused DEV channel that deals with it, off you go!
• #ideas: A great channel to share new thoughts and ideas. It’s also where :coolio: reacted posts are cross-posted.
• #overheard_clients: Encouragement is always a good thing, in it’s never better than when it’s coming from a client. So this is where we document the great things clients say about us - intentionally or otherwise.
• #pm: Where we talk about sprint planning, our processes and discuss ways we can improve both.

We don’t use email to do internal comms. At all.

Instead, we use a combination of Favro for task-based comms, and Slack for everything else. We’ve developed our own visual language through emoji which helps us react to points really quickly. There are of course the ubiquitous and widely understood 👍 and 😉, but below are some of our more important abstractions… 

We structure the work we do around two-week long cycles which we call sprints.

• They are a way of planning, structuring, and working on projects in a way that creates an easily understood rhythm.
• The sprint includes dedicated time for planning, estimation, retros where we look back at how well individual projects have gone as well as the sprint as a whole. There’s then big windows - the majority of Tuesday, Wednesday and Thursday - which are set aside for focused productive time where we try to avoid all manner of distraction.
• The flow is outlined through our shared “ Studio” and “Sprint Rhythm” Google calendars. But for the sake of completeness, below is an overview of the highlights. All time blocks are whole-team events unless otherwise stated.

All teams have their favourite buzzwords, labels, niche apps and tools, and acronyms.

• Many of the expressions might be shrouded in an amount of history and opaque metaphor. Here’s a list of ours. We’ll grow this over time…

A

• A/B testing: A test that compares two versions of content under controlled conditions to determine which version performs better.
• Agile: A methodology for delivering a project which focuses on the process rather than solely the final output.

B

• Back end: The data access layer of software, often all the parts of a project that are necessary to make it work but that aren’t immediately visible to users.
• Blanc/Blank: The company we were before we were the Developer Society.
• Brand guidelines: A list of design criteria that need to be adhered to, often detailing logo positioning, fonts, colours and other design points. Most orgs have these ranging from a few bullet points to detailed guides.
• Browser: What you use to access the World Wide Web and view sites. A system such as Chrome or Firefox.
• Bug: An error in the code.
• BVIC: Where our offices were before we were at Fazeley Studios.

C

• Call To Action (CTA): A clear request for the user/visitor to do something. Important to include to increase conversion.
• CMS: A Content Management System is a way of creating and editing digital content, often encountered as the way you change content on your site.
• Community Benefit Society (CBS): Our legal wrapper, as opposed to a Limited Company. 
• Conversion: When a person does something you want online (signs petition, donates etc.)
• CRM: A Customer Relationship Management system is a database of contacts and records and a way of managing these.
• CSS: Cascading Style Sheets is a way of formatting the presentation of HTML and other markup.

D

• Django: An open source web application framework which we use to build most of our web projects, coded in Python.
• DNS: Like sign-posts, Domain Name Servers are how the internet knows which servers your email and web services use.

E

• Embed code: Lines of HTML or other code which is added to a site and allows content from elsewhere to be displayed on that site too such as embedding a YouTube video on your site allows users to watch the video without needing to open YouTube.

F

• Favro: The Kansan-Based project management tool we use to track tasks as they pass through the studio.
• Front end: The data presentation layer of software, often all the parts of a project that the user sees from layouts to animations.

G

• GDPR: The General Data Protection Regulation is an EU wide piece of legislation governing how organisations collect and process data online.
• Glitter: Front-end content management tool we built on top of Django.
• Google Analytics: Google’s system for tracking the performance of a site. Needs to be setup for each new website.

H

• Hosting: The way of making your site accessible via the web. Typically how you purchase a URL and connect it to your content.
• HTML: The standard markup language for building websites. The code that is written which creates the site itself. HTML brings the design of the site to life.

I

• Image dimensions: The proportions of an image, often expressed as a ratio such as 2:1 (an image that is twice as wide as it is tall) or in total pixels such as 1200 x 900.

J

• Javascript: A programming language for producing software.

K

• Kanban: A system of organising tasks to be completed via a board system which is common in software development. Often run via a program like Trello or Favro.

M

• Mobile app: Software designed to run on smartphones and other mobile devices.
• MSA: Master Service Agreement is a contract which governs how we relate to and work with a client. It covers anything we might want to do with them, an means the client only ever has to read the big scary document once at the beginning of a working relationship. The details of an individual project are then felt with in a separate Statements of Work (SoW). This makes the sign-off process for each new contract far more straight forward.
• MVP: The minimum viable product or the smallest possible version of your project you can build that has the core functionality. You would produce an MVP in order to test your project out early and modify it through an agile process.

P

• Python: An open source programming language, for which we have much love.

R

• Responsive design: A way of building software so that it presents and functions well on all devices.

S

• SEO: A way of structuring the code on your site to make it more likely to show up in unpaid searches.
• Servers: The computers where the code to run your websites and data on lives.
• SoW: Statement of Work is a contract which details the deliverables, timelines and salient details about a given project. An SoW invokes the terms played out in a Master Service Agreement (MSA) which the client must also have signed.
• SSL: A Secure Sockets Layer is a standard security technology for establishing an encrypted link between a server and a client. A standard digital security measure denoted by the S in HTTPS in a URL.

U

• UI: The user interface is how people interact with software.
• URL: A Uniform Resource Locator is best understood as the address of the site (https://www.dev.ngo/ for example).
• User testing: The process by which you can test a site/app/other build with people and record feedback.
• UX: The user experience, for explain how it is (and how that makes you feel) to use a certain site.

V

• Vector images: Image formats such as SVG or EPS which can scale infinitely without losing quality and pixelating.

W

• Waterfall: A methodology for delivering a project which outlines a specific list of functionality.
• Web app: A website that presents and functions like an app and lives on the web, rather than on a device.
• Wagtail: A CMS which sits onto of Django, we're transitioning to using this as our default CMS in place of Glitter for many of our more standard website projects.
• WYSIWYG: What You See Is What You Get — a form of editor allowing you to modify content in your CMS in a way that closely looks like how it will present on the live site.

Everyone in the team will have their own way of communicating and that difference in style and tone is great.

There are also a few key things to keep in mind so our comms are on brand for DEV and consistent across the team.

• We’re professional but not corporate. We need to make sure our comms are reassuring and generating trust but we want to emphasise one of our key USPs which is the fact we are a not for profit and part of the third sector not just servicing it.
• As part of that avoid corporate language where possible (we say ‘partner’ not ‘client’ for example).
• We’re dealing with important topics so it’s important to be serious but we shouldn’t be solemn/somber, it’s important we enjoy what we’re working on and we convey that outwardly.
• Quickly! That doesn’t mean we have to answer all questions right away but if a partner contacts us we should respond as quickly as possible. Often this will just be a holding message to acknowledge we’ve seen it and give a timeline for a full response but this will greatly help reduce stress for our NGO partners.
• Positively! Written communication is hard and it’s not great for conveying tone. Make sure you’re adding positive elements into our comms with partners.
  • Show some love to them
  • Highlight specific parts of the project we’re enjoying working on
  • Show we’re familiar with their mission and invested in that

When speaking with annoying NGO partners

We’re all human but NGO people are a very particular type of human! As a breed they’re often wonderful to work with but there are some common patterns of behaviour that we see time and again which are incredibly frustrating. Here are a few points for how we communicate around that.

• When you’re getting annoyed, remember two things:
  1. Like Wikipedia, assume good faith. We work exclusively with people who are spending their lives working for important causes. Like any group of people there will be some assholes but really they’re a pretty good bunch on the whole working to often insane deadlines with few resources and little support.
  2. Are you 100% sure you have all the information? It’s likely there are circumstances we can’t see that might be producing sub-optimal decisions

• A lot of our partners are verbal communicators so if emails are getting tense, consider a quick call. That often clears the air and unblocks things in a remarkable way.
• If you’re dealing with a request, try to always send a holding-email if you can’t respond that day. An acknowledgement that you’ve seen the request along with an outline of when it will be addressed will save a partner chasing you.
• If you’re finding a conversation difficult, tag in a teammate for a second opinion.
• ‘When they go low, we go high...and then retro’. Keep it calm and classy at all times. If someone is really difficult to work with then let’s discuss this in retro (or a breakout meeting at any time) and address it as an org not individually in an email. You will be supported but don’t go rogue!
• If you feel the urge to say something sharp in response...then just take a breath and step away from the keyboard. Grab a teammate or your Buddy and vent then leave it a few hours before responding.

Scheduling terms

There has historically been some confusion over the usage of language when scheduling. Here’s the v1 for names of things, let's try to stick to these to avoid confusion across concepts.

• Days = One day in the calendar. There’s 365.25 of them per year.
  “There are only four days next week because of the Bank Holiday.”
  
• Sprint = A two week unit of time DEV uses for our rhythm. 26 in a year. Remains independent of clients.
  “We’ll be working on that in the next Sprint which starts on Monday.”
  
• Work Day, Production Day or Billable Day = One day spent delivering on a project. The limit to how many Work, Production or Billable Days in a Sprint is the number of staff working.
  “We only have 4 Production Days of Back End next Sprint because nearly everyone is on leave!”
  
• Work Sprint or Production Sprint = A unit of work we use for sales purposes (where we call it a Production Sprint with clients). This has two Back End and one Front End team member working on it and design as required (to be refined) and runs for one Sprint. This mean there's at least 3*6 Production Days.
  “Great news, Oxfam just booked in two more Work Sprints on ACT.”