oneux | designing experiences

agile: discovery phase

It's good to know that agile experts agree with the need for an initial discover phase for a typical agile project. I have just completed a scrum master course with Mike Cohn and one of the questions raised as part of the course was: "Is there such a thing as an 'analysis sprint' where requirements are pulled together?" The response was a clear 'Yes' with a few clarifications, to which I fully agree:

• It is best not to call it a sprint as it may take longer than one sprint. I personally prefer 'discovery phase' but 'analysis' or 'definition' are equally good. As I mentioned in previous posts, 'Sprint 0' betrays an attitude where analysis, research, and discovery are seen as secondary to the main development work.
• Preferably, it needs to be part of the overall agile project and run in an agile fashion. So, daily stand ups, product owner involvement and time-boxing still apply. I prefer this to running it as a separate project as making it part of the bigger project highlights the contributions that a dedicated discover phase can bring to the project and the end deliverable

There you go the guru has spoken: researching and understanding users is expected to be part of the agile process.... only thing left is try to sell it to clients.

let's not get hung up with the full UCD process

or

"Let's not do the full UCD process",

"Two hours with users is a bit excessive, isn't it?",

"We will define the workflow and they [the users] will confirm it".

"We are building something new so we do not need to talk to them [the users]"

These are some delightful comments that were directed my way from, not clients, but team members when I dared suggest that we need to observe and talk to users of a back-end system to understand their motivations, goals, and behaviours. The excuse was that we had done enough business analysis to understand the workflows and that further exposure to users was unnecessary.

If nothing else, these comments reveal a fundamental lack of understanding of how UCD works and the value it adds to projects. Business analysis while concerned with workflows, business rules, and systems, it fails to identify people's motivations and needs when it comes to exercising those workflows. BA, while immensely valuable in getting any system properly working, is user agnostic in a sense, as users feature only as actors. UCD on the other hand, focuses on the human side of the system, concerning itself with the needs, motivations, and current behaviours of those who in one ay or another interact with the system.

So, what do you do when faced with such opposition? You gently ignore those comments, begin a UCD process and in the process educate the team. Well, that is what I am planning to do...

why User Centred Agile?

I mentioned in previous posts that Agile Usability is a compromise where the end product suffers. Here, I’d like to expand on that and argue the need for a User Centred Agile approach.

What is out there
As stated by other commentators, in an agile environment, UE is bolted on at the beginning of a project in what is called ‘initial requirements envisioning’ stage that typically takes place at sprint/iteration 0. It is generally suggested that this stage would last from a couple of hours up to two weeks, depending on the size and complexity of the product.
During this initial stage the UE team is expected to identify ‘high level’ requirements and get a ‘good gut feel’ of what the product is about. The focus is on getting something that is ‘just barely good enough’ at this stage and get the process going.

Objections and an alternative way
Existing arguments fail to understand that a user-centred approach will need to include user insights and requirements, which certainly cannot be collected and analysed in a couple of hours. Meeting and observing users is crucial to the design process and cannot be underestimated. Discovering user and client needs naturally comes at the beginning of the project hence iteration 0 is a good idea, though I think ‘0’ gives the wrong message as clients may see it as an unnecessary step. During this discovery phase UE spends time understanding what and how the product will behave and look. A ‘good gut feel’ is simply dangerous as you cannot trust it to base cost, time, and resource estimates on it. Though some of the requirements can change as the project progresses, the discovery stage will help identify and understand the majority of them minimising the risk of any overruns.

I will argue that a well planned and executed discovery stage will help Agile do what it can do best: produce working software within relatively short periods of time.  Having a good understanding of what the final product would do will empower developers to innovate in their approaches and not merely produce a good enough result.

agile and user experience: discovery stage

Back to a current favourite of mine: Agile and UE.

Here is the issue: Imagine a client asks you to provide a proposal and costs for designing and building a piece of software to a fixed deadline. They provide you with some high level requirements and asks you to get back with a plan. So, what ussually happens is that you go back with an estimate for the project based on the client briefing and upon client sign off you get started on the project. A few sprints further down the line you realise that you won't meet the deadline because the list of requirements has expanded after  closely looking at the client and the user needs.This is a situation that you really do not want to be in. It involves re-negotiating the project scope, revisiting the amount of resources available, and generally risking damaging the relationship with the client.

So what do you do?

• When scoping the project you get the client to commit to an initial discovery stage (not sprint 0) before you get back to them with a clear and accurate proposal
• During the discovery stage ( 2+ weeks depending on the project) you conduct qualitative user research and collect both user and business needs
• You deliver the following:
  • Personas
  • User Journeys
  • (Agile) User Stories
  • Interaction principles
  • Initial IA

The benefits?

• The discovery stage helps you understand the amount of work required and you can confidently produce estimates you can trust
• The client sees the benefit of the discovery stage
• UE has the time to lay the groundwork for the design and built while developers set up the environment and get ready for the hard work ahead of them.
  

putting the case forward for User Centred Agile

I'd like to put forward the concept of User Centred Agile, an approach where the principles of agile development operate within a larger user centred environment. For example, while developing user stories to help prioritise development still remains part of agile, these stories are the result of qualitative user research and not the result of stakeholder workshops. Another example: while UE is represented throughout the project, there is dedicated time to conduct sufficient qualitative user research.

Why User Centred Agile?
The majority of references to UE and Agile I came across, talk about Agile Usability; they describe how user centred design can be adapted to work in an agile environment. The term 'Agile Usability' at best suggests a compromise, not just for Agile and UE practitioners but more importantly a compromise in the user centricity of the final product / solution. 'Agile Usability' suggests a cut down version of usability - already the wrong term- to fit in agile timelines. Agile Usability appears to be synonymous with discounted usability.

One of the main arguments coming from commentators when discussing the relationship between agile and UE is to bolt on 'usability' at the beginning of a project to 'explore interaction issues'. I will go through the reasons why this is a compromise that will affect the quality of the end product in future posts. For now it is enough to say that reducing user centered design to usability and interaction issues removes the possibility of innovation in agile environments.

agile user stories: what works

So what is good about user stories?

• They help bring user needs to life. They focus our attention on specific scenarios of use
• They expand on personas
• They help developers prioritise their work
• They introduce business and technical requirements in the form of conditions of satisfaction and constraints
• The INVEST acronym is a really good set of guidelines for writing effective stories.
• They focus on user needs not UI elements, though it is argued that UI elements can feature as the project moves on. I guess that is fine if user stories refer to elements already built and therefore need to be taken into consideration.

I will definitely recommend using user stories. They are more focused than user scenarios and make the leap from conceptualising a solution to actually building it.  I am still really concerned that a lack of user insights prior to writing user stories could make the whole exercise pointless.

agile user stories: objection #3

Agile suggests we stop talking about users and start talking about user roles. I will agree with the first part of the sentence: we definitely need to get away from talking about an elusive and generic user and be more specific, I am just not sure that user roles is the way to do it. Instead, I would argue we need to focus on behaviours not roles.  A user’s role in relation to a product or service may give us clues as to what they may want to with it, but it tells us nothing about how and why they may want to do it. User roles cannot effectively express goals, needs, attitudes, and behaviours. Enter personas, a proven tool to communicate those intangible, and subtle characteristics that will be the building blocks of a user centred and innovative solution. Personas offer an answer to the 'generic user' problem by helping focus the design to those who matter. Mike Cohn's objection is that Alan Cooper suggests we create only one persona, which is a slight misunderstanding; in fact you begin we a few personas and then narrow them down to a primary persona while you retain the others as secondary ones. Another problem with user roles is that they lend themselves to stereotyping.

agile user stories: objection #2

Product owners represent the users. This is a central premise of the agile approach. Probably a wise one as developers would not want to own the user and would need guidance by the people who run / own the solution that users would use / purchase, etc. passing on, or probably sharing the responsibility of knowing the users makes sense. However, more often than not, product owners are not in a position to understand the users. They may have marketing segmentations, sales stats, feedback forms, anecdotal evidence, personal experiences but all this information relates to exhibited behaviour not insights to users needs and goals that can only effectively be identified by qualitative user research. Only then would the product owner and developers be able to fully understand the user and stat building user stories.

agile user stories: objection #1

User stories are a tool to ensure that requirements are communicated effectively between the business owner and the developers, and also to ensure that, as Mike put it ‘resource allocation becomes a shared problem [between the business owner and the developers]’. User stories are effectively a mechanism by which to ensure that developers have all the necessary information before they start building. Well, what is wrong with this? Absolutely nothing, I believe developers should be given all the right tools, information, and privileges so they can build working solutions. However, the problem lies in the fact that user stories are at best the output of brainstorming sessions and not the result of user research. I am struggling to understand how a group of developers and business owners can identify and list user needs in the form of stories without previously having done qualitative research. The agile answer is that project owners understand and own the users, which leads me to objection 2 

agile and user experience: user stories

I return to a favourite subject of mine: Agile and UE. In a previous post I was full of hope that user stories would instill some user-centricity in the agile process. Today I had the chance to find more about them. I just returned from a full day’s course on ‘Effective User Stories for Agile Requirements’ run by Mike Cohn, founding member and director of Agile Alliance and Scrum Alliance.
I went to the course hoping to find out that user stories are the output of user research and a way to express user needs to the developers building the solution. Unfortunately I found out that instead of being user centred, user stories are effectively developer focused.
I will explain all my objections and agreements in separate posts so I do not bore you all with a long tirade.

agile and user experience: bridging the gap 1

**post not finished

I've been looking around to see what other opinions are out there about combining or integrating agile with user experience and I was surprised to see how weak some approaches are. It is as if UE needs to tiptoe around developers in case they get annoyed,

They focus on

• doing just enough modeling
• supporting developers 'do the simplest thing that could possibly work.'

In one article the speaker argues that unlike building a house, building software does not obey the laws of nature and that you can build the attic before you start on the basement. Absolutely true, however, you run the risk of building a monstrosity unless you have a blueprint and in the world of software development that blueprint lies within user experience.

agile and user experience: user insights

Back to a subject that I am currently interested in: whether and how UE fits in agile approaches. In previous posts I argued that Agile approaches by definition do not include UE and I am still standing by this until I find otherwise. It is interesting that Ken Schwaber, one of the two co-developers of the Scrum approach makes no mention of UE when talking about the roles involved in Scrum. He mentions the scrum master, product owner, coders, analysts, designers, QA, documentation people, but no user experience. interestingly user needs are 'owned' by the product owner who according to Ken 'represents all customers' and that would include both the client organisation and the end users of the product.
For Ken, the point of the Scrum process is to protect those committed in delivering the product from outside influences such as those coming from stakeholders as well as users.  Scrum is about protecting what Ken calls the 'pigs' by not letting the 'chickens' jeopardise the process. There is no dedicated process whereby user needs are researched, documented, and taken into account. Admittedly there are the user stories that the development team puts together, but I will come back to that in a separate post.

It appears that producing working software within budget or time is more important than producing user centred products.

agile and user experience: definition of 'done'

Like other UE professionals I will argue that working software means little in terms of user experience. A piece of software or a website that works technically, does not necessarily mean that users would either want or be able to use it. Agile methodologies' focus on technical efficiency is simply not enough to guarantee a user centred product. There is a need for an explicit requirement for the product to meet certain 'user centred' standards, and by that I do not mean usability standards but user experience requirements, that is ensuring the product successfully supports users' goals while also helps users immerse themselves in the brand.

Each agile project is required to offer a definition of 'done', that is, to describe when a product will be considered finished, done. Scrum masters are expected to work with their teams and list all the requirements the software will be measured against at the end of each sprint as well as at the end of the project. If the code meets the requirements then it is considered done and it taken off the backlog list.

This definition of 'done' is a window of opportunity for the UE member of the team to make sure user experience requirements are included in the definition thereby ensuring the product is not simply functioning but also offers a compelling  experience.

            

       

agile and user experience: initial thoughts

I've been searching around and came across a number of articles talking about the uncomfortable relationship between agile and user experience. The consensus appears to be that though challenging, user experience can be incorporated into agile practices and help produce not just working software but also usable ones. Of course it is possible, user experience professionals will make sure the user is heard regardless of what development methodology is used. To me the issue is not whether UE can be incorporated into agile, but how can UE transform agile approaches so improved user experience is part and parcel of agile approaches.

Note that innovation does not feature when talking about agile but references to 'the simplest thing that could possibly work' are common. Well, this is probably fair because you cannot possibly innovate without real insights into user needs and behaviours. Anyway,

• Regardless of how UE can be bolted on to agile we need to remember that agile is a software development methodology and all its practices, tools, artifacts are designed around helping developers build working software: Producing working code is at the core of agile, user expedience is not.
• Agile approaches are supposed to make the developers' life easier, the processes used are designed to help developers successfully build and test (note not necessarily user testing) small pieces of software in small periods of time thus minimising risk. In that sense, agile approaches are inward looking.
• Focusing on customers is not the same as focusing on user. 'Customer' in agile is quite a vague term that incorporates the client, owner of the product to be built, as well as the final user base. As a UE practitioner I would argue that identifying and prioritising the end users is critical to building successful interactive products.
• Agile passes the usability bucket over to what is called the 'product owner', which in most cases would be the client, internal or not, commissioning the work. Agile, here, makes a  dangerous assumption, namely that  companies have a clear and deep understanding of their customers' needs and motivations. Furthermore, assuming that there is someone at the client organisation that 'owns' the customer  - which would normally mean they own and manage customer segmentation based on market research, not user research, - it is not likely that they will be the 'product owner' .
• To end my thoughts on a positive note,... User Stories, well there is something that can make agile uer cnetred... let's see...

More thoughts soon...

agile and user experience: the questions

Agile, being a methodology that uses iterative techniques and relies on people should work great with UE. But do agile approaches and UE work well together?

• Where and how does user experience fit in an project following an agile methodology?
• Why is there not a dedicated stage for user research?
• Is sprint 0 when you do collect user requirements? How do the spikes fit in?
• How do you ensure usability in a methodology that is not using prototypes?
• What are the benefits of working in small cross functional teams?
• How effective are sprints for ensuring user needs have been taken into account in the design and built?
• What is the UE involvement in Scrum?
• How do user stories differ from personas and user journeys/ scenarios?
• Are user stories based on requirements?
• How effective are user stories?
• Do developers have the skills and insights to create user stories?
• Why is the product owner the voice of the customer?
• Are UE professionals part of an agile team?
• If part of the team, what is there role?
• How can a UE improve the quality of a sprint output?
• Where does usability testing fit in? at the end of each sprint? just before release?
• It appears that agile methodologies are inward looking while UE is outward looking
• Do agile methods foster innovation?

Over the coming months I will be thinking about these and more issues and writing my thoughts on agile and user experience. All your contributions are welcome.