agile explained by leandog

Agile Explained

Twitter: @jonRstahl www.jonstahl.com

jon.stahl@leandog.com

Co-Founded 1 Year Ago

Grew up in Pittsburgh, in Clev last 18 years

BS in CIS + Econ Minor

@jonRstahl

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 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

Things on the right are important - Things on the left are more important

Individuals & Interactions over Process & ToolsWorking Software over Comprehensive DocumentsCustomer Collaboration over Contract NegotiationResponding to Change over Following a Plan

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

Some of the 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…

eXtreme Programming

Group Dynamics

eXtreme Programming (XP) Values

Simplicity

Communication

Courage

Feedback

Respect

Business Analyst

Story Card Creation*Story Card Elaboration*

Low-Fidelity PrototypingAcceptance CriteriaFunctional Testing

Card Tracking System

Quality Assurance

Test Plan CreationManual TestingAutomated Regression TestingExploratory TestingDefect Tracking

Engineer

Simple & Evolutionary DesignTest Driven Development

Continuous IntegrationPaired Programming

Technical DebtSpikes

Iteration Manager

Team FacilitatorDemand Management*Release Planning*Iteration Planning*Card Tracking SystemVelocity

* Customer Collaboration

ConceptsWhole Team

Open WorkspacePoly-Skilling

Sustainable PaceBig Visible Charts

Frequent ReleasesStory Card Wall

Kanban

ProcessDaily Stand Up

Iterations / SprintsIteration Planning*

Show & Tell*Retrospectives*

Release Planning*Estimation*

“Do not develop an attachment to any one weapon or any one school of fighting.” - Miyamoto Mushashi, 17th century Samurai

Clear communication is the foundation

“I’m glad we all agree.”

9Source: Thoughtworks

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.”

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

ConceptsWhole Team

Sustainable PaceBig Visible ChartsFrequent Releases

Story Card WallKanban

CONCEPTS

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

Small Large

Developers 7 12

Business Analysts 2 3

Quality Assurance 2 3

Iteration Manager 1 2

Scrum says max size is 7 people

We believe in pairing in all roles

Thoughtworks model

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.

Poly Skilling & Sustainable Pace

• Poly-Skilling / Cross Training / Avoid Silos• Pairing• Queue Limits (Kanban)• Sign up for work

• Sustainable Pace• Hard 40 hours, maintainable pace• Throughput consistency• Avoid mistakes• Card process and limited WIP support this

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 ReleasesDone means Automated Testing CompletedEvery iteration close should be very close to

releasableMay need to do some extra integration & stress

testingCustomer decides when to “pull” releaseLarge Releases = High RiskRelease is most important form of feedback &

Business Value IncrementallyValue is realized sooner

Story Card WallWork in progress, Card is “currency”, must be physicalMust be readable to outside

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

ConceptsWhole Team

Sustainable PaceBig Visible ChartsFrequent Releases

Story Card WallKanban

PROCESS

Daily Stand Up Meetings Team communicates status of its work on a daily

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 Stand Up Meetings 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

Iterations 1 to 2 weeks iterations/sprints

A short (1 to 2 hour) Iteration Planning Meeting kicks off each new iteration. Close the previous

Review cards completed Review current velocity Conduct show & tell Hold retrospective

Open/Start 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

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

Kaizen & Muda

Road BlocksNot Started

In Progress DoneWorked

Could Be Better

Retrospective

Story Card EstimationEstimated 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!

Business Analyst

Story Card Creation*Story Card Elaboration*

Low-Fidelity PrototypingAcceptance CriteriaFunctional Testing

Card Tracking System

Quality Assurance

Engineer

Simple & Evolutionary DesignTest Driven Development

Continuous IntegrationPaired Programming

Technical DebtSpikes

Iteration Manager

Team FacilitatorDemand Management*Release Planning*Iteration Planning*Card Tracking SystemVelocity

* Customer Collaboration

ConceptsWhole Team

Sustainable PaceBig Visible Charts

Frequent ReleasesStory Card Wall

Kanban

“Do not develop an attachment to any one weapon or any one school of fighting.” - Miyamoto Mushashi, 17th century Samurai

Product Owner / Business Analyst

Story Card Creation*Low-Fidelity Prototyping*

Acceptance TestsProgressive Elaboration*

Value Stream MappingPersonas

Card Tracking Process

Story Card Creation 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

Low Fidelity Prototypingmore 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

Acceptance TestsDefines test BA would need to complete in order to

sign off on the card

Two formats to choose fromSimple

Story: Adjust search radius

As a customerI need to adjust the search radiusSo 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” PatternUse if you plan to use behaviour driven development

tools such as Cucumber, JBehave, etc.

Additional Story Card ArtifactsShould include Acceptance Tests

Might includeScreenshot

Formulas with Inputs and Outputs

Workflow rules

Progressive Elaboration

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

Persona Example

Frances Miller

Sixty-seven year-old Frances is the mother of four children and the grandmother of twelve. She lives in her own home, bakes a pie once a week so that she has something to serve for Sunday visitors (usually one of her children and their immediate family), and has two cats. The cats’ names are Fred and Wilma, names given to them by four-year old grandson Bobby. She likes to knit and do needlework, which she either gives away as presents to her family or donates to the annual sale to raise money for the church she belongs to.

Every morning she goes for a one hour walk along the lake front when the weather is good. On bad days she’ll go with her neighbor to the local mall where a group of senior citizens “Mall Stroll” each morning before sitting down at one of the restaurants for coffee or tea. For breakfast Frances prefers a cup of Earl Grey tea and two slices of whole-wheat toast with her own home-made preserves. Lunch is typically a bowl of soup or a sandwich and then she’ll have the opposite for dinner.

She is a middle-class retiree living on a fixed income. Her mortgage has been paid off and she has one credit card which she seldom uses. She has been a customer of the bank for 57 years although has never used an automated teller machine (ATM) and never intends to. She has no patience for phone banking and does not own a computer. Every Monday at 10:30 am she will visit her local bank branch to withdraw enough cash for the week. She prefers to talk with Selma the She prefers to talk with Selma the branch manager or with Robert, a CSR who was a high-school friend of her oldest son.

Source: Scott Ambler http://www.agilemodeling.com/artifacts/personas.htmGreat read!

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 developmen

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

Card Tracking Systems

Scrum Master / Iteration Manager

Demand Management*Product Backlog* Release Planning*Sprint/Iteration Planning*Show & Tell*Retrospectives*Velocity/Cycle TimeCard Tracking Process

Product Backlog

Always lists items adding value for the customer.Includes functional requirements and non-functional requirements.

Cannot include concrete low level tasks and requests for building the intermediate artifacts.

Utilizes the simplest and the most effective way for prioritizing requests - a simple list.

Such a method does not allow for having 100 absolute max priority features and forces the product owner to actually make decisions about the feature priorities.

The higher the items are located on the product backlog, the more detailed they are.

Does not typically include the detailed requirement information.

Ease of use, clear and transparent purpose is what makes the product backlog so useful for seeing into the project status.

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

Iteration/Sprint Planning

Sprint/Iteration CloseShow & TellReview VelocityRetrospective

Sprint/Iteration OpenTarget VelocityReview CardsSign Up for Work

Show & TellMini 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

RetrospectivesHelp 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 FormatWhat didn’t work or was confusingWhat workedDetermine if any changes should be made in next

iteration, create a card for this and get business buy in

VelocityTrack number of units completed in an iteration

Yesterday's weatherBest 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

Cycle Time (Kanban)

Developer

Collective Code OwnershipContinuous Integration

Simple & Evolutionary DesignPaired Programming

Test Driven DevelopmentTechnical Debt

Spikes

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

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!

Technical Debt Every system has debtDon’t hide it, make it visibleAvoid “Cowboy Spaghetti” problems! --->Don’t pay debt – go bankruptAll debt should be justified as business value (VSAM)

Velocity/Cycle TimeScalabilityAvailabilityMaintainability

Anything that makes code hard to changeSloppy / Un-testable codeDependencies (high cohesion & low coupling are

essential for testable code)

Spikes

Football = quick, stop clock, assess situation

Mitigate Risknever done it, don’t

knowjust too large

Estimate the spike like anything else

Discovery

C#/.NET Developer Tools

Write a Failing Test

Write code to make it pass

Continuous Integration

Test Driven Development

Refactoring

Can’t think of any more tests

Team City

ReSharper

Refactor

Quality Assurance

Testing Quadrants

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

Automated Regression Testing•Record & Play •Frees QA to focus on more testing tasks•Enables complete regression testing cycle•Shortens regression testing cycle time from weeks to hours

Selenium

Quick Test Pro

The End Game

Be adaptive, be transparent, seek to

eliminate waste, value people above

all else

Live the values & principles!

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 moral

Survey of 2319 companies taken in 2008

Some Good Reads

“The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails.” - William Arthur Ward

Fire Away! ;)

QUESTIONS only please

Engagement with LeanDog

Software Delivery

Jump Start Programs

Trainers

Coaches

Practitioners

agile explained by leandog

story card

team open

big visible

story card

show amp

constant collaboration

feedback form

extreme programming

Technology

agile retrospectives explained

agile pricing models (webinar by luxoft agile practice)

agile transformation explained: agile 2017 session

agile scrum lean & kanban explained in a flash

santa barbara agile: exploratory testing explained and...

agile explained

agile & scrum qualifications explained · pdf fileagile &...

probiotics explained by oragenics

n hibernate explained by example

mers explained by aurora lawyers

5 myths of agile explained

android: explained by numbers

agile serbia: exploratory testing explained and experienced

mindfulness explained by rick hanson

exploratory testing explained (tampere goes agile - 2013)

biodiversity explained by dr.b.k.sahoo

agile marketing values explained

agile mont kiara property project explained

welcome “agile explained” the agile scrum software...

fractions explained by graeme henchel