Combining and Matching Research and User Testing into Agile Development

Agile development is on everyone's lips, because of “speed to market”. Agile development appears to be the most compelling method for businesses who want to minimize expenses. When “speed to market” is on everyone's lips, in everyone’s head and focus, quite quickly you get into situation that the leaders and also the team neglect, or try to push away, or hastily cobbled a research together. As it is perceived as a negative impact on the development’s timeline. 

When this happens, teams can waste months of work building a product that customers never use because it doesn’t provide any value to them – do not provide utility, respect the existing work process or manual or automated operating procedure.

I see user and usage centered research – covering Customer Experience CX, User Experience and Design status quo and trends as essential in agile development because it:

  • Bring light into the ‘darkness’ – defining and clearing up the task and problem from a various point of views – company, users, competitors, market and trends
  • Illuminate the future or possible future – clarification whether it is worth to go that way or do we need adjust the direction 
  • Helping everyone on the team to stay focus and having user’s tasks and user profiles in mind when the team discuss, develop or test features or solution 
  • At the end it minimizes wasted work by regular and ongoing feedback rounds

At the beginning of a development, of a new project or even of features often we have a problem statements seen as an assumption. But quickly it is taken as given and carved in stone. And it becomes often quit quickly a statement.

Often these problem statements are only observed from the perspective of the business suits, and not real users – often they are driven by “we have to meet certain KPIs” which are all too often defined by annual personal goals or team goals and less driven what is really needed to provide value to the company or the customer and users – But I firmly believe that a good business or a good service meets the value of users, of customers and then the values of the company  - and by meeting these values the company will make profit and money – and then it becomes visible in “certain KPIs”  and vice versa.


How can you match the needs of research and agile development?

First of all the team should questioning the ‘given’ initial statement. Research should in best case identify problems from different perspective and as much sides as possible, but also only as much as really needed and suited to the project. Sometimes you get the point that the initial statement was good and right. 

But what is much more the case - the team will get to a new problem statement that has been validated with users and a conceptual solution that focuses on delivering real value to the user. 

Already this is a huge step for many teams. But there will be still many assumptions about the solution. These assumptions about the solution will shape the research’s questions and also the team will address them each time during the development. 

Having the time and the resources have to be part of the or a release plan.

Once you start to design and to develop – research will make a step back and user and usability testing will come into the play.

Testing the concept, first UIs and UI flows is essential for a good solution.

While developers are coding to address functionality, a stable data flow etc. designers continue prototype testing to refine and revise the solution. Insights gained from prototype testing help drive modifications to the backlog.

Once self-contained or sovereign UI or task flow are completed, teams, researchers and designers can push their click-dummy or even the solution out to a small sample of users. 

It is important that teams be comfortable releasing solutions that are not perfect because we are most interested in learning if this product is valuable. But if we learn that it is not, we will have saved ourselves the time and effort it took to build a perfect application – and then discover or get shocked by the reality.

While failing may seem like a waste, we learn what our customers want and need. Agile is a practice grounded in learning, but teams need the support to do so.

Project lead and project management need to integrate the following thinking to their practice ...

Scheduling some time in research – discovering and defining and clearing up the starting  point the aim and goal, questioning the problem statement, as it is perceived from initiator, the user, and environment, will ensure the team developing a valuable application, tool or service.





Comments