What is Agile?
What is Agile?
Why being agile is a mindset, not a process.
A newsletter for technical SEOs to learn the product and agile skills so they can work with development teams to get recommendations implemented.
Agile is a mindset, not a process.
That’s what I have learned after spending over 2 years in the product and engineering team that transitioned from waterfall to agile delivery.
This mindset has changed how I work with developers and how I approach working with clients as an SEO Product Management Consultant.
The TL; DR
In this newsletter I will go through:
What is Agile?
The Trap of Doing Agile
Agile vs Waterfall Delivery
The Agile Mindset
Agile Frameworks
Further Reading
The concept of agile is a way of thinking that technical SEOs or SEO Product Managers need to understand if they want to work with product and development teams who get things done.
What is Agile?
Although there are definitions and wheel diagrams on Google these seem focused on “doing agile” rather than “being agile”.
If I had to define and summarise agile it would be:
A Mindset - Agile is about approaching projects differently by creating a culture of learning and experimentation so teams can learn to “be agile”.
Maximise Outcomes - Agile is about solving both customer pain points and business problems, it’s not about just shipping deliverables.
Teamwork - Agile needs people to work together and be bought into the idea of working in a different way, both at a team and executive level.
Utilising Frameworks - Agile is about utilizing and evolving frameworks that help teams and organisations create processes, roles and rituals to “do agile”.
These core factors allow successful product and engineering teams to release small and frequent code changes to customers, then learn from these changes.
I think this is one of the biggest benefits peeking behind the curtain of a large software company, you soon realise software development is utter chaos.
Agile, in my experience, is just a way of thinking backed by practices that, with the right people, can drive real business growth, solve customer problems and bring order to the chaos of releasing code.
Many organisations fall into the trap of “doing agile” rather than “being agile”. I’ve fallen into this trap as a Product Manager and it’s an easy one to fall into.
The Trap of Doing Agile
If you Google this question you will get something like this:
“Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches.” - https://www.atlassian.com/agile
It’s true that product and engineering teams release smaller and frequent code changes but that can be done with traditional waterfall delivery practices.
Many (including me) fall into the trap of “doing agile”. Following a set of agile delivery frameworks like Scrum or Kanban and then saying “we’re agile”.
In reality, all you’re doing is waterfall delivery in smaller release cycles.
Agile vs Waterfall Delivery
Let me explain why many fall into the trap of “doing agile” by breaking down waterfall and agile delivery practices.
Waterfall Delivery
Traditional waterfall delivery projects are sequential and are released in one “big bang”.
Projects which use waterfall follow a set sequence. They start by gathering requirements and making a project plan. A number of different teams then design and build the product while passing it off to the next team.
This usually causes issues, as many teams do not directly speak to each other and assumptions, are made about the project. This can slow down the project and extend its release.
This means it can be months or even years before a product is released and the team start to learn by gathering customer feedback.
I’ve seen companies use traditional waterfall project management to launch websites many times over the years.
One of the worst waterfall projects I’ve seen was on a site migration project was lost a global client brand £100,000 in the first month (which was the first month they signed up to the agency).
The client changed everything about their brand and website but didn’t do any user testing before launch. This wasn’t just an SEO issue but more importantly, was a branding, informational architecture and UX issue.
Doing a test before launch or gaining valuable feedback during the design phase would have circumvented many issues.
This is the issue of having a fixed mindset and using traditional waterfall project management techniques in today’s age of constant change. The risk to a business increases the longer the project takes to get in front of customers.
Which can lead to businesses investing even more money, time and resource into “fixing” projects.
The Trap: This is where many fall into the trap of “doing agile” by building a product or feature in small sprints but still following a set sequence that takes causes a long delay when releasing to users.
The greater the time to release to customers or users the greater the risk and cost to a business.
At the end of the day, waterfall stops a team or business from continuously learning and improving based on data and feedback. It waits for a “big bang” moment, rather than trying to learn and reflect. This can still happen with an organization “doing agile” and it happens all the time.
Agile Delivery
Agile or agile software development is an iterative approach to building a product, service or feature. It focuses on incrementally shipping code with the goal of maximising customer outcomes and business impacts using small releases.
Releasing small and frequent changes helps product and engineering teams be more efficient, productive and maintain customer-centricity.
In a time where user behaviour and technology constantly changes on a weekly or monthly basis, spending months or even years to release a product or website no longer makes sense.
Instead, successful product teams use experiments, surveys, A/B tests and prototypes to confirm hypotheses for high-risk initiatives before investing in development teams to implement code changes.
They use data to inform and back up their ideas, which allows them to get buy-in from other teams. It also allows product managers to prioritise initiatives based on customer feedback and data rather than just opinions.
Quick Note: Many successful product teams don’t try and test every little thing.
Instead, they prioritise initivies before using discovery sprints to uncover if their big risky ideas are worth investing in.
I know many claim to “test everthing” but in reality unless your Amazon who releases code every second, without the right team, process or culture it’s not possible.
The product and engineering teams then work together using agile frameworks (Scrum, Kanban, etc.) to break down features into manageable chunks or web development strategies which are then released to customers.
Using these frameworks product and engineering teams do not release things in one “big bang”.
Instead, initiatives are phased to maximise learning from each release. Product teams monitor and learn from these changes, the positive or negative outcomes are then fed back into the team. These learnings are discussed and allow teams to pivot quickly, reducing risk and maximising outcomes for the business and customer.
This continuous process of learning and experimenting never stops.
Any team or company on this journey requires the right mindset when approaching any project.
“The importance of investing in culture and change on the journey to agility cannot be overstated. Agile is, above all, a mind-set. Without the right mind-set, all other parts of the agile operating system can be in place, and yet companies will see few benefits.”
- The journey to an agile organization, McKensey
Let’s talk more about the agile mindset.
The Agile Mindset
Agile is not just about using frameworks to make “small and frequent releases” by a product or engineering team.
Instead, it is a way of approaching projects and thinking “how can this be delivered to maximise team learning and maximise business/customer outcomes?”.
This way of thinking is called the Agile Mindset and is defined as:
“An agile mindset focuses on “being agile” as a foundation for success in “doing agile.” It is defined by the four values and described by the twelve principles of the Agile Manifesto and then manifested through an unlimited number of practices and different ways of working.” - The Agile Mindset
The mindset, values and principles of agile should allow companies and teams to develop a delivery culture of learning and experimentation.
Quick history lesson: In 2001 the Manifesto for Agile Software Development was put together by a group of softwar engineers who were fed up with traditional project management practices.
This manifesto created a new way of working, an Agile Alliance and outlined 4 core values and 12 principles for software teams who wanted to practice agile.
These core values and principles are still used by teams today.
From my experience, this shift in thinking and culture development can take years. Although it isn’t down to one person to change a company, you can still have an agile mindset that strives to help improve how work gets done.
Even then it won’t be perfect.
If you’re looking for agile to create a “perfect process” to get SEO, UX or development initiatives implemented you’re in the wrong game.
If you’re looking for your team to learn and improve while building SEO initiatives that solve a customer or business problem after each release, then you’re already on the right path.
Agile is about being on a constant journey, rather than reaching a destination.
Agile is a Mindset Journey
Remember, it’s not about the destination but a neverending chaotic frustrating journey working with people.
Both you, your team and your company will need to approach work with the mindset of learning, experimenting and making decisions.
This is the foundation of agile, working with people to maximise learning through experimentation.
Not all teams, organisations or individuals will be ready for the agile mindset or even want to engage. It can take a long time for organisations to start to embrace agile.
For example, at DeepCrawl even with our team using agile frameworks and access to agile coaches, it took almost 2 years for the whole product and engineering team to transition from “doing agile” to “being agile”.
Even then there were still things that needed to be actioned and improved. It wasn’t perfect (nor should it be).
Through this culture of learning and experimentation, over time the team’s change in attitude and thinking increased code output by +700% year on year.
To put that in terms of waterfall vs agile, that is a change of 1 major code release in one year, to 1 code release a day the next year.
Even when the agile mindset foundation is formed any organisation is going to need to start using agile frameworks to “do agile”.
Agile Frameworks
If the Agile Mindset is the foundation, agile frameworks and practices are the structure you build on top to get teams to work together to get initiatives released to customers.
They are important as they can help your team develop processes, roles and systems to release small and frequent changes that maximise business and customer outcomes.
It's quite likely that you've heard of these agile frameworks but for those who aren't aware:
Scrum - Scrum is a framework that is the most commonly used framework by product and engineering teams. It allows teams to be self-organized, creates structured processes and works in time-boxed sprints to achieve a common goal.
Kanban - Kanban isn’t just a board but a popular framework that helps teams reduce waste and be transparent about work being carried out. It’s quite often used when product and development teams need to release tickets very quickly.
Lean - A lesser-known framework but one we used at DeepCrawl. The lean UX method focuses teams on continuous learning and reducing assumptions about a new product or feature to reduce risk.
When you talk to product and engineering teams what you find is that many starts with these frameworks but over time evolve these practices. It is a natural evolution of agile frameworks.
If you read the agile framework guides this is something that is by design and is encouraged:
“Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.” - The 2020 Scrum Guide
This is because agile frameworks like Scrum understand that successful product and engineering teams shouldn’t just be “doing agile” but should have an agile mindset so they are “being agile”.
The agile mindset foundation allows teams to evolve processes and practices to help deliver initiatives that maximise both customer and business outcomes.
This is exactly what happened at DeepCrawl. The rituals, roles and processes of Scrum and Lean, morphed into Discovery and Delivery Sprints. All are aimed at releasing features that maximise the value of the business and customers (or at least when I was there).
Summary: Agile is a Mindset, Not a Process
As I said at the start of this newsletter Agile is a mindset, not a process.
There are a lot of definitions of agile and it’s easy to fall into her the trap of “doing agile” rather than “being agile”. Although it might be a trap an organisation needs to fall into to better understand what success looks like.
In software development, product and engineering teams have been using agile for many years to deliver features, products or services that solve customer problems.
The shift to this agile methodology takes time and even organisations like Spotify, Amazon and Atlassian continue to evolve how their teams work together to achieve “being agile”. It is a journey that never ends.
Further Reading
If you want to learn more about agile I have provided a list of resources below to read:
The Secret to Achieving Sustainable Agility at Scale by Ahmed Sidky
Product Management Books for SEOs by Adam Gent
The journey to an agile organization by Sherina Ebrahim et al
Lean, Agile, & Design Thinking by Jeff Gothelf
Managing Up - Lessons From Scaling Teams at Credit Karma and Lyft
Agile development, Department for Work and Pensions, UK Government