Scrum has a few types of meetings but, with this question, people usually tend to be referring to the daily scrum meeting. The daily scrum is a 15-minute meeting, held every day by the development team. The purpose of the meeting is for that self-organising, cross-functional team to assess the last working day and plan the next one while giving them the forum to raise any risks to the delivery.
The meeting should take place standing up (in order to encourage brevity and focus) and each team member is encouraged to share with their team mates the answer to three questions:

What did I do yesterday that helped the Development Team meet the Sprint Goal?

What will I do today to help the Development Team meet the Sprint Goal?

Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Quite often the purpose of this meeting is misunderstood and it is viewed as a status sharing meeting for others within the organisation rather than as a tool for the development team to manage themselves. If the daily scrum is viewed in this way it often becomes meaningless.

I have briefly explained above what Scrum is. Whereas Scrum is relatively straightforward to define (even if it is difficult to implement), Kanban is more open to interpretation as it is less of a framework and more of a set of principles. This question probably deserves a more in-depth answer but here is a short comparison. Thanks to my friend, Helen Meek, for letting me pick her Kanban brains!
Scrum is a framework for a cross-functional, self-organising team to iteratively and incrementally deliver small slices of valuable functionality every couple of weeks. There is plenty of scope for interpretation within Scrum (how you estimate, whether you do release planning etc) but there are also some non-negotiables (there is always a ScrumMaster and Product Owner, there is a strict definition of done, teams must do sprint planning, daily scrums etc).
Kanban is a method that you apply over your existing ways of working, be that Scrum, XP or something else.
It looks to understand how you work now and how you can catalyse continuous improvement through small incremental change. It also seeks to help organisations understand the demand on them and what their actual capacity is.
Kanban uses work in progress limits based upon capacity thus it is a ‘pull system’ meaning that, unlike Scrum, Kanban has no timeboxes.
As well as some guiding principles, Kanban has a set of 6 practices. These are:
· Visualise the work flow
· Limit your work in progress
· Manage flow
· Make policies explicit
· Feedback loops
· Improve incrementally
Because Kanban is overlayed onto your existing methods, roles and processes etc will remain in place until you decide they need to change.
You might have heard of ‘ScrumBan’. This is where Scrum teams have decided to adopt Kanban principles and practices in addition to doing Scrum.
There is no strict rule for which is more appropriate in a certain context but personally, in general, I believe Scrum is more useful for product development efforts or situations where creativity or innovation is valuable while Kanban is more useful when efficiency or ultra-responsiveness is valuable for example maintenance work.
Henrik Kniberg and Mattias Skarin have created a free eBook detailing the comparison between Scrum and Kanban.

To begin with, a Scrum team has no idea of how much work they are capable of within a sprint. Therefore they will create a prediction. This prediction of their capability is known as their initial velocity. Once the team has completed a couple of sprints, they have some empirical data of their actual capacity and so their velocity is based upon this data.
Velocity can be used to get a feel for likely end dates for projects or the likely scope of the project, however it is often a source of tension within an organisation and, misused, can lead to dysfunctional behaviour.

The sprint backlog is the team’s plan for the sprint. It is usually quite low-level and detailed compared to the product backlog which is generally at the functionality level. As a general rule of thumb, users should notice when a product backlog item is done but probably won’t notice when a sprint backlog item is done.
Product backlog items are often written as user stories (although they don’t have to be) and, as such, define something that when completed will be of value to the product or its users. Sprint backlog items are typically tasks that are required to be completed in order for the product backlog item to be completed.

Sprint planning involves a cross-functional, self-organising Scrum team collaborating with the Product Owner and subject matter experts to forecast what they are able to deliver in the upcoming sprint. Sprint planning is broken into two parts.
In sprint planning part one, the team attempt to answer WHAT they can do. They will analyse their capabilities, their availability and use data about their previous capacity to work out what they are capable of. They will take the product backlog that the product owner has curated and, together, will confirm the definition of done and craft a sprint goal – or objective – for the sprint.
In sprint planning part two, the team attempt to answer HOW they plan achieve their sprint goal. They will work out who is going to do what, how the design will evolve, how they will know they are done, how they will mitigate risk during the sprint and how they will manage themselves as a team during the sprint amongst other things. Teams will often create a sprint backlog of tasks that they have identified are needed in order to achieve the sprint goal and will create a way of making this visible and easily maintainable throughout the sprint.

“a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”

Scrum is a simple, empirical process framework based upon the principles of transparency, inspection and adaptation. In short, when using Scrum, you accept that the end solution is not predictable at the outset so commit to short iterations of “done” work, building something valuable and then getting feedback on what you build and how you built it so that you can improve both the product and the process in the subsequent iteration.
You can watch a short video of me explaining what Scrum is here.

Not really. Agile is effectively just a set of values and principles. Many people call it a mindset but there’s not enough formality to call it a methodology. Even Scrum, the most popular and formal of the agile flavours, is more of a framework than a methodology. Scrum has rules, roles, artefacts and ceremonies but is still some way short of a blueprint or standardised process.

I’m not going to quote you any headline grabbing statistics or headlines. I’m just going to tell you what I think. Speaking from my own personal experience…yes. For me, agile is a more realistic, humane and value-driven approach to delivering projects or developing products. The people I speak to enjoy working on agile projects more than the type of projects they used to. The organisations I work with get better results and the products are typically much better. Of course I would say this but, then again, I wouldn’t still be doing this 15 years later if I didn’t believe in what I was doing.

Far from it! If anything agile is quickly becoming the new norm. Admittedly, many people within the industry have been frustrated by the relatively slow pace of adoption in the early years after the Agile Manifesto was published, and there have been a number of high profile organisations claiming premature success in wholesale adoption but the fact remains that the high pace of change and the increased complexity of product development efforts and organisational challenges means that an the empirical approach of agile methods is more often than not a more suitable approach than a predictive approach.

This is a common misconception that is frustrating for many and has potentially been one of the factors that has held back the success of agile teams and organisations over the last 15 years. The agile manifesto was created by software professionals and it is an incredibly logical and successful way of developing software. However, the values and principles are applicable in many problem spaces.
Any domain where it is difficult to define exactly what is needed or where there is a high degree of uncertainty or change, or where value can be realised or risk mitigated incrementally can benefit from adopting the values and principles of the agile manifesto. Unfortunately many people from non-software domains get turned off by the fact that the manifesto refers to software.

Usually when people ask me this they are referring to “being agile” rather than simply “doing agile” – the holy grail of changing the culture of the organisation to a more agile one. If you look at The Agile Manifesto, then you will see that “agile” is largely values and principles rather than specific practices or a particular process. Indeed the phrase “we value individuals and interactions over processes and tools” is one of the key values of an agile approach.
Changing an organisational culture is a challenge and takes a long time and concerted effort. Companies may never achieve complete change and complete alignment with the agile manifesto. And that’s fine. Usually just changing so that the culture is a bit more aligned to agile values is enough. What does that look like? Well, usually we look at the default behaviours of people and whether that is more aligned to the values on the left hand side of the agile manifesto or whether those behaviours are more aligned to the values on the right hand side.

I am a Scrum Alliance Certified Scrum Trainer (CST) and, as such, run Certified Scrum Master (CSM) classes. I do not offer certifications from any body other than the Scrum Alliance. In order to become a CSM, you must attend a CSM class of at least 2 days in length, taught by a CST and then subsequently take and pass the CSM exam.

Agile is generally shorthand for either agile software development, agile product development or agile project management. An agile approach to something is typically based upon the four values of The Agile Manifesto. These values advocate individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.