Can User Personas Support Adoption of Agile Principles?
A few months ago, I opened Pandora’s Box and unleashed user personas on the team. Despite the challenges around their adoption, it has had the intended effect of encouraging developers to start talking to our users, and identify the problems that our software needs to solve.
Nevertheless it has not always been sunshine and lollipops. Enforcing standards can lead to backlash when the value is not immediately clear. Since personas are documentation, it can be seen as introducing unnecessary bureaucracy. Here I attempt to assess persona agility against the Manifesto for Agile Software Development, and highlight the value they bring to our processes.
Documentation Over Working Software
One concern initially raised is that the burden of additional documentation doesn’t fit the criteria of prioritising working software. Working in a regulated environment results in a lot more documentation than other organisations. We feel the need to justify every decision. The burden of writing said documentation is often imposed from top down, resulting in frustration for programmers.
Developers tend to exhibit an extreme hated for documentation. From university and beyond into the world of work, the sole purpose of engineers is to write code. This pesky documentation simply blocks them from carrying out their raison d’être.
When determining the key value of encouraging greater user engagement, the question I had to ask myself is how to reduce the overhead. By providing a concise template in a bullet point format, we allow for rapid generation and change of these personas, without overburdening developers. That way they can focus on building working software, but still with users in mind.
Dreaming of Electric Sheep?
Collaboration with users is important, so much in fact that customer collaboration is a principle in the manifesto. It is a key pillar, especially in my role where I’m actively developing products for colleagues in the same organisation. To build the right thing, and maximise value, we need to understand our users and what they do. Furthermore, we need to empathise with users struggles and identify the goals rather than just the process.
Processes are inherently complex, especially in the corporate world. Humans make it so. The processes are often outlined in expansive process documents that read more like War and Peace than The Hungry Caterpillar. This is another reason documenting the user interactions we have in the search for value all the more important, albeit in a far more concise format.
Who Are You?
As outlined previously, the goal of the template was to help developers integrate personas easily into their everyday cycle. The template listed only key headings to identify their key daily tasks, the challenges they face, and the systems they typically use. My aim was to summarise the key attributes of a user’s day to day function, without having the profile sound like a dating profile. Personal attributes are therefore limited to role title, location and photo.
We do want to encourage empathy, but us knowing that Jane Doe is 27, loves dogs and spends their weekends binge-watching Netflix doesn’t achieve empathy for how they use our systems. It may help you build a relationship by discussing the latest episode of insert latest flavour of the month here. However, knowing that they spend 1 hour everyday pulling data from our systems into a spreadsheet to transform the data into a another format should allow us to focus on not just the user, but their interactions with our systems. Only then can we evolve our software and optimise these interactions.
People change as they adapt to their environment, even in work. I’m definitely not the same mousy optimistic developer that joined the intimidating corporate technology world just under 7 years ago. I’ve worked on many systems, with differing technology stacks. I’ve evolved as a person outside of work as well. Those insights bleed into the software I build and the work that I do.
This effect is not just limited to technology, but every aspect of an organisation. As people change, they make their mark for a while and then leave. Processes change depending on the ideas thrown into the proverbial pot. Understanding of processes definitely does fluctuate, and it is OK to admit you don’t always know what an individual does 100% of the time.
Recently I’ve had a reminder of that experience. One process I’m currently analysing has changed again a year later, and as of this week may do so again. The goal is still the same, but the execution has changed in every region.
This process has evolved for several reasons. The initial change was where the information was being stored. It was not necessarily the realisation that the data is there in the system, but that the execution time was becoming exponentially longer as each day was documented. Personas allow us to adapt to changing user challenges. Responding to change is a key principle of the Agile manifesto. When thinking of change, we should consider change in people, processes and software. Personas definitely help support Agile development, in a world of constant change.
Thanks for reading!