• History of Agile
• Three Methodologies
  • Extreme Programming (XP)
  • Scrum
  • Kanban
• Which one is right for us?

"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. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle."

- Wikipedia.org

• Why did the Waterfall Method fail?

  .

• "The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design." - Friedrich Von Hayek

Agile development techniques have been around for quite a while. Barry Boehm proposed the iterative Spiral Model in 1986.

In 2001, 17 leading luminaries of software methodology met at Snowbird, Utah to discuss the shortcomings of current software development. They published the Manifesto for Agile Software Development.

The Manifesto has Four Values and Twelve Principles.

In 2001, 17 leading luminaries of software methodology met at Snowbird, Utah to discuss the shortcomings of current software development. They published the Manifesto for Agile Software Development.

The Manifesto has Four Values and Twelve Principles.

• The Rational Unified Process, RUP, has 120+ rules (30 roles, 20 activities, and 70+ artifacts)

• Extreme Programming, XP, has 13 rules (Test Driven Development, pair programming, continuous integration, ...)

• Scrum has 10 rules

• Kanban has only 3 rules

• 

• Extreme Programming (XP) is a software development processes emphasizing frequent releases of code, flexibility, communication, simplicity, respect and courage.

• XP was formalized by Kent Beck in 1999.

• Communication - important for creating a sense of team and effective coding
• Simplicity - "what is the simplest thing that could possibly work?"
• Feedback - give feed back frequently and quickly
• Courage - do the right thing
• Respect - "No one is intrinsically worth more than anyone else."

Extreme Programming - Principles

• Humanity
• Economics - software is more valuable when it earns money sooner
• Mutual Benefit
• Self-Similarity
• Improvement - constantly getting better
• Diversity - how to deal with differences of opinion
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Baby Steps
• Accepted Responsibility

• Test First Programming (Test Driven Development)
• Pair Programming
• Continuous Integration
• Incremental Design - a skyscraper starts as a dog house
• Sit Together - in an open space
• Whole Team
• Informative Workspace - lots of charts and stories on walls
• Energized Work - sustainable pace, no death marches
• Stories
• Weekly Cycle - write tests early in week, write code to make them pass
• Quarterly Cycle - plan work in quarterly increments; reflect on process
• Slack
• Ten-Minute Build

• Embrace change - don't grimace when requirements or design changes
• Write the test case first, and then the code.
• After unit testing, do integration testing immediately.
• Key premise: the cost of change is not as high as it used to be
• Be sure to test rigorously and often with automated scripts
• It's important to have snacks and toys around
• Have a morning "stand up" meeting daily
• "Make it run, make it right, make it fast"
• Have an integration machine for testing
• You can implement XP in parts, but won't get near the benefit
• Delete any functionality no longer needed
• Only make a solution for today's problem
• Instead of "If it ain't broke, don't fix it", we improve code when we need it to be better

Image from www.mountaingoatsoftware.com

• Scrum is an iterative, incremental product development framework with emphasis on time-boxed "sprints" by self-organizing teams where the next list of items to do is constantly being updated by business interests.

• Developed by Ken Schwaber and Jeff Sutherland in the mid-1990s.
• Scrum has benefited from great marketing and the Certified Scrum Master program.

• Three Roles - Product Owner, Scrum Master, Team Member

• Three Artifacts - Product Backlog, Sprint Backlog, Burndown chart

• Four Ceremonies - start of sprint, daily standups, sprint review, sprint retrospective

• Product Owner - communicates vision of product, represents the business interests, and does prioritizing, accepts or rejects work results.

• Scrum Master - Is an Agile Coach, removes any organizational barriers preventing work, advises on the Scrum process. This is not a full time job on most projects.

• Team Member - cross-functional, self-organizing, usually 5-9 people, members are full time on project. Team members pick tasks to perform without managers intervention. This can lead to problems.

• Product Backlog - high level list of future product changes
• Sprint Backlog - list of items to do for a single spring
• Burndown chart - shows remaining work to be done

  

  Image from www.mountaingoatsoftware.com

• Daily standups - 5-15 minute status update:
  What I did yesterday, What I'm planning to do today, Roadblocks.
• Start of sprint - planning for the sprint
• Sprint review - demo to the client what was done
• Sprint retrospective - how did the sprint go? What should we Start doing, Stop doing, Continue doing?
  

• Product owner creates prioritized stories, or features.
• The team assigns "story points" to each task, low numbers easy, high numbers hard
• Product owner re-prioritizes stories based on estimates for tasks
• The team estimates how many stories they can do in a sprint
• A sprint start meeting details everything going into the sprint
• Coders work on highest priority items, items don't change after start of scrum
• The team builds a shippable product
• The team demos the product to the business people
• A retrospective is held to improve the process

Image from www.mountaingoatsoftware.com

• Early preview to customers
• Only work on the features that are really needed right now, (not what we think we will need in 3 months).
• Forces automation in releasing since it is done so frequently
• Exposes inefficiencies in process
• Each release improves product and improves the team

• It's hard to get everything into a 2 week period. Some tasks are too big, or very small
• Sometimes a feature is needed now not in two weeks
• Without WIP limits, all the tasks could finish on day 13 with one day left for testing
• Changing to Scrum can be stressful to developers

• Kanban (pronounced 'KahnBahn') is Japanese for "Board", or "Sign"
• Based on the highly successful Toyota Production System
• Kanban helps us visualize the workflow - it's all about the flow through the system
• Kanban reveals bottlenecks dynamically by using Work In Progress (WIP)
• "Cycle Time" is the average time to complete one item. Goal is to make this as small and as predictable as possible.
• Kanban prescribes no roles
• Kanban has no time-boxed iterations. Release once a week, or when something is ready based on MMF (Minimum Marketable Feature set)
• Kaizen - continuous learning
• Kanban board should be visible to all

• What are the columns on the board (e.g., Todo, Ready, In progress, Done, Tested) and how many swim lanes?
• How many items can be in each column (WIP)?
• Who can change what on the board?

• Both are Agile
• Both use transparency to enable process improvement
• Both have self-organizing teams
• You can fail spectacularly with either

• Scrum constrains the time-line, Kanban constrains Work In Progress of flow
• Scrum is more prescriptive - it has more limits
• Scrum measures velocity (points per iteration),
• Kanban measures "Cycle Time" (how fast can we pull an item across the board)
• Scrums allows no new items into the sprint list; Kanban allows for new items, but will push back release date (or trade)
• Scrum provides estimations of completion, Kanban does not
• Scrum has built-in priorities, Kanban does not (Take any item, take oldest, take the shiniest one,...)
• Scrum has cross-functional teams, Kanban does not - could be specialized teams (database, UI, ...)
• Startup costs in Scrum are high, it takes a while to get going. Kanban will gently slip into your current process

• Scrum is your mother-in-law telling you explicitly what you are doing wrong and exactly what you should be doing instead
• Kanban is a quiet shy friend, who hints at your inadequacies and what should be done - but you have to pay attention. You ignore her at your peril.

It depends.

• Kanban is less disruptive
• Many software development shops are moving from Scrum to Kanban.
• Kanban allows continuous deployment
• 

• You may have an XP-Scrum-Kanban or Scrumban methodology
• Continuously experiment (Kaizen)
• Take courage and do what makes sense