Do not develop an attachment to any one weapon or any one school of fighting
Miyamoto Musashi, 17th century Samurai

Agile

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams (“Individuals and Interactions over Processes and Tools”).

Whaterfall

Requirements Analysis -> Design -> Code -> Integration -> Test -> Deploy

Scrum

Iteration = Evaluation / Prioritization -> Detailed Requirements -> Design & Analysis -> Implementation & Developer Testing -> QA /Acceptance Testing -> Deployment

Scrum Roles

Product owner -> vision, ROI -> accepts/rejects product increment -> reprioritize constantly backlog, leadership role
Scrum Dev Team -> cross-functional, self-organizing
Scrum Master -> leadership role, screens the team from interferences keeping the work flow, adjusts forecast, keeps the scrum artifacts visible

Scrum Meetings
Planning meeting -> see what items from the backlog to include in a sprint (max 8 hours timebox over a max 30 days sprint)
Daily Scrum -> short 15 min daily meetings for reports and impediments
Review -> after a sprint finishes a live presentation of the product should be made. Incomplete items are moved again to backlog for reprioritization and inclusion in the next sprint. Stakeholders usually attend this meeting. (shippable software should be delivered)
Retrospective meeting -> reflection of the process, and improvement.
Backlog Refinement Meeting -> cut the big items (epics) into smaller, estimable features (stories) 

Scrum Artifacts
– epics -> big stories that are not easy estimable
– stories -> epics broken down into smaller, manageable, estimable features
– Product Backlog -> list of needed feature visible to any stakeholders, reprioritized constantly by product owner.
– Product Backlog Items (PBI) -> they are usually written in user stories  form. Effort is estimated roughly usually in story points (not hours) -> 2-3 days for 2-3 people => 9 story points
– Sprint backlog -> PBI included in the sprint
– Sprint tasks -> user stories are broken down into short, max 1 day elements that describe how the achieve the PBI (design the page, show latest jobs on the page…)
– Sprint Burndown Chart -> remaining tasks hours till sprint ends. Reestimated daily. It is not a manager report!
– Product / Release Burndown Chart -> Tracks the remaining Product Backlog effort from one Sprint to the next

Notes
* Scrum constrains you to have timeboxed iterations and cross-functional teams
– split in small teams, cross-functional, self-organizing
– split work in small concrete deliverables, estimate effort for each one
– split time into iterations 1-4 weeks, shippable code after each iteration
– optimize release plan, update priorities in collaboration with the customer after each iteration
– optimize the process after each iteration
– In scrum teams are needed to do a time estimation of each item. By adding up estimations of all tasks in a sprint we get the velocity

Kanban

* Kanban constrains you to use visible boards and limit the size of your queues
– specialized teams are allowed
– split work in pieces, each one on a card and put it on a wall
– using columns to visualize the place items are in the workflow
– limit WIP (work in progress) => explicit limits for how many items are in progress in each workflow state
– measure lead time => average time to complete an item, optimize to make the lead time as small and predictable as possible
– In Kanban estimation is not prescribed
– can work in more projects in parallel -> we can use colored cards or swimlanes

Other real project inspired notes
– daily standups are not prescribed but are usually used
– some prefer to put on the board tasks > 1 hour not to transform the board into an administrative monster
– a good idea to use stories that can be broken down and estimated
– weekly iteration planing and a short feedback loop
– pair programming for sharing knowledge (borrowed from XP principles)

Leadtime = average time to move an item across the kanban board
When item sizes vary dramatically WIP can be limited based on the story points instead.
Some teams prefer to break down the tasks in roughly the same time pieces.