The most important technology decision you'll ever make
Introduction
The technology landscape is moving at a frightening pace. Approaches and tools that were the de-facto standard last month are soon irrelevant, impacting productivity and development. Platform abstractions continue to consume more commoditised work, and everyday over seven million new JavaScript frameworks are born.
Common mistakes
1. We’re doing agile!
Almost everyone is now (or at least is claiming to be) Agile. Done properly, it’s a great way to take advantage of what technology can do, allowing us to continually course correct in small steps to help us reach a better destination. There’s often a distinction made between ‘Big A Agile’ and ‘Small a agile’, with the former referring to the industry of frameworks and certifications which have sprung up seeking to take advantage of the popularity of agile.
Some of these are well intended, most are often a distraction from the actual behavioural changes needed to deliver in an agile fashion. ‘Small a’ agile is then used as a reference to the core principles of agile outlined in the Manifesto.
There’s a simple acid test you can do to decipher the reality of where you are: are real end users frequently using your outputs, and is their feedback used to inform what is being delivered? If the answer is no, you’ve probably got Agile™ - not agile.
2. We’ve got a business case!
It’s important to have a business case. Understanding why you are doing something is critical to knowing if you should do it, and if so, how to prioritise it against other workloads. As well as this, a business case is a good measurement for success. However, like architecture diagrams, business cases come in all shapes and sizes.
Some are well thought out and comprised of evidenced research, whilst others are simply a baseless PowerPoint deck; light on substance and sold based on the charisma of the presenter. In any case, it’s always worth validating that a genuine user need has been identified, and that the case is clear on three things – 1. Who wants this, 2. Why do they want this, and 3. Is it feasible to deliver this to them? Many business cases still come with questionable assumptions about user uptake rates, with no clear approach to meeting and exceeding this aim.
3. We’ve done our user research, now it’s delivery time
If you have experience in engaging with user research, you’ll understand the importance of ensuring it remains an ongoing activity throughout the duration of a project. Lots of organisations fall into the trap of doing a requirement gathering activity (often with good user research practices) then ending the focus at the outset of the project.
Technology and development tools exist to allow us to iterate quickly and allow continual user input, focussing on getting feedback cheaply and quickly before a team has gone too far down an assumed path.
With one of our clients, we booked a private cinema close to the office every two weeks and used it to get the entire delivery team together to watch the latest user research and interaction reviews. This was transformative in both the attitudes of the delivery team and in catching issues early, leading to a much more efficient delivery.
4. Wrong definition of ‘user’
It’s usually easy to pinpoint who the end user of a system is. Those who use the front end are typically the ones we think about first, such as the customer, citizen, internal staff and/or third party. However, it is also very easy to overlook all the other users of a system, i.e., the people who operate the software in production, those who manage the financing of the system, those who work on the service desk and the people who ensure the security and compliance of the organisation.
Each one of these people are all users, and they all have needs which need to be factored in and prioritised. On the other hand, organisations can make the opposite mistake - giving people who are not actually users too much influence over what is delivered, causing significant harm and misdirection.
5. Everyone else is doing AI / Low-code / Blockchain / Kubernetes
The final mistake considers the age-old issue of chasing the latest technology trends and fashions. The four mentioned above (AI, Low-code, Blockchain and Kubernetes) all have their own use cases - but some organisations and teams continue to initially position each of these as their answer, and then will work backwards to try and find a need.
Whilst it’s good to sustain innovation, explore new ways of doing things and expand on what you already know, a technology-led piece of work is usually a red flag. It’s imperative that a conversation is had detailing the problem we are trying to solve, or the opportunity we are expecting to take advantage of. I haven’t yet found a user who cares if their service has a shiny container orchestration layer under the hood, but I’ve seen plenty of shiny container orchestration layers looking for users!
To summarise
There’s no doubt that technology is an expansive and, often intimidating, domain. However, we must make sure that whatever we build and however we build it is informed centrally by user needs, continues to engage users, and proves out the value in small iterative chunks. All these considerations will greatly increase the confidence in the specific technology decisions being made, and ultimately, the output of the delivery project.
At Kainos, we set our teams up for success by making sure everyone understands what user need they are delivering against. If your organisation is struggling with lots of digital delivery activity but little translation into satisfied users, please reach out to see where we can help you delight users and deliver faster by simplifying and focussing your approach.