Although many organisations realised how important it is to adopt agile ways of working, and what the benefits of business agility are, it is still very challenging to gather all business requirements and insights from user research to inform better decisions. Usually, in this phase, many of us rush as we want to deliver value to our users quickly and as a result, we underestimate the importance of Discovery.
Discovery is the first phase in a service lifecycle. The Government Service Standard says: ‘Understand users and their needs’.
The objective of Discovery is to understand our users, their habits, motivations and what they struggle with when using our service. It doesn’t matter if your service is digital or not, it’s all about satisfying user needs and delivering value.
As Scrum, one of the agile methodologies says, it’s important to work in cross-functional / multidisciplinary teams and have all the skills and capabilities needed in your team to deliver a product. This also includes requirements gathering and user research, therefore it’s crucial our Product Owners are supported by other roles, for example: User Researchers, Business Analysts, Project Managers and UX or Service Designers.
This can be done through one-to-one interviews or user workshops and observations. We need to understand what currently works and what doesn’t in order to identify areas for improvement.
Before thinking of a solution, you’ll also need to create problem statements so that you know what problem you’re trying to solve and what success criteria will look like.
This is the time when you need to explore the problem area in-depth and analyse the root cause. Interestingly, the problem is not always a real problem but a symptom, therefore using the 5 Why’s method has helped me many times before I create a problem statement.
For example, when delivering Agile and DevOps transformation programmes, you find out that the problem is not solely a technology problem. In most of the cases, it is a people or process problem and collaboration, communication, or stakeholder engagement need to be improved first.
When you have all the problem statements, you need to prioritise them and choose the hardest problem to solve or the one that is giving a lot of value to your users but taking a relatively low effort to deliver.
Particularly when dealing with a highly complex environment, you may need to think of a few potential solutions that could work. So test them all with your users in the next phase which is called Alpha.
The objective of Alpha is to build a prototype and test it with the users to learn from their feedback. The prototype / proof of concept doesn’t need to be perfect or coded in the right way but it should be just a mock-up that could be presented in front of the users and business stakeholders to learn if it’s going to work in real life. By applying various Lean and Agile models e.g. ‘Build, Measure, Learn’ or ’Plan, Do, Check, Act’, you continuously learn and measure the results. It’s a cycle and you never stop learning about your users.
We live in a complex and highly competitive environment where technology changes, users become more and more demanding and you need to manage shifting priorities.
That’s why you learn by engaging with your users through the whole service lifecycle.
At the end of Alpha, you should be in a good position to define what solution you’re going to build in Beta. Taking an evidence-based approach will help to inform decisions and define a roadmap for the Beta phase. By rapid prototyping, you minimise the risk of delivering something that’s not fit for purpose or doesn’t meet user needs. More importantly, this is also the time to make more critical decisions: ‘Go / no go” and ‘kill’ an idea if necessary.
In the Beta phase, you build the real thing. If you build software you should start building it from scratch so that you can make it perfect by writing the right code. Very often teams think they can improve their prototypes, and make them better, but actually, a prototype is only a mockup which validates your ideas, assumptions and hypothesis, and not a solution.
You literally throw the prototype away and build the real thing. After testing, you can release it to a wider audience and test it again. Once this phase is completed, you can make improvements to your service before moving to Live.
In the Live phase, your service is live and accessible to your user group. You’re going to learn if it meets user needs and measure the success. Again, it’s very important to remember that’s not the end. When a service is live, you still need to look after it e.g. maintain it, run it and continuously improve.
When your service moves into Live, you should not experience any surprises as you have been gradually releasing and testing your product. Therefore, Agile service lifecycle helps to minimise the risk and optimise predictability by iterative and incremental approach.
Thank you to Iwona Winiarska, our Agile Delivery Manager for another entry of the Agile Blog Series. For previous posts please see our blog.< Back