Working in digital can be challenging. How do you define value? How do we build the right thing? How do we implement business change?
Digital professionals working in government have a range of methodologies and standards such as the Government Service Standard and The Technology Code of Practice. These support teams and give confidence that they are building products and services that their users will value.
Here are some principles for teams working in alpha, beta and live phases, which I have observed while working in government digital departments. These principles complement the existing methodologies and standards and enable digital teams to deliver value.
1. Understand the big picture and where you fit in it
Knowing where your product or service fits into the bigger picture is important. It helps you understand what your dependencies are, where there are opportunities, and how you can save time and effort by reusing other team's work.
2. Keep it small, get it to users, learn something, repeat
Agile has become a buzzword in the digital industry and, although its origins come from the software manifesto, it's become synonymous with being able to deliver change quickly. As a headline principle, you should try to deliver small chunks of value to users quickly, as often as possible, learn something, then repeat.
3. Create short feedback loops
Creating short feedback loops across technology, users and stakeholders enables your team to deliver change based on user’s needs. From a technical perspective, you want to build resistance-free pipelines direct to your users. It’s also important to close the feedback loop using user research and business analysis.
4. Turn assumptions into user needs
Testing user needs and with short feedback loops will enable your team to build value into your products and services. You should aim to test assumptions and turn them into real user needs if you can, in order to give you confidence that you are building the right product or service.
5. Fail fast
Let’s get this in the open: failure is a good thing. We learn more from failure than we do from success. If you’re building something, aim to know just enough to have confidence you can test an assumption, turn that assumption into a user need, and learn something.
6. Identify risks as early
Aim to Identify risks early and mitigate the highest risk first. Thinking about services end-to-end can help identify risks, for example, if you are collecting data from a user, where is that data stored? Do you need to integrate with a legacy system? What business logic does that legacy system use to store the data? What events and triggers in the legacy system use that data?
These are some of the values and behaviours that I have seen help teams to overcome challenging problems and deliver value. These principles are constantly changing, and I would love your feedback to help iterate and improve them.
Please leave a comment if you have any examples, challenges, or suggestions, or reach out to me at firstname.lastname@example.org