Agile Methodology - Scrum, Kanban

Scrum

• In scrum you have small team working on list of small, concrete deliverables. You divide big organization into small cross-functional and self-organizing teams.
• It has fixed length iteration (usually 2 – 4 weeks) at the end of which you have shippable code. 
• Each items in the iteration (sprint) are estimated and team commits on finishing it by the end of sprint.
• At the beginning of iteration team pulls out items from the product backlog, based on the product owner’s priorities and how much the team thinks they can complete in one iteration. 
• After each iteration the process is optimized by having retrospective.
• Since you working on a small thing which is part of a large group, you integrate regularly to see the whole.
• Scrum prescribes three roles: Product Owner (sets product vision & priorities), Team (implements the product) and Scrum Master (removes impediments and provides process leadership).
• Scrum resistance change within the iteration, which means you typically don't add new item in the middle of iteration as team is commited with items pulled in the sprint.
• Scrum prescribes estimation and velocity(per iteration how much hour of work a team can complete).
• Burndown chart prescribed 

Kanban

• Kanban leaves almost everything open. The only constraints are visualize your workflow and limit your WIP.
• Split the work into pieces, write each item on a card and put on the wall 
• Use named columns to illustrate where each item is in the workflow. 
• Limit work in progress ( WIP), this way proper flow to finish line is always maintained.
• Measure the lead time which is average time to complete one item.
• It does not prescribe any roles but that doesn't mean you shouldn't have. You are free to add role(Product Owner) which make sense to your project. In a big project Project Manager role may be great idea, perhaps that’s the guy who helps multiple teams & product owners synchronize with each other. In a small project that role might be waste, or worse, might lead to suboptimization and micromanagement. 
• Kanban board doesn't need to be reset or start over.
• In Kanban, cross-functional teams are optional, and a board doesn’t need to be owned by one specific team. A board is related to one workflow, not necessarily one team. 
• In Kanban, estimation is not prescribed. Uses Lead time as default metric for planning and process improvement. 

Lean Principals

• Fail Fast, Learn Rapidly
• Planning and Commitment are two different thing. Plan thoroughly and commit sparingly.
• Think Big (Look at the whole Value Stream), Act Small
• There is no process which cannot be improved. Continuous Improvement is never-ending.
• Designs evolve, so do not waste time locking it down early.
• Release Early, Release Often
• Predictions of the future are always going to be inaccurate, by locking down designs, processes, requirements, etc., we lose our ability to respond to the inevitable unpredictability. Change is inevitable!
• Build quality from the start -- don't rely on testing it in later. The job of testing is to prevent defects not find defects
• Specify the most important things and deliver them fast, then take the next most important things. And repeat. We do not know what we do not know, so it is not possible to define everything (and have it remain unchanged) up-front. 
• Everything not adding value to the customer is waste - stop doing it
• Don't equate speed with hacking. A fast moving development team must have excellent reflexes and a well-disciplined "Stop the Line" culture.
• Treat each other as our Customer. Find good people and let them do their job.
• When a defect is found-Stop the Line, Find the Cause, Fix it