An Agile Persona

by Gordon Baisley

When you boil it down, the Agile approach focuses on the value of the software to the customer, a commitment to responding to feedback all through a project and a certain impatience with excessive documentation. It’s a mindset as much as a methodology, and one that best suits people who accept that constant change is a given – the emphasis has shifted for good away from finite software products to ongoing development in an online world.


Because it judges success in terms of the value projects deliver to clients, persona building is often used by Agile practitioners to create a fuller picture of requirements, needs and expectations. More than that, building a 360 picture of clients encourages teams to work heads up (looking at results) rather than heads down (buried in the documentation).

So it seems fitting to try and build up a picture of an Agile persona. What are the individual qualities, inherent or learned, that will help drive the Agile approach?

In no particular order:

They need to have focus

I’m going to say “focused” rather than just “customer-focused” because Agile people have a lot of potential distractions. They need to look outside their own disciplines, they need be able to listen to others without forgetting what their role is, they need to involve the end-user at every stage at same time as being committed to keeping the project on track.

It helps to be practical

The Agile persona is supremely interested in delivery so has to be practical.

Meeting Paul Gerrard recently he put forward a great proposal: “The only question that matters is “Does anyone have a better idea?” It seems the perfect summary of the constant desire to move forward and a mindset that challenges the futility of procrastination.

If traditionalists want to conform to requirements, the Agilista (!?!) does whatever is needed to ensure that customers are satisfied and software delivers value. So while a traditional approach might rely on a Test Strategy or Quality Plan, the Agile approach is to prioritise working software over documentation and trust in the process to build in Quality along the way.

Be ready to adapt

Agile puts greater emphasis on responding to change than following a plan, so flexibility and adaptability are vital qualities. Internally, teams should be constantly on the look-out for ways to be become more effective, and adapt accordingly.

Stay inclusive and responsive

In an Agile project, people generally find better ways to communicate than via documentation and if the team is focusing on delivering value for the customer, then it makes sense to involve them in the project as much as possible. An ability to ask direct questions and respond to direct answers is a must.

Take responsibility

As well as being responsive, Agile projects work best if everyone buys into and feels responsible for the project. Within teams, the old divisions should dissolve so everyone takes a hand in ensuring that Quality is built in, for example, rather than exclusively the preserve of the Quality Assurance or Test practitioners on the project.

Learn tact

There are more ways than one to skin a cat and Agile is a mindset rather than a rule-book. A greater emphasis on interactions and collaboration than on documentation means process will be based on shared understanding rather than a reference book. This in turn means process can be adapted as quickly as interactions happen. This may go against the grain of established Quality practitioners and some, especially those that are silo-bound, may need coaxing out.

Be collaborative and communicative

Agile’s dynamic and collaborative approach sets it apart from other methodologies. This is fundamental to its success rather than a bolt-on, so internal structures with predetermined rules and roles may need to be looked at. But the benefits are wide-ranging. More internal conversations spin out into better communications with clients, leading in turn more responsiveness when requirements change – and they will!

These are the qualities we look for. What others do you see that should be included?