Lots of teams need to be agile (small A), they need to be able to react quickly and effectively to both external and internal factors that can affect where the companies focus needs to be. Usually, this means being Agile (big A), and using one of the common methodologies such as Scrum, or Kanban.
But just because you need to change your direction quickly, does that really mean that you need to use an Agile methodology?
Getting a workflow that works for your team is one of the most important factors in making sure your team are productive, and releases happen when they should. For me, this means making sure your workflow works for you, and not necessarily shoe-horning your team into an already prescribed method of working. Sure, there are widely adopted standard workflows for a reason -- they work well for many teams. But like all rules, aren't some of the rules of Agile made to be broken?
Personally, for example, I'm not a big fan of the Daily Standup™. I feel that it's invasive and alludes to micro-management. Proponents of "pure" Agile will argue that the reason I don't like it is because I'm doing it wrong, and I'd probably agree with that. In every company I every worked with, the daily standup always boiled down to "yesterday I did this, today I'm doing this", regardless of the best intentions that this time we weren't going to fall into that trap. If something is that hard to do right, I'd argue that the time may be better spent elsewhere.
So what is it that I am actually advocating here? That's a very good question.
In some situations, the rigidity and rules of a set Agile methodology work very well. Everyone in the team knows what's expected of them and how the process works. Getting new people up to speed can be much quicker because you're using something they will already be familiar with. But I don't think that this is always the case.
Sometimes, you need to use your tools as you want to use them, rather than mould your team to the rules of the tool. Sometimes you may want to pick the best bits from multiple sources and create your own hybrid that works for you. Like the concept of short iterative sprints from Scrum? Use them! Like the idea of a prioritised backlog from Kanban? Use it! Need to investigate and capture a rigid set of requirements up front, like you do in Waterfall? Shock horror! You can do that!
I'm a big fan of set periods to get something done (typically a sprint), but I also like continuous deployment. I prefer small deployments after a ticket is complete and tested rather than a big one once a sprint is completed. I also like to be able to drop the current sprint entirely if, for example, a very important piece of R&D comes along. Granted, I've mainly worked in internal development teams that are creating a product, but these are my preferences and things I try to include when I'm tweaking a workflow.
It's important (for me at least), to remember that your tools and processes need to be Agile, along with your development. Most people who are using Agile will have some form of retrospective chat about what went well (or not) over the last iteration; use that to discuss what's working and what's not for processes and tools. Iterate over your work-flow along with your application.
In short, find a workflow that works for you. Using a ticket management tool like YouTrack that is highly configurable can allow you to have a tool that fits your working practices, so that you can create a productive and enjoyable workflow that works for everyone in your team.
For some, adapting practices to fit a tool is important, and works well for them. For others, they'd prefer to whittle the right tool to support their workflow and environment. For me, both practices are equally valid, but maybe we don't say that quite enough with the current trend that screams "EVERYONE MUST BE AGILE!!!".