Agile mindset, Writing clear documentation, and Specification by Example
3-2-1 Mondays - Edition #2
Hello 👋,
Welcome to the 3-2-1 Monday newsletter.
Every Monday morning, start your week with the following:
💡 3 short ideas about working with devs and product teams.
📰 Two articles to explore to help be more effective with product and dev teams.
❓ One question for you to think about this week while working.
To receive articles like this, please subscribe to The SEO Sprint 👇.
💡 3 Short Ideas
Short ideas on how to improve working with devs and product teams.
1) 🧠 Agile is a mindset, not a process
Many SEOs working in product and engineering teams will notice they use Agile frameworks to plan, manage and execute projects.
They’ll work in sprints, planning, reviewing and refactoring to break down tasks into tickets that fit into short and frequent releases. However, many teams and organisations fall into the agile trap.
An Agile coach Ahmed Sidky at Riot Games, states that there are two ways of doing Agile:
🌀 Doing agile - When a team just mindlessly follows frameworks and processes to the letter. They don’t learn to adapt their processes or practices.
🧠 Being Agile - When the team embraces a growth mindset, their habits and attitudes will reflect and improve delivery processes to meet their needs.
The trap of agile is that teams follow a process or framework by embracing the habits or attitudes of being agile. This result is that “agile frameworks” slow the delivery of work. Teams get stuck in vicious “short” delivery loops trying to follow necessary processes, rather than focusing on solving customer and business problems.
I’ve had first-hand experience working as part of a product squad and finding that just following set practices in a framework like Scrum hindered delivery. In retrospect and looking back, it was clear now we were “doing agile” (following a process) rather than “being agile” (embracing a growth mindset).
After inspecting and reviewing how we worked, the team identified a few new practices and frameworks we added to make our way of working. This meant we collaborated outside of official Scrum ceremonies. This improved our output, reduced rework and allowed the team to focus on solving impactful problems.
The lesson from this experience was that to be truly agile, teams need to collaborate outside of official Agile ceremonies.
I explained my thoughts on what agile is based on my experience working in product 👇
2) 📝 Clear documentation helps get buy-in
In 2022 I interviewed 15 in-house SEOs on how they worked with developers to get things done.
One clear trend from the interview was that in-house SEOs learn to write clear documentation to get buy-in from development teams before creating SEO tickets.
Before any ticket is added to a development backlog, many in-house SEOs create documentation to explain:
What - What is the problem that the team is trying to solve?
Why - Why is this problem worth solving?
Where - Where exactly are you asking the developers to implement a change, and how will it look?
This documentation allows technical teams to understand what SEOs are requesting and get on the same page. It also allows developers to ask questions and provide feedback within any shared document. Reducing the chance that tickets get rejected.
Many in-house SEOs create a Product Requirement Document (PRD), 1-Pager or Project Brief to provide a technical team with details of what is needed. Then they sit down and discuss the document's contents with the team. The contents of the documents change from team to team, and from company to company.
There were usually three key pieces of information that were shared with the technical team:
🩲 Opportunity (Why): The in-house SEO always explained the WHY behind the requested feature, fix or change to the website.
⚙️ Specifications (What): The in-house SEO provided the requirements the developers must meet for the project to be marked as “done”.
🎨 Visualisation (Where): The in-house SEO provided a high-fidelity design or code output for the team to visualise what the work output would look like once complete.
These three key pieces of information were critical to helping in-house SEO teams get projects executed by product, development or project management teams.
Once the idea or project is signed off, the specifications or requirements are turned into development tickets.
I provide more details on how in-house SEOs get things done 👇.
3) 📋 Specification By Example
In SEO teams, it can be difficult to communicate our technical requirements to product and development teams.
The recommendations you made in a ticket or document are completely missed or misunderstood.
In elite product and engineering teams, communicating requirements isn’t a problem.
They use a simple and powerful method to communicate complex specifications that both business and technical teams can understand.
That method is called Specification by Example.
“Specification by Example is a process to define requirements for software by illustrating specifics using concrete examples rather than abstract statements.”
Gojko Adzic, Author Specification by Example
Specification by Example is a secret communication superpower I’ve found helpful in breaking down SEO requirements into actionable tickets.
Instead of writing abstract tickets, an SEO professional uses concrete examples to help a development team easy to understand the ticket requirements.
In the example below, the SEO has taken the list of pages that need a self-referencing canonical tag and created a testable example in the form of a data table.
This can then be used to write the acceptance criteria the developer needs to meet so it can be marked as “done”.
There is little “guesswork” done by the developer or QA team. A developer could take this ticket and easily test it to see if their work matches the acceptance criteria in the request.
Why is it so powerful?
I’ve found that it:
📋 Clarifies Acceptance Criteria - SEOs can write better specifications and reduce the amount of discovery work needed.
💬 Develops a Common Language - Concrete examples help cross-functional teams (SEO, product, dev, etc.) quickly develop a common language, reducing the time needed to discuss and discover the tickets.
🧠 Builds shared Understanding - Concrete examples help the team quickly get on the same page to identify ambiguous or missing requirements in stories.
The great thing about this method is that it is simple and can be applied to any project or ticket.
I’ve written more about Specification by Example in the article below 👇.
📰 2 Articles to Explore
Articles to explore to help be more effective with product and dev teams.
The Power of Product Thinking
by Julie Zhuo
"The simplest way to define product thinking is that it is the skill of knowing what makes a product useful — and loved — by people. As with all skills, it can be nurtured and developed; it’s not just an instinct one does or doesn’t have (and even instincts are trained, after all)."
The Art of Decision Making as a Product Manager
by Sachin Rekhi
"The surprising thing about the difference between the well functioning team and the alternative is not the actual decisions being made, but the process and culture within which such decisions are made. To build the right decision making culture, I encourage product managers to follow the following best practices."
❓ 1 Question For You
A question for you to think about this week while working.
How can you use your SEO data to create concrete examples?
How did I do this week?
If you enjoyed reading this article, then consider the following:
📰 Share — Please share the newsletter with your network or colleagues if you think they might find it helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.