Agile / SCRUM Process
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss these lightweight development methods, among others Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. Together they published the Manifesto for Agile Software Development.[4]
Agile, in it's purest sense, is a philosophy, a way of thinking and behaving, a culture.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
This is as prescriptive as Agile actually is, so when someone tells you you're not Agile because you're not doing a stand-up properly, well, that's not strictly true (and also usually it's not really any of their business! 
)
So where's the beloved stand-up? the retrospective? Well i think you might be thinking of SCRUM, one of the most popular implementations of the Agile approach.
SCRUM
Here's a quick high level view of the SCRUM process.
SCRUM, like Agile, is very lightweight. With the Agile principles at core, SCRUM layers in the concepts of Ceremonies and Artefacts.
Kanban
Kanban started in manufacturing back in the early twentieth century emerging out of the world famous Toyota Production System, a movement which transformed modern manufacturing process before it's approach was adopted in the domains of software development (amongst other industries).
https://en.wikipedia.org/wiki/Toyota_Production_System
Kanban as we know it today are those funny little boards with endless tickets moving from left to right through vertical columns headed with 'Backlog', 'Test Done', 'In Progress'.
A team's kanban board should really be unique to that team and it's process; the boards reflecting the process or states that there tickets move through. for example a financial, or other highly regulated industry, software delivery team may have columns to include compliance checking (hopefully these skills will be readily available in/to the team).
Physical or Digital?
My preference is for physical boards. I love the interactivity, for example, in daily stand-ups asking people to touch the ticket they are working on before speaking about it helps the team to visualise and contextualise this persons contribution in the scope of the overall sprint/feature/deliverable and encourages engagement.
A physical board will also always been infinitely more flexible. Add a mini post-it here for a blocker. Add a date to a ticket to set it's expectation for done. Add a post it to a column to add acceptance criteria. All of these are simple with a physical board however software implementations will always have their restrictions.
Information Radiator (tip of the hat to the TPS again for this..)