This article is for anyone considering or preparing to begin a software development project. It intends to show you how to start with a problem-driven approach against a planned or traditionally linear plan. The context of this will be shared through our learnings and experimentation over numerous software projects.
What is agile software development?
Agile software development is a method of building software that focuses on delivering value often and early. It has gained popularity over the past 15 years and for many companies and software projects, has become their default methodology. The key benefit of agile is that it enables you to test and validate the software early - ensuring that feedback is fed back into the later stages of the software build. Contrast this to the waterfall methodology where software is only used and tested once it's 'finished.'
As a Web and Mobile app development company WorkingMouse uses our Way of Working as a functional guide on how to deliver Agile projects. At the start of 2019, we observed a pattern of lower customer satisfaction at the beginning of our scope process (this is where we comprehensively design and document the application to be built).
To address this we decided to experiment in improving our Brief process. This immediately precedes the scope and addresses the solution at a high level. The outcome from this has been a change to our Discovery Workshop process which we call 'starting with a problem.'
Old Approach
To fully comprehend the value delivered in changing the process it is important to firstly understand the old Brief process. The old process involved capturing what we define as a list of 'Epics'. These are large volumes of work that could then be broken down and prioritised into smaller 'User Stories' during scoping. This essentially amounted to an unvalidated wish list based purely upon a single product owner vision. We found scoping from this was taking us too far into a project and its assumed solution.
The issues that came from the old approach were:
Several projects failing to truly capture customers needs and provide a viable solution to their end-users.
Differing expectations between epics at the Brief stage and epics at the Scope stage.
Scoping and building unassumed and unvalidated work.
Larger scope which ultimately takes longer, leading to larger estimations, projects and deliverables.
Scoping teams felt they were fleshing out a wish list into a product instead of consulting to solve real problems.
To re-align expectations and remove assumed work, we proposed and completed an experiment to change the brief process.
New Approach
Taking inspiration from successful methods (see inspiration below) we pivoted the briefing stage to focus on the customers problem, then their solution.
What this means is that instead of sitting down and formulating a list of 'Epics' the team works with the customer to define a problem statement that when solved, achieves their business goal.
For example, this could mean:
Problem statement: "My users need a way to better track their job progress within my software"
Goal: "Increase productivity, team happiness and managerial tracking"
Moving to this methodology we create a frame of mind for the scoping stage where everyone involved is formulating different approaches to solve the problem. Rather than spending most of their time turning those 'wish-list' items into unvalidated solutions.
The Process
The Discovery Workshop is used to learn and understand: what the customers business goals are, what their goal is for engaging with the customer, what their criteria for success will be and what problem/s they are hoping to solve with this project.
The team will map out what the relevant user journey is and what steps the business takes to complete the desired outcome so everyone has an understanding of the current process.
We list all of the problems/opportunities we have to solve using software.
Team members help the customer focus in on the most pressing problem that they can solve early on to validate.
We ask why. This enables us to remove any abstraction or assumptions through their domain experience that customers may have placed into the statement.
After this, we rapidly iterate the problem statement again until it satisfies all relevant stakeholders and the business process.
Finally, we quantify the problems business case by setting a goal where we can measure value.
If the customer is coming with a ready solution or a backlog of stories then the team should still focus in on finding the first problem and explain how the scoping team will proceed with identifying a solution from that. It is also important not to get bogged down in any solution generating this early on. Ideas can be recorded to be tested but it is not about forming a solution...yet.
The objective of a brief is to make sure the client and WorkingMouse can facilitate a good working relationship and build trust (which is the foundation of any agile project). WorkingMouse is looking to ensure that the customer understands how we work and what steps/stages we undertake within our Way of Working.
The whole idea of agile software development is to not rush to a final solution. Over the years this has become the norm during the building phase. However there are still plenty of examples of projects that have rushed to start building. By firstly starting with a problem and using that to discover a solution we can create a framework for the design phase of an agile project.
Inspiration
We do not profess to be the masters of design thinking. We learn from and adapt learning to our process. Therefore it is important to highlight relevant resource we took inspiration from for this.
'The Design thinking playbook': mindful digital transformation of teams, products and services, businesses and ecosystems/ by Michael Lewrick, Patrick Link and Larry Liefer, published by (2018).
'Sprint how to solve big problems and test new ideas in just five days' by Jake Knapp, published by Google Ventures.
Outcomes
Through this process, we found that our customers are more open to change. Scoping is shortened with smaller deliverables, smaller estimations at the end of the scope and better software for the end-users. We hope you can use this approach for your software projects. Alternatively, contact us to see how we can use the process to help you build software.
