Lessons from Agile Delivery
What I learned from working with an enterprise engineering team
A newsletter for technical SEOs to learn the product and agile skills so they can work with development teams to get recommendations implemented.
I learned A LOT working as a Product Manager.
In this issue, I highlight some of the most important lessons I learned to get things done as a Product Owner/Product Manager when working directly with development teams.
As a Freelance SEO Product Manager, I now use these lessons to work with client developer teams to get recommendations delivered (not stuck in a backlog).
In future newsletters, I’ll dive a little deeper into each topic to provide more details (I’ve also provided more links for further reading).
Discloser: A lot of the drawings in this newsletter were inspired by Michael Williams and Jeff Patton.
Vision and Navigation
A vision provides a North Star for development teams and requires a navigator to make sure they are heading in the right direction.
I’ve learned that having a clear project vision helps development teams improve code quality and efficiency.
A good vision requires someone to be the navigator who is able to stand back and make sure the team is headed in the right direction toward the desired outcome.
There will be many ways to reach a product vision but someone will need to make sure that the team is actually solving customer pain points.
In product teams a vision needs to be a guiding principle that helps developers understand:
The user problems the team is trying to solve
The user behaviour the team is trying to change
Why this feature is important to build over others
A good vision requires communication to help teams understand your guiding principle.
I’d recommend reading Product Vision vs. Mission or What Does It Mean to Be a Product Owner? for more information.
Keep focused
It’s better to prioritse and focus your effort on solving one big problem at a time.
There is always something to fix, improve or change when you’re building software.
If you’re worked on the delivery side of a business you’ll understand that without planning, strategy and discussion a project can quickly grow in size.
The issue is that your teams time or resource is not finite, even when you have millions of dollars of investment. A team of developers can only work on so many things at once.
At DeepCrawl the engineering changed how we worked on projects and problems, with squads formed around solving specific client issues. This helped to focus each team on solving specific problems, rather than spending time spread out unfocused and putting out infinite fires.
In reality, the team members in the squads did need to jump on other issues but it allowed a group of different specialists to put 70-90% of their time into solving one critical problem at a time.
Break it down
Developers need someone to continously break down projects into features, then features into prioritised tickets.
I learned from other experienced product leads that this backlog of ideas and bug fixes can’t just be thrown into a development backlog. A development team will question everyone, which will take time and slow down the release of tickets (ideas).
Instead, it is better to create a “break it down” process with your developers that will get developers involved at the very beginning and help prioritise tickets before it enters the dev backlog.
This process of continuously breaking down tickets with developers will help improve code quality and output efficiency as teams focus on solving priority problems in the backlog.
Team Structure
Small teams formed around problems will make the dream work.
I’ve seen a lot of team structure over the years but at DeepCrawl we changed traditionally large siloed teams into small squads.
These small squads were made up of core engineering specialists (UI, API, designer, etc.), a product manager and a scrum master. Each squad was tasked with solving a particular customer problem including segmentation, SEO QA automation, SEO insights, etc.
As a smaller team, we found we were able to work independently from other squads but still work in the guidelines of the organisation (release cadences, design and brand guidelines, etc.).
I’d recommend reading more about squads and engineering culture from the Spotify blog:
Discover Customer Value
Testing risky ideas about adding customer value needs to be uncovered not assumed, to make sure code releases aren’t wasted.
Lean UX has taught me that assumptions are the killers of ideas.
At DeepCrawl there were a lot of assumptions around features, designs and user flows. However, before each feature, we always highlighted what the biggest risks and assumptions were to a project and made sure to create experiments to learn how to mitigate this risk.
This created two workflows: discovery and delivery sprints.
Discovery sprints happen throughout the life cycle of a project. Any time new requirements are unearthed from customer feedback after a release or provided by the product manager it's important to make sure your riskest assumptions are tested.
If you’d like to learn more I’d recommend reading up on Lean UX practices and principles.
Align on Stories
Discussing stories with developers helps to build a shared understanding, solve complex technical problems and align on requirements.
Documentation does not equal understanding.
This is one of the biggest lessons I’ve learned working directly with development teams. Simply writing down a ticket and assuming your user story or bug requirements is understood is a huge risk.
There is a big difference between reading a ticket and creating a shared understanding of the necessary requirements to solve a problem.
Discussing a ticket or tickets in a time-boxed meeting can help your developers really understand the user requirements and align on acceptance criteria. This can reduce time spent working on unnecessary code and reduce defects or bugs once the feature is built.
I’d recommend reading Behaviour Driven Development if you want to find out more.
User Story Mapping
User story mapping helps to slice large projects into manageable chunks.
Development projects are complex.
One of the most useful techniques I’ve learned is that no matter how complex the project is, it’s important to always make sure to create a User Journey Map (even a rough one) with your developer. This helps a team think more about the user journey and pain points.
From this User Journey Mapping exercise, the team can start to break down tasks that can be turned into user stories or epics. When breaking down projects into these smaller tasks can help the team think about a phased approach to delivering a project or initiative. I always found breaking down projects helped developers (and me) clarify what priorities were needed to get the project started.
The aim is to deliver a minimal viable release for a project that solves a customer or user problem, that can be continuously improved after each release.
I’d recommend reading more about User Story Mapping.
Dev Backlog Management
Creating well-sized tickets for each sprint is an art that requires planning and strategy.
As a Product Owner within squads at DeepCrawl, I know just how chaotic and ever-changing a development Jira backlog can be on a day-to-day basis.
Even when moving tickets from the product backlog to the dev backlog I learned that further discussions were needed to make sure tickets were prioritised and well-sized for the next sprint.
Any ticket in the product or development backlog could change in scope at a moments notice so it was always important to make sure you were aligned on these changes. As this would impact the next sprint and backlog of work.
The trick I learned was that development teams needed 4-6 weeks worth of backlog tickets to make sure that initiatives were continuously improved and developers knew what other work was coming up.
If the backlog was too large or you worked on tickets too early then you, and the development team would forget the requirements of tickets.
A combination of planning, strategy and alignment on user stories needed helped keep the backlog well managed and allowed developers to release consistently.
Frequent Releases
Frequent code releases help to reduce risk, priority changes and bugs.
At DeepCrawl I watched as development teams moved from big bang releases to shipping code frequently using Sprints.
This might seem like a simple step but in reality, it takes a lot of work to make the switch.
After switching the benefits of the shipping code frequently become very clear to the team:
Reduced risk - There was less chance of broken software being shipped and less time to get features in front of customers.
Mindset - The frequency of code releases also changed how product and engineering teams approached releasing features.
Experimentation - A reduction in risk meant that teams could ship code that tested an idea and if it didn’t work it could easily be changed.
Code quality - A development team can make frequent changes to the code, learn more about the tech stack and improve the quality of the code over time.
For more information on frequent code releases, I recommend reading more about continuous deployment.
Iterative Improvements
Small iterative improvements are a more efficient path to success compared to larger “big bang” releases.
Iterative improvements allow software releases to be guided by customer feedback — which helps teams to release successful features or products faster.
This stops businesses from wasting time, money and resources shipping code that does not solve customer pain points or grow the business.
These small iterative releases also allow your team to test your system after each release and flag bugs that need to be fixed. It is a lot easier to narrow down why something broke after making one or two releases than making 100 (especially on a system that relies on multiple stakeholders).
Small releases allow squads to get to grips to complex problems and then once they are confident scale the system.
Measuring Outcomes
Reporting back to engineering teams help them see the value of their work.
Reporting doesn’t just matter at the executive or management level.
Development and product teams also need to measure a variety of different metrics to make sure that projects are driving the desired results.
At DeepCrawl we used Objectives and Key Results (OKRs) to help rally teams around a common goal. This helped the squad focus on 1-3 key results for projects which would be the measurement of a project’s success.
What I found was the automated reporting to track the progress of the team helped them understand the value of their work and prioritise bugs and tickets in the backlog. A simple automated dashboard can help clarify the impact and direction of the project (also be used to report back to other teams as well).
I’d recommend reading Guide: Set goals with OKRs and Outcomes vs Outputs in SEO for more information around goal setting.
Learning Compounds
Discussing ways to improve the process as a team can help reduce friction, waste and bugs.
A key lesson learned was that a squad needs to discuss how to improve.
At DeepCrawl we used a simple meeting called a retrospective after each release to understand how the team could better work together.
This allowed different team members to highlight things that were working and things that weren’t working. For example, I remember UI and API discussing how they should align on releases (API was steaming ahead on changes that UI needed to know about).
After each sprint, the team would build up a list of things that needed to be tackled but step by step we also learned more and more how to work with each other.
If you want to learn more about retrospectives check out this quick guide here.
Summary
I’ve learnt a lot from working in an enterprise product and engineering team for over 2 years.
I hope these lessons help any Technical SEO or SEO Product Manager think more about how they approach working with development teams.
In future issues, I will provide more details of each topic covered in this list.