Where you want to get to matters, unless, like Alice, you are on an adventure and you are just trying to get back to where you started. In my work with organizations, the general intent is to get to somewhere different, somewhere better. As an Agile coach with 20+ years helping others develop proficiency in Agile, I've found effective "where you want to get to" strategies tend to fall into one of 4 contexts -- team, skills, customer, or flow.
These contexts establish frames for selecting specific agile practices and choosing goals for measuring progress towards proficiency in those practices. For example, the "skills" frame might lead to the use of practices such as coding standards, paired programming, and continuous integration. A reduction in production defects would indicate an increase in skills proficiency.
Of course, Agile practices are not restricted to just one frame. Paired programming would be an equally valid practice in the "team" frame. The frames might be viewed in a venn diagram with some practices such as retrospectives living in all 4 frames. Likewise, a measure of progress, like team satisfaction, could span more than one frame.
The main benefit of frames is focus. You don't need to, nor should you try to, do all Agile practices at once, right out of the gate. Just like incremental product development, you should adopt agile practices incrementally, respecting your organization's capacity to absorb change in process and practice, and keeping an eye on your goal -- where you want to get to.