A user centred, Agile approach to software development

By Jay Alvarez on 02 December 2015

In this post I'd like to introduce you to how we at Aptivate help organisations and NGOs develop software applications using the iterative development methodology called Agile and a user-centred approach

Introduction

Building a new website application is a big challenge, particularly for NGOs and International development organisations that we work with. One of the main reasons is that trying to work out what people need is actually a bit tricky. Do you ask just them? Do you just guess? Do you decide for them? And how do you know who they are? Who do you consider the most important, the data entry person or a director? Different people need and want different things and designing a system that suits everyone's needs is a challenge.

A typical request to Aptivate would be:

"We need an easy to use system that ties together our log frame tool, finance system, our website, our blog, our resources library and our training platform so that we can monitor the progress of all our activities and report to our stakeholders so that they can see that we’re doing a good job"

Once you’ve agreed what users want and how a new application should work, you then have the challenge of building it. If all goes well - you have a great working shiny new thing that people find easy to use and they don’t mind spending time on. If it all goes wrong - you have a faulty system that people politely ignore. They won’t tell you what they don’t like about it, they just won’t use it.

I’d like to introduce you to how we go about developing web applications for project managers at small organisations with limited budgets who need to explain to their bosses why an iterative development approach like Agile is better than the standard 'Waterfall' approach typical of many small scale projects - more about Waterfall later...

Some Challenges of developing a new web application

Lets begin by looking at some of the challenges faced by any organisation, big or small when developing a new web based application. We’ll look at these challenges one by one and explain how they can be difficult and how we help clients get through them with a user centred and iterative approach.

1. Requirements gathering - what needs to be built?
2. Planning and Estimation - how much will it cost?
3. Project Management - how is the work going to get done?
4. Testing - how do we know it works?

1. Requirements: What needs to be built?

When your organisation decides to commission a website or application there are a few challenges you face. You know you want to develop something that meets the real needs of your users and stakeholders but you aware that you have a tight budget to do it with. Apart from that it will require some project management time and expertise from your organisation and finally you want to make sure that what you get works as you intended.

Waterfall approach: Complex up-front requirements that don't change easily

• Often features are specified that are later not developed or used
• Changes are avoided as they are costly to implement
• Change of staff during project can cause it to fail due to lack of understanding

Agile approach with User Experience: Flexible requirements adapt to changing needs

• Agile methods provide process frameworks so that that clients stay in control of the project
• Agile projects only produces what it needs when it needs it and change is expected
• A user-centred approach provides meaningful data to base project output on
• Project requirements are small and focus on explaining the problem - not the solution

How Waterfall works

Imagine a waterfall. 

The water at the top topples over the edge and this is like gathering together all the features that have been generated by your organisation regarding the design or development of the application. All of this would then fall like water into a large pool where it would be analysed by another team of people who would then flow their conclusions down again until it reaches the designers who then pass it down and down until eventually a whole pile of fully specified features in the form of a heavy document with hundreds of pages, diagrams and screens to work up based on everyone elses ideas and solutions. It is always assumed or hoped that the previous stage was well executed and that decisions and judgements made were the best ones. This is waterfall. Often features get build then not used because they fail the user tests at the end. At other times features are not developed because the budget ran out due to the cost of making changes to highly complex functionality. 

So here is how Agile works

Imagine a waterwheel.

Imagine the wooden type of waterwheel with cups or buckets that carry only a little water from the top and drop it further down. You could think of each cup as a feature and a single cycle of the wheel like a development cycle. The features which we call user stories are gradually released over time into the buckets where they move around the wheel. At different stages on this cycle they are explored, estimated and designed and developed until they get to a point where they get released into the testing pool where they are assessed for completeness and quality by team members, clients and users. Any successfully completed user stories will go into a new pool ready for release. Any user story that were technically bad get fixed and send up an empty bucket. Any stories that were technically good but didn’t convince the users would be sent back up to the top for incremental improvements in new turns of the wheel - in new iterations. A release would be where a bunch of successful user stories go live for wider testing as a group. Here you can imagine a collapsing floor ready to let all the good code loose on the client when they are all of equal quality. At this point most of the new features should work well but in case any don’t - they can be fed right back into the process for improvement.

User Experience

User Experience (UX) is a body of practice which focuses on finding out what needs your end user - or target audience wants by undergoing research exercises and developing requirements based on the findings.

UX is common in big projects but less frequently found when small organisations decide to develop software. The main reason is that it is considered expensive and is perceived to be complex - requiring great expertise. In fact basic user experience practices can be cheap, quick and simple. User experience methods can be taught easily and incorporated into the client workload during the project. We've created a free user experience discovery activities resource for helping you run some exercises with your team.

At Aptivate we use a mixture of user experience techniques to inform what users need based on budget and time constraints. The amount we do will depend of the project budget but typical user research includes stakeholder and user interviews to start with. We will try to ask users how they currently carry out their tasks and about other issues which impact on their productivity or efficiency as well as try to build a rich picture of their personalities, motivations, concerns and frustrations. We also carry out user story workshops where we bring together existing user research and try to plug gaps by generating 'Personas'. 

Personas are hypothetical characters. 

Personas are often single page documents that profile a fictitious end user. They will have names, job titles and defining statements - statements that tell us what their key goal is. A persona will have a photo or drawing attached to it and short lists of key tasks, motivations and concerns. We will often split into small groups to ‘question’ the persona and to generate user journeys and 'User Stories' from them.

User stories are easy to sort and focus on problem not solution

This process of exploration generates modular solutions called 'Epics' and smaller units called 'User stories'. Epics will often be a list of top project goals and will be a consolidation of bottom-up user led needs and top-down organisation led needs. User stories are typically smaller features and epics are broken down into stories only when needed by the project.

Each epic or user story fits onto a single index card and can be sorted and grouped by the whole team to help make sense of what the minimal viable product should be. User stories are a lightweight way of capturing the essence of the problem from the users point of view together with the benefit that the solution should bring to that particular user. User Stories don’t focus on the technical solution and often they are simply never explored in any depth - because the project dynamic has changes, the goals shifted and these features are no longer required. New ones may be added at any time and will be sorted and ranked in importance for future iterations. These user stories persist until they are completed and tested by users on a regular basis. The client will be in charge of writing them in their own language and for determining when they consider them to be successfully completed or ‘done’. Any further clarification needed when the user story is being coded up by the developer will be dealt with by an email, phone call or meeting. There is no need for heavy, cumbersome documentation. Analysis paralysis which is also very common in waterfall projects is also avoided this way. Change is welcome, expected and driven by user testing. You, the client take ownership of the process and you keep informed all through the process.

Review

At Aptivate we lead our clients through User Experience processes. The final is a set of deliverables which seek to uncover the problems and key user goals. These offer big picture solutions and a stack of lightweight user story cards that define solutions at a high level while reminding everyone of the problems they solve. These are called Epics and will be broken down into solutions only as the epics get prioritised and are always being reflected on and tested.

2. Planning and Estimation - how much will it cost?

It’s a big question and funnily, it’s a chicken and egg situation. You might not want to tell us what your budget is because you don’t want that to influence our estimations but similarly we work best if we know our constraints. Here's the rough picture for waterfall and agile:

Waterfall: Fixing costs on complex functional requirements creates potential for budget creep

• Requests for change can stop development and are costly
• Features are over engineered and often go unused after final testing

Agile: Iterative development allows for adaptive budgeting throughout a project

• Only most valuable features are estimated in any detail when needed by the project
• A minimal viable product is estimated with contingencies and realistic expectations

Review: To summarise the estimation challenge; Counting on an accurate estimation by using a complex specification document can lead to many problems, not least budget creep. Many features that you have said you wanted at the beginning may be developed and will never be used as by the time user tests happen, a lot of money has been spent on developing the features and changing them to work will cost a lot. By using an iterative development process such as SCRUM, estimation is based on delivering a minimum viable product that meets the key user needs but allows the flexibility for continuous testing on an cyclical basis.

3. Process - how is the work going to get done?

It’s all sounding great, we know what we want and we know roughly how much it will cost . If we’re lucky we will also have realistic expectations and expect for the budget to be negotiable. What we don’t know yet is how it’s going to get done. I’m going to describe how projects can often go when they follow the waterfall approach and how we at Aptivate like to work. Using an agile approach which is user centred, iterative and incremental. I will tell you what YOU need to do also. Iterative development might sounds like magic but it does take some commitment from you, the client. It’s not as difficult as you might think though - and it can be a lot of FUN! yes FUN!
We regularly tell our clients how much we enjoy working with them - that’s unusual for our sector.

Agile methods provide process frameworks so that that clients stay in control of the project

• Agile project management leads to trust between client and development team
• Development cycles are organised with a set pattern of activities which help keep pace
• Client project managers are considered part of the team

Easy, shared, online project management tools enable everyone to stay on the same page

• Kanban tool and skype are two key tools we use for self organisation and instant contact
• It’s easy for project management tools to become overwhelming and discourage use

Kanban tool and skype are two key tools we use for self organisation and instant contact

• Regular contact with development team & stakeholders ensures issues are quick to resolve ( Waterfall approach often leads to developers working in a vacuum)
• Agile methods ensure developers talk to clients regularly asking them for clarification
• Regular demonstrations of working software to stakeholders builds trust and confidence

Development is cyclical - continuous user testing of new features informs design and build

• By testing working features in vertical slices, users can test and feedback gets built in ( In waterfall users only test software at the end of the project - often it doesn't work)
• User experience designers work closely with client and team to design or change

Review: The waterfall process opens itself up to many project management headaches where trust and pace are essential to maintaining a steady flow of work and a motivated team. The client project manager becomes an integral part of the development team. By using shared project management tools and keeping the communication flowing on a daily basis, unclear specifications, tensions and misunderstandings can be sorted out. Encouraging developers to lead the client demonstrations helps them take ownership of the user experience as they will care more about how the feature will be used and therefore lead to better decision-making when developing new features. Releasing working software often so that users can test it, allows feedback to be collected early on and can lead to better choices overall. By the end of the project everyone involved feels jointly responsible for its success. Any failings are felt by all and responsibility for them is jointly felt also.

Summary

Iterative development methods like Agile lead to reduced risk of failure in software projects and an increase in productivity and a highly motivated team. Ultimately to a more successful project that delivers more value in less time. 

If you'd like us to come and talk to you or your organisation about our approach at Aptivate - get in touch for a chat.