There are lots of different frameworks for how to run projects so they are ‘agile’. Tim Beattie takes us through some principles that will help you no matter which specific ways of working you choose to implement.
Don’t Make Assumptions of Simplicity
When working through a Discovery phase, you’ll be doing activities such as empathy mapping, scenario plotting and user opportunity spotting. These can then help you quickly get into an iterative delivery process like Scrum – producing products against an agreed backlog of features and stories.
However, a common mistake is that, through this process, you will miss a particular piece of the overall puzzle. By working in small increments, and presenting to stakeholders regularly, you will be more likely to catch any mistakes quickly. That said, make sure that you are casting your Discovery net far and wide, looking for areas that you don’t fully understand.
If an area of your product feels like it’s simple, it’s quite likely that you don’t fully understand it.
When Prototyping, Don’t Just Look at the Front-end Product
When teams are prototyping a new product or service, they usually start with the customer-facing screens. Discovery, design and build are focussed on understanding the end user and what problems we need to solve for them.
However, most investors are at least, if not more, interested in the administration side of your product. This is where the costs and revenue will likely be generated, so it needs to be considered. How is your service going to be manage? Where are the efficiencies going to be created? Is it even something current employees will understand? These are all questions you should be asking from the outset.
If you’re prototyping something, always discover and then design how it will be managed.
Focus on Outcomes
Measurable outcomes that can drive your work will help you deliver value for your users and business, faster than any agile framework, process, or methodology. As you are going through a discovery process, create a list of ideas and outcomes that you are going to work towards in your delivery. This will align the team and get you working on stories that actually add value, rather than lead you down rabbit warrens.
The Mobius Loop
Rather than yet another framework for agile, this is a broader set of approaches that can be picked up and put down as you and your team see fit.
- Discovery Loop – why are we here, who are we building this product for and how are we adding value? The answers to these questions should form the basis of the target outcomes that you move towards.
- The Options Pivot – this is a list of activities that we can research or experiment with, which we believe will help achieve our outcomes. This might be a backlog or list of features, depending on your way of working.
- The Delivery Loop – here we start building things, creating features, carrying out activities etc
Once you have run through the loop once, you have an important choice to make – whether you continue to progress through delivery, or if you need to go back to Discovery and a find or pick up a new set of options.
The way to do this is to measure whether you have reached one of those target outcomes. If not, then you need to keep delivering. If so, then start again and find out a new way forward.
Being agile doesn’t necessarily mean adopting any particular set of practices – it means being able to find and deliver small pieces of value as quick as possible. The heart of that is in thoughtful discovery, assessment, and delivery.
Comments 0