Tech should be inclusive, with new developments bringing the world together. But there are barriers to accessibility, not least of all the vernacular. We decode some of the jargon
Trying to decode your tech team? Understanding and learning the software development lingo doesn’t have to be daunting.
Getting a grip on the basic steps and jargon can shed light on what many people see as the ‘black box’ of charity app development.
Better communication can also help promote data sharing across organisations, meaning no more data silos. We focus on the world of tech development we explore the basis of how software is produced and launched.
The theory behind software development generally follows two main ideas. The first, and more traditional is called the ‘waterfall’ method.
The project management steps to developing software are like a waterfall cascade. According to ScienceDirect, the approach follows a logical, ordered process to software delivery:
The waterfall method means that each step follows one after the other. The point is that projects don’t progress to the next stage unless the teams are happy with the current one.
Agile software development is the more modern theory. Agile considers views from different departments, and focuses on what customers want. Customer preferences are prioritised in the development process.
Instead of step-by-step stages, development can happen at the same time across different processes. During each development phase, something is completed or delivered. Because agile focuses on delivering what customers want, each phase can be demonstrated or shown to charity users.
Charities are already using agile to develop and launch products. Diabetes UK uses agile because the approach lets other teams know where their bit of the project stands in the queue.
“User stories and the concept of a backlog have been key here. We usually involve product owners and any wider project group in the development of user stories. And colleagues appreciate that even if their work cannot be done now, there is a backlog of user stories/potential projects, where they have contributed to prioritisation and can see an ordered list for future development.”
- Graeme Manuel, Digital Communications Manager at Diabetes UK
Diabetes UK’s experience shows us the benefits of agile are transparent working and better communication.
For many charity teams, agile offers a more flexible way of working, because teams are working all at once. There’s no waiting for the previous ‘stage’ to finish.
Now that we’ve covered the basics, we can start to decode your IT team. By looking at key terms and concepts from both the waterfall and agile approach, charities can better understand at what stage projects are in.
For both waterfall and agile software development, requirements outline what’s really needed in software. Essentially, the requirements are a collection of deliverables that the software is meant to meet.
For teams using agile development, requirements come in user stories. User stories are simple, short descriptions. Software users typically define what they want to achieve and why that’s the case. For IT teams, user stories help break down how the new software might be used into small bite-sized pieces.
The acronym stands for ‘user acceptance testing’. Tech terms define the UAT as: “A process designed to help ensure products will meet user expectations when they are released. It involves running a product through a series of specific tests that help indicate whether or not the product will meet the needs of its users.”
In simple terms, UAT tests how closely the new software works, and whether it meets the expectations of users. UAT can also give extra comfort to charity teams around quality.
No, your charity tech team hasn’t morphed into a rugby team. A scrum is a small team of multi-talented tech people working together. The scrum team has a scrum master, who helps guide the team through short bursts of activity to deliver a user story.
These short bursts of activity are called ‘sprints.’
To make sure that scrum teams stay on track, sprints are made up of timeboxes.
Timeboxes are defined periods of work – they can be a few days to a week, depending on the project.
After all the phases of UAT have been completed, a minimum viable product (MVP) emerges.
The MVP is a prototype of the end-product. The MVP is the version of the software that helps developers gather the most information on what customers do with the product.
Eric Ries, the author of The Lean Startup says: “The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.”
The bottom line is that the MVP is the most basic product developers launch in order to learn and improve on.
Sometimes confused with the MVP, MMP isn’t a feedback tool for software developers. The MMP is the version of the software with the minimum number of features to satisfy charity users.
For charities focusing on delivering digital services, the MMP can be sent to a specific set of people first. Once upgraded with more features, a second version of the application can be rolled out for everyone else. For charity tech teams, the MMP proves that there is an appetite for the new application.
Releases in software development have specific characteristics. The Project Management Institute notes that to be successful, charity tech releases should be:
As releases are made, maintenance updates can also be done. For charity software apps, this could take the form of an upgrade.