Here are 5 steps to transform however you’re doing Agile towards Customer-Centric Agile, as I’m calling it. This is “Agile UX” or how we make CX/UX more Agile.
Step 1: Hire Fully Qualified CX and UX Pros to Do CX and UX Work
We’re never going to be Agile if we are giving the wrong people the wrong work. In at least 99.9% of the time, we don’t ask Marketing to write code. We don’t declare that data analysts can do manual QA testing after a few hours of training. We hire qualified marketers and QA testers when we need them.
Take a look at the job listings at your company. Chances are your “Junior” UX Whatever required 1 year of experience, maybe 2 years of experience. Yet when UX is spread thin, someone is SURE that anybody at our company can “do the UX.”
Let’s say that again.
- When CX/UX wanted to grow the department and add qualified people, we’re often told there isn’t budget or we don’t really need that.
- But when UX work isn’t getting done due to a lack of qualified people, someone decides it’s “good enough” to give the work to unqualified people, teammates who don’t have 1–2 years of UX work experience. They wouldn’t even be interviewed for a UX job at our company.
- Why do we need 1–2 years of experience when someone is applying but if they’re already a non-UX role at our company, we appear to have no standards?
Step 1 to being Agile is hiring qualified people and having standards for who does UX work. We have these standards for other roles. We have these standards for our own CX/UX candidates. Let’s please stop pretending that our work is easily “democratized” when no other domain is a democracy. Product Management and Engineering aren’t democratizing.
Let’s stop pretending that UX is as easy to learn as pivot tables. CX/UX aren’t quick upskills. If they were, we wouldn’t demand “entry-level” candidates with 2+ years of experience. If UX could be easily upskilled, we could hire people with no experience and train them in hours.
Step 2: Hire CX/UX at a Nearly 1:1 Ratio With Engineering
At many companies, a UX resource is assigned to more than one project. This means that a team of 6–10 Engineers is waiting for a fraction of one person to do research, IA, IxD, prototyping, testing, and sometimes visual design too.
This makes no sense. This is the main reason why we hear that UX isn’t Agile. Oh, UX is SO SLOW because it’s going to take that UX person SO LONG to do that work. Yes, it surely will when you put 1 UX practitioner or 30% of 1 practitioner on the team.
The solution here is to have a nearly 1:1 ratio of CX/UX to Engineers. My model calls for:
- A paired CX Architect team. Two people proficient in information architecture, interaction design, and prototyping. This could be two seniors (or higher). This could be a senior and a junior or apprentice.
- Three CX Researchers. Three people proficient at generative, evaluative, exploratory, and other types of research, mostly qualitative. This could be one senior (or higher) and 2 juniors or apprentices.
- When should these sub-teams have more leads/principals/seniors and when is it OK to have people with less experience? It depends on the company, project, domain, etc. I can’t say for sure, but I would like to see more talented apprentices and juniors given a chance and direct support and coaching.
- This also means that we have specialized jobs with different responsibilities. Developers and QA feed each other. Researchers and Architects feed each other. We improve Agility when we let specialized workers focus on tasks in which they are proficient and efficient.
- Even if you hired CX/UX generalists who show talent and skills in research and architecture/design, we could still be more Agile with 5–6 of these on a feature team versus the sole practitioner (or fraction thereof) that teams tend to have now.
Let’s visualize that. Imagine a larger project that needs serious research and then serious design. This isn’t a small fix. We’re estimating 370 hours of research work and 210 hours of design and iteration. This isn’t far-fetched or uncommon. My company has done a few of these in the last couple of years.
- If we put one Jack of All Unicorns on that, it would be 19 weeks of work for them. There is no way anybody will give you 19 weeks to have something ready for Engineering. You will hear that you are not Agile.
- But what if we use the Delta CX team model and put 2 Architects and 3 Researchers on it? The researchers can probably get that work done in around 4–5 weeks depending on how many useless, time-wasting meetings you make them come to (rather than giving them time to do their work). Two architects should be able to get 210 hours of work done in around 4 weeks, awful meetings permitting.
- This means we would need 4 two-week sprints to get a pile of stuff into the backlog. When Engineers want 4 two-week sprints, nobody calls that Big Engineering Up Front. Let’s normalize teams of any type doing great quality-over-speed work in “reasonable” numbers of sprints based on the size of the stories, feature, or project.
- Where our research set us up for design success beyond the feature we’re working on now, we would only need to estimate our time for architecture/design and testing.
CX/UX work is done before Engineering’s work. Since the dawn of time, designing something has come before building something. And we’re populating the backlog. CX/UX are always before Engineering in our Agile assembly line.
Step 3: Kill Most Meetings, Give UX Decision-Making Autonomy
You made it through steps 1 and 2. Now we need to address drowning in hours of useless meetings. Many could be emails or dashboards. This keeps us from our work and keeps us from being Agile. Engineers have their ceremonies but don’t seem to end up in 5 hours of meetings each day like CX/UX often does. Engineering doesn’t constantly pull each other into “collaboration sessions” and the like.
Let’s take a page from Engineering, let’s be more self-managed, and let’s allow UX to make decisions in their own domain. This would eliminate all of these “alignment” meetings where UX pros have to hope someone else doesn’t circumvent, overrule, or ignore our UX decisions.
Imagine an Agile world where UX showcased their work, people made a few comments, and nobody killed what UX decided without a really good reason. You know… the way Engineering showcase meetings work now.
Step 4: Time Estimation and Planning
CX/UX must be involved from the very start of early planning, especially in task-oriented companies, where our research will inform strategies, initiatives, and product (versus someone internal deciding what the product does, and UX is told to wireframe that).
CX/UX can’t get the time left over after Business Analysts, Product, and Engineering take the time that they want. We are an equal voice in planning. If we are task-oriented and doing this right, then CX/UX work feeds everybody else. We feed BA’s so they can write more customer-centric requirements. We feed Product. We feed Engineering’s backlog.
CX/UX must be brought into every planning session at every level so that we are estimating our time and resources. Then we get that time and resources because we are customer-centric and we care about using better processes to create better products and more satisfied customers.
Step 5: Tri-Track Customer-Centric Agile
Finally, we must use Tri-Track Agile. Quite simply, this is where there are three streams working at the same time, collaborating, and feeding each other.
The first track might be called Research or Understanding. This is our CX/UX observational research, insights, opportunities, as-is states, optimized future states, and strategies. This track includes all of the artifacts and documents coming out of research work.
Research feeds the second track, often called Design or Discovery. This includes architecting, designing, testing, and iterating. But if you look closely at the infographic on the right side, it’s also showing that requirements and user stories would be created or improved during this track.
This supports the idea that research isn’t just a UX thing for UX workers. Research should feed Business Analysts and Product Managers and Owners. Research is business intelligence and customer intelligence around people, systems, and context. It should feed company strategies and goals, though that’s not on the infographic… yet.
The third track in Tri-Track Agile is Engineering, often called the Delivery Track. Everything that’s Engineering fits into this track. Coding, testing, sprinting, ceremonies, etc. Engineering gets to do whatever they want here. This is theirs to plan and execute based on how they want to work.
Notice that the first two tracks are not controlled by Engineering or any Engineering-focused methodology. They do not require working in sprints or holding Agile or Scrum ceremonies. CX/UX can join some or all of those as a part of collaborating with Engineering. But left to our own devices, we probably wouldn’t choose to work this way. And we shouldn’t be forced to.
