We hate unnecessary jargon. We’re all for using simple language and making things as clear as possible - to each other as well as our clients!
But no matter how much you avoid it, every sector, every industry, every business has its own specific language it uses to communicate.
We’ve broken down ours so if you don’t understand a particular term, you can check it here. Don’t let that stop you from asking us directly, though - there are no stupid questions!
This is the name of the software development process we use at Switchplane. Although this system of project management was originally designed for banking institutions, it is highly applicable and commonly used in software development. The framework is based on continual improvement, iterative development, quick return on investment, and it encourages a rapid and flexible response to change.
API is the acronym for Application Programming Interface. It's basically how one piece of software talks to another, or "integrates" with something else.
The name for the stuff that happens in the background on a website. This will often never be visible to the end user. It includes the way that data is stored behind the scenes, responding to things that a user has done, and any processing that is required.
This is a collection of features, fixes, and requirements that are needed to deliver a product. Items are prioritised from the backlog and brought into a Sprint based on considerations such as risk, business value, dependencies, size, and date needed.
These are problems which prevent a particular request or next step from being completed. These are generally raised by developers in our Daily Stand Up meetings: it may be that more information is needed before a request can be completed, or another step needs to finish before a developer can make a start on a request allocated to them.
This is a list of updates that have been completed with a new release to a website, mobile app, or web system. The developers keep track of the changes made throughout the project, and we share the changelog for each release with our clients.
The CMS, or Content Management System, is the area that administrators can log into to make changes to content on a website. The amount of access an administrator has can depend on the design of a website, and how much will need to be changed on a regular basis.
Daily Stand Up
This happens every day at 10am. The whole team get together to see how progress on the Sprint is going, to see if there are any issues (‘blockers’) arising which prevent a developer from completing a task, and to see if there are any announcements. This normally takes about 5 minutes to complete, and it’s a great way for ensuring that everyone is on track.
These are our developers - the people working directly on the code. All our team are directly employed and all work is completed in-house.
This is the name for the part of the website closest to the user. Work done on the front end will always be visible using a web browser. It encapsulates the look and feel of the site as the experience that the user has when interacting with the website.
This is our own internal system for managing requests and for running our Sprint cycle. We’re really proud of this and apply our own principles of continuous improvement to make our own web app as good as it can be.
Once our graphics designer has put a website design together, our front end developer Dean does a bit of magic with the visual presentation of a web page to make it look awesome. He marks up the site.
This refers to Minimum Viable Product. This is a product with just enough features to satisfy early customers; the intention is then to get their feedback as soon as possible to influence future development of the project.
This is the connected workspace where we plan, organise, and collaborate on work. We sometimes share particular areas with our clients so they can view our planning too.
Open source is a term that refers to open source software (OSS). Open source software is code that can been seen, modified, and distributed by anyone.
This is our Operations Team, headed up by Donna (COO) and supported by Sarah C (Operations Manager), Sarah B (HR Officer), Geoff (Office Manager), Christian (Graphic Designer), and Carrie (Growth Marketing Executive).
Plugins are pieces of software that add capabilities to an existing program without changing that program's code. No single piece of software can deliver every function for every user - no matter how powerful it might be. Plugins make it easier to add specific features to applications and software without affecting the source code.
The Project Champion is the lead developer involved in the project. Whilst other developers on the team will work on various requests throughout the life of the project, the Project Champion has the overall context. The Project Champion typically attends meetings with clients to help make decisions on the best next steps, and will carry out the necessary planning and quality control to get the new features released.
QC stands for Quality Control. Every piece of work is checked by another person to eliminate errors or make any changes required.
This is a term used when cleaning up code. There are multiple reasons why you might want to refactor a piece of work. It could be to make it more readable for the next person who comes along or to make room for an additional piece of functionality. It is something that is done regularly in the development process; some argue that you should spend more time refactoring than writing the code in the first place!
When a new feature is asked for by a client, we break this down into a series of smaller requests, which can be completed and delivered in one chunk or feature. A number of requests will go into a Sprint.
A release is when new functionality is deployed to the system. Developers will prepare a release offline and an automated deployment process kicks in to make it live.
The retro, or retrospective, takes place every second Friday for both the Development team and the Operations team. In the retro, the teams look at what went well, what went badly, and raise any other comments to help with the concept of continuous improvement.
This is the specific framework of Agile software development that we use; it is an iterative and incremental framework for product development. Time is broken down into Sprints of a fixed duration - for us, we use two-week cycles. During these periods, we hold a number of Sprint ceremonies which facilitate the process and enable our client work to be allocated for development in small, deliverable chunks. For a full explanation of Scrum, watch this 10 minute video.
Show and Tell
Internally, we hold this once a month. The team gathers together and demonstrates the work that has been completed on their projects in that cycle, so that the whole team has the full context of the current state of the project. Externally, at the beginning of client meetings, we will typically Show and Tell the progress made on the project since we last met.
This is our preferred method of internal communication; we’ve almost eliminated email internally. Slack is like an instant messenger system, but with hundreds of useful add-ons. For clients we work with regularly, we encourage starting a Slack workspace to enable fast and to-the-point communications without any of the extraneous noise.
A spike is a piece of investigatory work that needs to be done in order for the requests to be worked out and allocated. It helps provide a clearer picture of the problem and its solutions.
A Sprint is simply a two-week period of planned project work. Under the Agile ethos, instead of attempting to plan an entire project, we break it down into manageable chunks called Sprints. We allocate 80% of our working hours to each one. That leaves time for us to cover unexpected issues arising with non-Sprint projects, such as an issue which is too urgent to wait for the next Sprint cycle.
This happens both internally and externally with our clients. Internally, we plan work and fine tune what is needed technically for the next stage of a project. Externally, we meet with our clients regularly to find out what are the next priorities in the delivery of the project as a whole, and decide what our next steps should be together.
This refers to a block of time that is set aside or allocated to a particular task. This is usually used when there are larger tasks which need chipping away at, or perhaps for a spike to investigate a problem further.
The user story is a collection of phrases and sentences that capture a description of a software feature from an end-user perspective. The technical requirements can then be derived from this. For example: "As a user, I would like to understand the Agile process a little better!"
A Wash Up is a post-project meeting to work out what went well, what went wrong, and the lessons that can be learned and used to plan for future projects.
These are the very bare bones of a design concept, put together to ensure the required elements are present on a page. Once the basic structure is there, the design can be fully developed and fleshed out.
Are we missing any words you don't know?
Let us know!