Introduction to Agile

& Scrum

a starting point for discussion


Amber Doctor

amberdoctor@gmail.com

What is Agile?


Webster's Dictionary
  1. able to move quickly and easily
  2. quick, smart, and clever


Exploring Scrum: The Fundamentals
  1. The act of basing actions on current reality,
as opposed to being predictive or plan-driven.

What is Waterfall?



Wikipedia
  1. a sequential design process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.

White Board Drawing

It'll look kinda like this for those of you online:

Agile Over Waterfall?


  • When there is a high amount of discovery
  • When the product development is complex
  • When flexibility is needed
  • When delivering smaller incremental stages of project is preferred

"No plan survives first contact with the enemy."  -- Moltke

"Walking on water and developing from a specification are easy if both are frozen." --Edward Berard

Agile Manifesto

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

http://agilemanifesto.org/

What is Scrum?


  • "an iterative and incremental agile development framework for managing product development" - Wikipedia
  • "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" - Wikipedia
  • "an agile framework ( or process ) for Product Development, not Project Management" - Exploring Scrum: The Fundamentals
  • "a social agreement to be empirical as a team" - 3Back


Flow



  1. to issue or move in a stream
  2. to move with a continual change of place among the constituent particles
  3. to proceed smoothly and readily
  4. to derive from a source
  5. to deform under stress without cracking or rupturing

Scrum Roles


Roles on the Team include:

  • Product Owner
    • "Champions/Focus for the Product"
  • Scrum Master
    • "Health of the Team"
  • Development Team
    • "Intellectual Muscle / Horse Power"

Product Owner

"Champions/Focus for the Product"


  • PO champions a quality product
  • PO gathers the feedback from stakeholders, distills it, and translates it
  • PO focuses's team's attention
  • PO provides a single voice for the business and stakeholders to the development team

"If we'd asked the customer's what they wanted, they would have said 'faster horses'."   -- Henry Ford

Scrum Master

"Health of the Team"

  • SM is the member of the team who is accountable for ensuring Scrum is used in a positive way
  • SM ensures that the Team is constantly improving its use of Scrum
  • SM is a Servant Leader
  • SM is not a product manager (this role does not exist in scrum)
  • Must be a separate role from the PO because the goals conflict and too much power

Development Team Member

"Intellectual Muscle / Horse Power"

  • Creates the Project
  • Includes UX, Design, Copy, Software Engineers, Testers, etc

Characteristics of a Well Formed Team


  • Self Organizing
  • Self Contained
  • Value Driven
  • Cross Functional
  • Trust
  • Swarm on stories
  • Have a "polling" relationship
  • No head works alone
  • Acknowledges problems to solve (not blame game)
  • Respect

Scrum Process Outline

  • Sprint Planning
  • Sprint
    • Daily Stand Ups
      • Reports/Metrics/Impediments
    • Sprint Iteration
  • Deliver Increment of Demonstrably Done Reviewable Work
  • Sprint Review
  • Sprint Retrospective
  • Progress Assessment
  • Repeat

Sprint Retrospective

Incremental Improvement

The Team analyzes their own sprint process
and modifies it as necessary

  • What went well?
  • What could be improved?
  • Translate "What could be improved?" into an actions

Scrum helps you discover areas for improvement -- it doesn't prescribe how to solve problems that your team uncovers.  That's for the team to decide together.

Sprint Retrospective Exercise


  • Get together with the team
  • Silently brainstorm on note cards areas for improvement
  • Read the cards out loud for the team
  • Pick 1
  • As a team come up with an action plan


There's other methods for running a sprint retrospective, this is just one to get you started.  Try Agile Retrospectives by Esther Derby and Diana Larsen for more.

Technical Debt

the enemy of agility

Consists of deficiencies in the code, technical documentation, development environments, 3rd party tools, and development practices, which makes the code hard for the Team to change.

Occurs when:
  • High quality standards are not enforced by the definition of "Done"
  • Cutting corners when trying to meet impossible deadlines
  • Management pushes work through the system rather than allowing pull

Pay Off Technical Debt

Why:
Technical Debt is like a broken window on a car
A car can sit for weeks without anything bad happening to it.  
Brake one window and in hours the car is stripped.
http://en.wikipedia.org/wiki/Broken_windows_theory

How:
  • Address Technical Debt when you discover it
  • Track Technical Debt when it can't be fixed immediately
  • Allow time in your development process to address known technical debt

Play a Game

Rules:

  • The paper must be placed in the bin
  • Everyone must touch the paper before it's placed in the bin
  • No one can touch the paper at the same time
  • The paper must have air time

Estimation Bargaining


Effort is like Mass, it's a physical property of a project.
Given a set of requirements you are going to have to do a certain amount of work to achieve those requirements.

If you agree to do the same amount of work in less time, you don't change the amount of effort it takes, you just have less time to do it.

Change scope (the requirements) to reduce the amount of time.

http://monkeyandcrow.com/blog/estimation_bargaining/

Adding More People


Work accomplished doesn't scale linearly with increasing the number of people.

For every person you add, you increase the amount of communication.

There's also a critical path to development work 

9 women can't make a baby in 1 month

A good team size can be fed with 2 pizzas  (7 - 9 people)

For Later Discussions


  • More in depth look into Sprint Cycle
  • Epics, Stories, Tasks
  • Story Size and Value
    • aka pointing stories
  • Impediments
  • Daily Stand

Introduction To Agile

By Amber Doctor

Made with Slides.com

Introduction To Agile

  • 2,274

More from Amber Doctor