For the most part, the tool gets in the way. And people getting started in agile frequently confuse what the tool is capable of (or appears to be capable of) for agile "best practices". If the tool doesn't allow you to add lanes or queues, then you shouldn't be using them. If the tool says to estimate everything in points using Fibonacci, then you shouldn't use t-shirt sizes. If the tool provides reports on personal velocity, then you must need to know personal velocity.
I like to start teams off with a simple card wall. Maybe it is a kanban board. Maybe it is a scrum board. Whatever it is, we design it together in a single session where we make broad-stroke decisions about our process.
We retrospect frequently (regularly) and evaluate if the board is working for us or not. "Does the story wall appropriately tell our story?" Then we make adjustments (or not). Sometimes, we agree to revisit on a set date. Sometimes, we roll with it knowing we can always change it.
In the interest of full disclosure, I did work on a multi-million dollar project with teams in various locations around the world. In this instance, I felt an electronic tool was beneficial as it was a good way to communicate work status across all locations. It created a universal card wall. But even then, we kept the implementation of the tool simple and relied primarily on local card walls allowing each team to design and adjust their own specific process.
The "process" you design must work for your team. Adopting another team's process is an acceptable starting point. Just be certain you adapt and improve as you learn best what works for your unique team in your unique environment. Most tools get in the way of this. All tools offer less flexibility than a blank wall, a roll of painter's tape, and a fist full of index cards.