Developing apps and websites in an Agile Manner
Developing apps and websites with teams of creatives can be a challenge, Samuel Fry explains some of the potential pitfalls.
My day job involves working with teams of developers, designers and analysts to build digital experiences. These are usually in the form of an app or a website and they’re often used for internal purposes. For example, one week I might be working on a search tool and the next week its booking tool.
At the beginning of these projects it is hard to know everything. Most of the time it is impossible.
Despite this, it is at the beginning of projects like these that teams are asked a lot of questions. What will you build? What do you need to build it? Who do you need to build it? Then finally, how much will it cost?
You can make assumptions about the project, of course. Typically you will remember that last time a project was done like this the user wanted X, it took Y many days and Z many people to do it. Your assumptions might be sensible, they might be close, but they are unlikely to be 100% correct. You know this and the company that is paying you probably knows this too. However, it does mean the project is full of many wrong assumptions from the beginning.
So, how do you run a project based on assumptions?
Waterfall Methodology Steps
The traditional way of developing software is in a “Waterfall” method.
The concept behind this is that every step is done in sequence. You start with a concept, analyse the problem, design a solution, build that solution, test that it works, release it to your users and maintain it. The term “Waterfall” is widely used as it refers to diagrams where one step leads to another.
The term is sometimes credited to Winston Royce who published an article called “Managing the Development of Large Software Systems” in 1970. Royce describes six stages to the process:
System and software requirements
This process was created for the development of large, complicated systems and the idea is that you do not start a new stage until the previous stage has been completed and verified.
The benefit of developing software in this way is that you have very clear milestones in the project and you can document decisions against where they were made in this process.
The problem with this process is that it is not very flexible. What if you design a solution and then find out that something has changed? Perhaps the users need something different, or another system that your solution relies on has gone.
Agile Project Methodology
For this reason, many teams are starting to work in an agile manner. They accept that they do not know everything at the beginning of a project and that things are likely to change while they are developing a solution.
There is a whole manifesto behind agile which focuses on enabling the team to be empowered to make decisions, working closely with customers, building software quickly and responding to change.
The idea is simple. Rather than designing the full solution up front, you work on one part at a time with the aim to release fully working and tested software on a regular basis. When you work closely with your end users to test ideas quickly, this is ideal.
Being “Agile” won’t fix everything
I’m a big fan of agile, but it does have its challenges too – especially when it is not fully adopted. Often teams say that they are going to work in an agile way but, when you look at how they are working more closely, they are still fully designing their solution up front.
Similarly, some teams will say that they are “user-focused”. Yet, there is very little sign of them observing user behaviours and testing ideas with users regularly. Also, often teams are not working with users but with people who interact with those users.
User Centred Design without users
Let’s use an example.
Our user works at a ticket office and we are building a new application to help them. The problem for the business is that it is taking too long for each ticket booth to serve an individual customer and many customers are walking away without buying anything.
The users themselves are too busy interacting with customers and making money for the business to help the design team. So, instead, some of the managers who allocate the ticket office shifts join to help. These managers speak to the users every day, so they are used to represent the users in a couple of workshops.
The difficulty is that, yes, these managers may know the users pretty well – but they are bound to make assumptions about what the users actually do. They can’t be 100% sure about the pains that the users go through or when they have a “work-around” to complete a task. They might be pretty sure, but you need actual users to really know.
What if that user has told their manager that they are able to record the email address of every customer as and when the customer purchases a ticket. The manager might believe this as they have records of each customer that bought a ticket. But, in reality, the user could be making a note of each customer’s email address on a piece of paper and manually inputting them all at the end of the shift. Quite frankly, it’s hard for that manager to know for sure.
Is Agile faster?
Being an agile team does not automatically mean that a team can complete the work faster. All it means is that a team can respond to change and re-prioritise. Building one feature, such as a login screen, may take just as long, but working in an agile manner means that the team can decide not to build a login screen if it is suddenly decided that it is no longer necessary.
The challenge is to make sure that everyone around the project understands the way of working, so that the team is empowered to work as effectively as possible.
Director, Create Hub
Customer Centric Design
Samuel is the Director of Create Hub. Samuel has a history of working with creative, innovative and entrepreneurial companies such as the creative-business incubator Cockpit Arts, in the Creative Economy team at Nesta, with entrepreneur network Virgin Media Pioneers and as the Enterprise Consultant at University of Bristol. All opinions are his and not those of his employers.