Agile Explained by LeanDog

Agile Explained Jon Stahl

Agenda
Introductions
Your Expectations
Video
Key Concepts
Key Processes
Lunch
Kanban Explained
Process Check
Scrum vs. Kanban
Product Owner Practices
Team Facilitator Practices
Quality Assurance Practices
Engineering Practices
Feedback Form
Take a Book

[email_address] Co-Founded 2.5 Years Ago Grew up in Pittsburgh, in Cleveland last 18 years BS in CIS + Econ Minor @jonRstahl

“ The Kearsarge” A Steamship built in 1892 Our office/boat

“ The Deep Dive” - 1999 How does the process of designing a better product work? What does a process AND a culture look like?

Process + Culture := Sustainability
“ Build a culture and a process, that's what companies really want”

What is Agile?
Term “Agile Methods” adopted in 2001
Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming
Sympathetic to the need for an alternative to documentation driven, heavyweight software development processes
Experts gather at a ski resort in Utah
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Values and Principles !!!!!

Agile Manifesto

Agile Principles
Deliver software in short increments
Expect and encourage change
Constant collaboration with customer
Continuous attention to technical excellence
Simplicity
Self organizing teams

Leandog Studies…
Scrum
eXtreme Programming
Lean
Group Dynamics

eXtreme Programming (XP) Values
Simplicity
Communication
Courage
Feedback
Respect

5. Alistair Cockburn, http://alistair.cockburn.us/Oath+of+Non-Allegiance

CONCEPTS Concepts Whole Team Open Workspace T-Shaped People Sustainable Pace Big Visible Charts Frequent Releases Story Card Wall Roadblocks Process Scrum Framework Product Backlog Story Card Writing Estimation/Sizing Release Planning Sprint/Iterations Sprint/Iteration Planning Daily Scrum/Stand Up Show & Tell Retrospectives Velocity Customer Collaboration Kanban

Whole Team
All skills necessary for project to succeed should be on the team
Team composition should be dynamic
The team must be self empowered
The right people in the right seats
They are led, not managed
They communicate and collaborate continuously
They are accountable for the results

Whole Team Worksheet
Use this template to begin to reorganize your group into an Agile Team

Open Workspace
Facilitates constant communication
Builds the sense of team
Should be set up for pairing
Parents Ear: Silence or kicking/screaming = bad
Lose the sensory deprivation chambers
Note: This is the hardest practice to adopt, but most rewarding when done.

Open Space

T-Shaped People
T-Shaped / Cross Training / Avoid Silos
Pairing
Queue Limits (Kanban)
Sign up for work

Sustainable Pace
Ensures the team has time to plan, think, rest, and deliver effectively
Hard 40 hours, maintainable pace
Throughput consistency
Avoid mistakes
Card process and limited WIP support this
Sustainable fun is evident in room

Big Visible Charts
A display posted in a place where people can see it as they work or walk by.
It shows readers information they care about without having to ask anyone a question.
This means more communication with fewer interruptions.
Large & easily visible to the casual, interested observer
Understood at a glance
Changes periodically, so that it is worth visiting
Is easily kept up to date

Clear communication is the foundation “ I’m glad we all agree.”

Get those mental models out on the table “ Ah...”

An explicit model allows convergence through iteration “ Ah!”

A genuinely shared understanding “ I’m glad we’re all agreed then.”

Big Visible Charts
Information radiators, transparency
Should include:
Story card wall
Road block board
Burn Down Charts
QA status
Production stats
Retrospective items
Should also include anything necessary to keep team and customer informed on status and progress

Frequent Releases
Done means Automated Testing Completed
Every iteration close should be very close to releasable
May need to do some extra integration & stress testing
Customer decides when to “pull” release
Large Releases = High Risk
Release is most important form of feedback & Business Value Incrementally
Value is realized sooner

Story Card Wall
Work in progress, Card is “currency”, must be physical
Must be readable to outside

Roadblocks
Displayed on the wall in each team area
Are prioritized
Reviewed at end of each iteration/sprint
When in progress there should be a owner of the card

PROCESS Concepts Whole Team Open Workspace T-Shaped People Sustainable Pace Big Visible Charts Frequent Releases Story Card Wall Roadblocks Process Scrum Framework Product Backlog Story Card Writing Estimation/Sizing Release Planning Sprint/Iterations Sprint/Iteration Planning Daily Scrum/Stand Up Show & Tell Retrospectives Velocity Customer Collaboration Kanban

Scrum Framework Daily Stand Ups Sprints

Product Backlog
Should be Visible
Must be prioritized
Backlog is organized by business value
Backlog is regularly reviewed and maintained
Does not include vacations, meetings or other items not pertaining to the product
Just enough product backlog to create product without unnecessary features
Story Cards are the backlog

Story Card Writing
They are the unit of deliverable for an Agile team
They are a sentence or two describing a set of new functionality
Must be testable and should include acceptance criteria
The details are elaborated via conversation between the customer, developer and QA
Start of a conversation

Story Card Writing
Independent
Negotiable
Valuable
Estimable
Small
Testable

Estimation & Sizing
Estimated as T-Shirt Sizes:
Extra Small < 1 Day 1 Unit
Small 1 – 2 days 2 Units
Medium 3 – 4 days 4 Units
Large 5 – 6 days 8 Units
Extra Large 7 – 10 days 16 Units (Never!)
Coding Estimate Only
Assumes relative complexity correlates to analysis & QA effort
Sizing ! – Therefore we talk in units!
Ideal day estimates, we will measure what reality is
Each size is double the size of the previous

Poker Planning
All Developers take a set of cards
Take the team average
Do it fast, do it often
“ Cheap” to do
Things always change (people, systems, customer vision)…
Therefore estimates should too
Adaptive, not predictive!

Release Planning
Large Sheets of paper
Each sheet represents one iteration
Put “guessed” velocity in units at top
Begin to lay out cards in feature importance order
Cannot go over unit limit
When done, tape cards down
Enter into Story Card management system
Produce burn down charts
The team should review plan and ask the following questions…
Enough work for all pairs?
Any pairs stepping on others?
We should play highest risk cards first, are we?
Do we have the most valuable features coming out first?
Any dependencies we are missing?

Release Planning

Sprint / Iterations Planning
1 to 2 hour Iteration Planning Meeting
kicks off each new iteration
Close the previous
Conduct show & tell
Review current velocity
Hold retrospective
Open the new
Available work hours and set velocity target
Review business intent for new cards
Re-estimate cards if necessary
Determine what fits into this iteration
Sign up for cards

Daily Scrum / Stand Up
Team communicates status of its work on a daily basis
Team members report:
What they did yesterday
What they are going to do today
Any concerns or road blocks they are facing
Each update is very brief
15 minutes for whole team

Daily Scrum / Stand Up
They reduce the need for full blown team meetings
They encourage accountability because team members are aware of all work going on
They allow for mid-course corrections
The encourage the team to solve problems on their own
Managers hear about road blocks early

Show & Tell
Mini UAT of software for Customer
Developers usually drive
Team gets to hear customer feedback
Team “see’s the whole” of the software, stays in synch
Customer can prioritize changes immediately
Accountability to customer and satisfaction

Retrospectives
Designed to help a team find ways to improve what they do
Should be held at each IPM
What worked? What didn’t work?
Team votes if items discussed during the retrospective should become cards to be played in the coming iteration
Courage, Communication, Respect

Retrospectives
Help develop continuous improvement cycle
Should be held every iteration, in IPM is ideal, have as frequent as necessary
Make action items visible
Ensure courage, communication and respect are adhered to
Basic Format
What didn’t work or was confusing
What worked
Determine if any changes should be made in next iteration, create a card for this and get business buy in

Velocity
Track number of units completed in an iteration
Yesterday's weather
Best estimate of what you can complete in the current iteration is what you completed in previous iteration
Plan using trailing average, 3 two week iterations
Estimate time based on velocity
Don ’ t compare teams

Customer Collaboration
In Agile the customer drives everything
Requirements
Prioritization
Review of work
completed
Not always possible to have customer on site
Should have customer surrogate

Kanban
Kan means "visual," and ban, means "card" or "board”
Uses cards to signal the need for an item.
3 Rules: Visible, Strict Queue Limits, Pull Value
Measure time for each card size to flow through all steps

Manage to Learn, Servant Leader, Team Facilitator, Intellectual Honesty, Passion for Learning

A3
Regular Management Retrospectives
Communication of Strategy, ensures everyone understands the strategy
Use a A3 Paper
What objectives do you have in place?
Do you have countermeasures in place?
Did you go to the gemba?
Are understood and visible to whole team
5 why method is applied
Encourage reading, buy and distribute reading material to team
Have lunch and learns
Attend your group’s show and tells periodically

Exploratory Testing
Manual tests that occur after story is developed
Used to catch the edge cases that aren’t caught in automation
Is part of the quality strategy for a team or a project
Involves the tester before the story card is implemented
Is context driven

Automated Regression Testing
Agile teams deliver working software at the end of each iteration
QA team must perform full regression test each iteration as well as testing new functionality
Usually not possible without Automation
QA should:
Write manual test plan during story card elaboration
Execute manual test plan when story is ready
Once manual test passes automated test should be created and added to test suite

Testing Quadrants

Collective Code Ownership
Any developer can change any piece of code at any time
Necessary to support continuous integration
Helps to eliminate “specialization” within systems

Continuous Integration
Integration is a risky time for any project
Agile teams mitigate this risk by doing integration all of the time
Should happen at each developer check in (several times per day)
Software is built and all automated unit tests are run against the build
Dependencies are resolved and full integration takes place

Simple & Evolutionary Design
The system is not designed up front – instead the system is designed at all times to support current application needs
Emphasis is placed on simple architectures and designs that provide adaptability to change
Simple designs also allow teams to have increased velocity as they are spending a greater percentage of their time providing customer value

Paired Programming
Build quality in with constant collaboration and code review
Increase productivity due to two minds solving a problem
Knowledge moves across team more quickly
Ensure best practices are followed

Test Driven Development
Developers write a test prior to writing application code
Tests ARE documentation, never stale, mirror logic
Places more emphasis on testing and quality during development
Reduces the number of defects that make it to QA
Simplifies design of application due to small incremental coding steps
Tests allow for fearless refactoring of system – it’s a instant feedback loop!

C#/.NET Developer Tools Start Write a Failing Test Write code to make it pass Stop Continuous Integration Test Driven Development Refactoring       Can’t think of any more tests Team City ReSharper Refactor 

Technical Debt
Every system has debt
Don’t hide it, make it visible
Don’t pay debt – go bankrupt
All debt should be justified as business value (VSAM)
V elocity/Cycle Time
S calability
A vailability
M aintainability
Anything that makes code hard to change
Sloppy / Un-testable code
Dependencies (high cohesion & low coupling are essential for testable code)

Spikes
Football = quick, stop clock, assess situation
Mitigate Risk
never done it, don’t know
just too large
Estimate the spike like anything else
Discovery

Low Fidelity Prototyping
more likely to give constructive feedback about the important aspects of the UX than if they were presented with a high-fidelity prototype or near complete version of the software
Light weight, no tools, fast
Build the software and let them touch it
Adapt

Acceptance Tests
Defines test BA would need to complete in order to sign off on the card
Two formats to choose from
Simple
Story: Adjust search radius
As a customer
I need to adjust the search radius
So I can increase or decrease the number of search results
Acceptance Criteria
Restrict customer to selecting 10,20,30, and 40 miles
If no customers in that radius, show message stating no agents found
If more than 15 agents, show all agents in radius
See mockup #2

Acceptance Testing “Given When Then” Pattern
Use if you plan to use behaviour driven development tools such as Cucumber, JBehave, etc.

Additional Story Card Artifacts
Should include Acceptance Tests
Might include
Screenshot
Formulas with Inputs and Outputs
Workflow rules
Confidential. Copyright 2009 LeanDog, Inc. All rights reserved. Do not copy or distribute without permission.

Value Stream Mapping
Flow of activities that starts with a customer in need and ends when the need is satisfied
Problem  ------ Value Stream -----  Solution
Source: Michael Nygard http://www.michaelnygard.com/blog/2008/02/ Great read on value stream of Waterfall vs. Agile

Personas
You don't "make up" personas, but instead discover them as a byproduct of your requirements investigation
Write specific personas: you will have a much greater degree of success designing for a single person
The "generic user" will bend and stretch to meet the moment, but your true goal should be to develop software which bends and stretches.
Your personas should "wiggle" under the pressure of development
You want to know what the persona's goals are so that you can see what your system needs to do, and not dot
Sometimes you want to identify negative personas, people that you are not designing for. A primary persona is someone who must be satisfied but who cannot be satisfied by a user interface that is designed for another persona.
If you identify more than three primary personas your scope is likely too large.
You want a finite number of personas, your goal is to narrow down the people that you are designing the system for.
Alan Cooper, The Inmates are Running the Asylum

Personas

Story Mapping
Early stage of progressive elaboration
Team uses post-it notes to depict the features and their flow in the system

How well does it work?
The benefits most widely cited by the participants:
93% Enhanced ability to manage changing priorities
83% Improved project visibility
74% Increased productivity
74% Improved team morale
Survey of 2319 companies taken in 2008

“ The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails.” - William Arthur Ward Fire Away! ;) Please fill out your feedback form so we can adapt and improve! Open Discussion & Acceptance Criteria Review

Engagement with LeanDog
Software Delivery
Jump Start Programs
Trainers
Coaches
Practitioners

http://leandog.com	205
http://www.leandog.com	143
http://localhost	40
http://www.linkedin.com	7
http://www.lmodules.com	5
http://www.slideshare.net	4
http://jonstahl.posterous.com	3

Agile Explained by LeanDog

by LeanDog

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 407

Statistics