There are so many methods to apply Agile principles to project management of all sorts. I feel like your choice depends what your end goal is and how you want your team to operate.
Perhaps most striking is this: pick a method that makes it easy for you to track, allow for changes (if any), simplifies administration (eliminate waste), and is easy to communicate to a team (if any).
I have comments on the ones I am most familiar with.
Prerequisite: You have a team that can scale.
If the end goal is a product where you need flexibility due to changing requirements, then my preference is to use Scrum-Agile. The reasons are this:
Periods of work are separated into "Sprints", which are time-based and results driven.
The end of every sprint results in a working product, which means it's completely integrated and is releasable for feedback.
If a change in product requirements needs to be implemented and re-prioritized, then this change can be built in a different sprint and priority.
A typical example is software development where you can adjust to changing requirements and release a product very quickly or if you're prototyping a hardware product.
There are some caveats though.
For Scrum-Agile to work, I feel you need to track three activities in general: Planning, Development, and Review. This is because the requirements could change so these three activities are always in flux.
I prefer to use three types of boards to track the flux:
For planning, my preference is to use a story map to map and prioritize all the individual tasks.
For development, I use a Scrum board to track progress. The planning of user stories on the story map forms the backlog of the Scrum Kanban board so they are super-related.
Then for review, I have a dashboard, which tracks your team's performance in getting work done for each sprint. The purpose is to find out if the team is finishing all it's promising in terms of releasing working products every sprint.
If the goal is to execute on an activity (such as making a sales call or sending out a marketing email based on a backlog of activities), my preference is to borrow the Kanban method from Lean production to track progress.
In this case, I am performing an activity based on stages in a defined and repeatable process (unlike Scrum).
In sales, there are stages where a potential customer is engaged by the sales team and they go from being a "Prospect" to a "Win" when the customer buys. In this case, I would track the activities that my sales team performs, which falls into a defined process.
I have a whole section on how to manage sales activities in my Sales area. I guess this is not really Agile, but more Lean methodology.
Kanban is a specific implementation of Lean production (which is a totally different topic). Generally, Kanban is used for production where you are building a product in a factory, such as a car. The process is defined and repeatable, and the purpose is to reduce waste by optimizing the process.
I prefer to use story mapping to track my progress on small projects as part of a modified Kanban method (story mapping is a big part of my process as you can read). I even use this to track small projects in my personal life. I use it for preparing for a vacation, exploring a new product idea, getting a quick website up and running, etc.
If you follow my headspace principles, a small project is something that needs to be completed within a 1-3 month timeframe and is focused on "what" and "how".
Generally, I use it because of the following reasons:
I need flexibility in planning tasks/requirements, assuming they might change.
I want to track the execution of tasks.
I don't have a defined and repeatable process in my activities.
I don't want to use Scrum Agile because I don't have (or don't want) a dedicated team to support a disciplined Scrum-Agile process.
I want something visual and better than a one-dimensional to-do checklist.
A story map is a 2D checklist for which I can prioritize my backlog of planned activities in a visual manner. Since I am focused on the user journey (which could be mine), I can prioritize my activities in sequence and based on dependencies. In addition, I usually time box a series of tasks as well.
I guess it's really a mutant Scrum-Agile method right now, but the danger is that it falls into chaos if you don't know how to enforce discipline when your team scales. My advice would be to use this mutant way on a small team no more than 2-3 people, but if the requirements and team need to scale, re-train everyone on a new, disciplined process based on a schedule.