This is an article on an Agile search engine optimization project I recently completed that illustrates how to apply Agile thinking to a non-software project. I’ve previously written other articles on applying Agile thinking and techniques to non-software projects (See Related Articles below)
This is another article on an Agile Search Engine Optimization project I recently completed on this very website.
Background
The goals of this project were to improve my blog site at https://managedagile.com/ . This site contains almost 100 articles I’ve written on Agile Project Management but it has reached the point where some additional organization and redesign is needed to make it easier for users and search engines to find and use the information in the site.
It’s important to emphasize that this is not a software development project; This project didn’t involve any real coding of new software. The site uses WordPress which is widely-used by many blog sites and many things can be done without any coding at all. I am very technically-competent but I don’t have time to do software development so I had to do this project in a way that did not require any software development effort.
This was a one-man project – I played every role you can possibly imagine (webmaster, Scrum Master, Product Owner, you name it – I did it). I did engage a consultant who is much more knowledgeable than I am in the area of search engine optimization (SEO) to help me. Her name is Rebecca Gill of Web Savvy Marketing.
Rebecca was very helpful. She did an audit of my website and generated a huge list of potential action items to improve my website. That became my “Product Backlog”, but it was not prioritized. There was a very large number of items in that list and it would have been impossible to do all of them in a very short amount of time. Some were more directly-related to driving business results than others. My first task was to try to prioritize the suggested actions in terms of business impact.
Project Results
This project is not 100% complete. Like most Agile projects, I used an incremental development approach to try to produce business results quickly. And within a few weeks of work, I arrived at the point of what I consider to be a “Minimum Viable Product”. It has the basic features I think are needed but much more work is needed to further optimize it.
Search Engine Results
Here’s what the search engine results look like by week:
This data shows the number of impressions reported by Google. An “impression is the number of times my site as shown up in Google search results. You can see from this data:
- A steady improvement over the past few months as I did a lot of cleanup and reorganization of many of the blog posts followed by
- A sharp increase in the past week or two as I implemented some of the improvements in this project
The result is that the total number of impressions has risen to almost 40,000 impressions per week as opposed to about 10,000 impressions per week earlier in the year (that’s about a 4X increase!)
User Experience
Aside from improving the search engine results, an important goal was just to improve the overall user experience for users using the site. There also was a huge number of improvements in this area including:
- Implementing a new home page to integrate the content in the site
- Implementing a new theme to give the site a more professional image
- Reorganizing all the categories and tags used for organizing the posts to make the information much more organized and easier to find
- Improving all the course materials to make it easier for users to find information on training courses
- Implementing a new contact page to make it easier for users to contact me for further information
- Cleaning up the SSL implementation so that the everything in the site is now secure
- Optimizing the load time of pages in the site
- Simplifying the Share buttons
- Implementing AMP for mobile user performance
- Resolving any site access issues (404 or 5XX errors)
Naturally these improvements are subjective and the impact is difficult to quantify but I’m sure the results are significant in improving the user experience with this site. However, I want to emphasize that this is only the beginning and there are more improvements yet to be done. I intentionally focused on what I considered to be “the low-hanging fruit” – those things that would provide the most impact that could be done quickly and relatively easily.
Important Lessons Learned
This was a fairly simple, short project; but there are a lot of important lessons that can be learned from it.
Agile is Not Scrum
This project did not really involve Scrum at all. Scrum has become so widespread that it has become synonymous with Agile for many people and that is not the case. This project was Agile but not Scrum
- There were no Scrum roles, meetings, or artifacts
- There was no development team – I did everything myself with some help from an outside consultant
- The project did not use fixed-length sprints. I did as much as I could as quickly as I could to get to a reasonable deliverable. I wanted to provide a sufficient level of value for it to be considered a Minimum Viable Product
A lot of people get consumed by the “mechanics” of doing Scrum and that does have value in normal team-level projects. It provides a “blueprint” or “road map” to help everyone in the project understand how the process works and to keep in-synch with each other. In my case, since I was a one-man band, I didn’t need any of that overhead.
The important lesson to be learned from this is that Agile is a mindset and way of thinking that is not limited to implementing Scrum.
Prioritization and Incremental Development Approach
As I mentioned, the list I received of potential action items to work on was overwhelming. If I had taken the traditional project management approach to consider all of those things as firm requirements and tried to deliver all of those action items at once, this project would have gone on-and-on for a long time. By prioritizing all of the items on this list and focusing on the ones I thought would provide the most value quickly and using an incremental development approach, I was able to deliver a high level of value very quickly.
The important lesson to be learned from this is that prioritization of features and using an incremental development approach can significantly improve time-to-market. If you’ve done the prioritization and incremental development correctly, it will be easier to see when you begin to reach a point of diminishing returns and the incremental value is no longer greater than the incremental cost of the effort required for that feature.
Minimum Viable Product
The concept of a “Minimum Viable Product” is also extremely important. Many people and companies make the mistake of:
- Thinking that they know what the customer wants and making a lot of assumptions about that
- Launching a long and expensive development effort based on those assumptions, and
- Then finding out later that those assumptions were wrong
Using a traditional project management approach, many companies wind up with bloated requirements and “gold-plating” products with features that no one really uses. That adds to the expense and time required to complete the project and may even make the product difficult to use because it might be overly-complex. It is better in many instances to start with something simple that meets the most important basic requirements and then optimize it further as needed based on user feedback and inputs.
The important lesson to be learned from this is to avoid the “all-or-nothing” approach that is typical for many projects.
Risk Management
Doing a project like this that involves tearing down a lot of existing functionality and replacing it with new functionality on a live website is full of all kinds of risks. Many people think that risk management is incompatible with an Agile approach. I don’t believe that to be the case. Some level of risk management is always useful and the level of risk management should be appropriate to the nature of the project.
The use of tools is also important. For example, in this particular project I did many backups as the project was in progress to provide a fallback if the changes didn’t work as expected; and in one case, I did have to restore the entire site from a backup. If I had not been doing regular backups, the results could have been disastrous. I think I was able to do all of this without significantly disrupting the user experience of people who may have been using the site during this time.
The important lesson to be learned from this is that an appropriate level of risk management always makes sense even in an Agile project.
Technical Debt Management
Another important consideration is “technical debt”. In an Agile environment, the goal is to release clean software that is free of any bugs at the end of each sprint; however, that is not always possible. Sometimes it may make sense to carry over minor bugs and technical issues that won’t have much impact on the user from one sprint to the next. That’s what “technical debt” is.
It requires some good judgement to manage technical debt sensibly. On the one hand, you want to release a good quality product; but on the other hand, you don’t want to release buggy software that is going to frustrate the users. For example, in this project there were some 404 errors and 5XX errors which I had to fix but the audit tool reported a large number of very technical HTML issues that weren’t even observable by an ordinary user – those were deferred. I think that was a very sensible decision.
The important lesson to be learned is that management of technical debt in a project is important and requires some good judgement and skill to make sound decisions.
Overall Summary
Agile can significantly accelerate the progress of non-software development projects. In many cases, it is just a matter of using an Agile mindset and Agile thinking and doesn’t necessarily involve using Scrum at all. It is mostly a matter of having some basic Agile skills and using a Agile mindset to apply those skills intelligently in a different environment.
Related Articles
Check out the following related articles on “Agile Non-Software Projects”:
- How Are Agile and the Coronavirus Crisis Related?
- Was the Manhattan Project an Agile Project?
- Agile Search Engine Optimization
- Using Agile for Non-Software Projects – Agile Home Remodeling
- How Do You Apply Agile to Non-Software Projects? Agile Book Publishing
Additional Resources
Resources for Agile Project Management Online Training.