Three . . Two . . One . .

WAIT!?!

Deliver

“The Right Stuff”

with

Tested

Quality

code!

Who we are

Paul Carter, CSM, CSP, PMP

• Agile Family Guy

• Scrum Coach & Trainer

Michael Collier, CSM, CSP, CSD

• Musician & Entertainer

• Scrum Coach & Developer

Agile Champions since 2008

3

#scrumdaddy @agilefamilyguy #agilefamily

@pappymcbeard

#agilepirate

www.musicalblades.com

The Elephant

Shared Vision

Jeff Patton / cakewrecks.org

Shared documents are not shared understanding

• Specifying in writing does not work well

• So what does work well?

Vision as Process

Vision as Mindset

People over Process

Culture of Collaboration

Customer Satisfaction

• Understand Customer Impact

• Human Centered Design

• Behavior Driven Development

Not just working software – must delight the customer

Visioning Questions

•Why does the customer care?

•Why is this important to you?

•Do we have a problem worth solving?

•What would that look like?

•How does the customer interact?

•How will the customer react?

•How will the user feel?

•What would happen if you could?

•What’s the first step?

•What is business value?

•What do you want to achieve?

•What is your dream/vision?

•What is our opportunity to impact the

customer?

•What other angles can you think of? Do

we have the right story? Do we need

another story?

•What is this important to the user?

•When will I know when we have it right?

•What is working?

•What does success look like?

•What are you thinking right now?

•How would you socialize this?

•How would you test this?

Visioning Tools: the Pitch and Product Box

Visioning Tool: The Story Map

Prioritized User Story

Additional Details

Ad Categories & Sub-Categories

• Food & Restaurants

• Retail (books, clothing)

• Entertainment General (movies, bowling alley, skating rink)

• Entertainment Sporting Events (Chiefs, Royals, Sporting KC,

T-Bones, Mavericks)

• Entertainment Music

• Entertainment Theatrical

Product Owner Validation

Open app and an ad from first category displays (example food &

restaurants) with message: “Do you want to see more ads like

this”

Customer clicks “Yes” or “No”

Save the responses

Display a different ad each time I open my app until each ad

category has been displayed so I know customer preferences

If I do not respond to the ad when displayed assume that the user

responded “Yes”. No response is assumed acceptance.

Acceptance Criteria

Display ads by category then sub-category

Log “I want to see more of these kinds of ads”

Log “I don’t want to see more of these kinds of ads”

Not responding means “I want to see more of these kinds of ads”

Rotate through the ads with each use of the app. One banner ad

for each time they open the app (based on the list of categories

and sub- categories)

Given, When, Then

Scenario: Display a different ad each time I open my application until each ad category has been displayed and I know my customer preferences Given The customer is a return customer

And has seen Food & Restaurants And has seen Retail (books, clothing) And has seen Entertainment General (movies, bowling alley, skating rink) And has NOT seen Entertainment Sporting Events

When They open the application we would display Entertainment Sporting Events Then

Save their responses to that ad

Unit Test Rules

Unit Tests are

•Fast

•Isolated

•Repeatable

•Self-Verifying

•Timely

It is not a Unit Test if:

It talks to a database

It communicates across a network

It touches the file system

You have to do special things to your environment

(These would be considered

integration tests.)

Unit Test Naming

Should be expressive

Easy to understand

Contain what is being tested and expected results

The team should agree on convention

Unit Test Name Examples

MethodName_StateUnderTest_ExpectedBehavior

IsNew_NewCustomer_True

MethodName_ExpectedBehavior_StateUnderTest

IsANewCustomer_True_IsNew

Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior

Given_CustomerIsNew_When_IsNew_Then_ReturnTrue

Unit Test Names – Bad Example

Not Expressive!

Not easy to

understand!

Process for Writing Unit Tests

Refactoring

Refactoring is:

•The process of changing a software system in such a way that it does not alter

the external behavior of the code yet improves its internal structure.

•A method to make it easier to understand and cheaper to modify code.

Refactoring is not:

•Debugging

•Adding features

•Changing observable behavior

•Performance improving

Benefits of Refactoring

•Improved software design

•Reduced code size

•Confusing code is restructured into simpler code

•Code is easier to maintain

Code smells (refactor opportunities)

Let’s look at our Given, When, Then and go write unit

tests

Scenario:

Display a different ad each time I open my app until each ad category has been

displayed so I know customer preferences

Given the customer is a return customer

And has seen Food & Restaurants

And has seen Retail (books, clothing)

And has seen Entertainment General (movies, bowling alley, skating rink)

And has NOT seen Entertainment Sporting Events

When they open the application we would display Entertainment Sporting Events

Then Save their response to that Ad

[TestMethod]

public void Given_CustomerIsNew_When_IsNew_Then_ReturnTrue()

{

var customer = new Customer();

var expected = true;

// Act

var actual = customer.IsNew();

// Assert

Assert.AreEqual(expected, actual);

} public class Customer { public bool IsNew(long id) { throw new NotImplementedException(); } }

[TestMethod] public void Given_CustomerIsNew_When_IsNew_Then_ReturnTrue() { var customer = new Customer(); var expected = true; // Act var actual = customer.IsNew(0); // Assert Assert.AreEqual(expected, actual); } public class Customer { public bool IsNew(long id) { return id !=1; } }

[TestMethod] public void Given_CustomerIsNew_When_IsNew_Then_ReturnTrue() { var customer = new Customer(); var expected = true; // Act var actual = customer.IsNew(“Jsmith”); // Assert Assert.AreEqual(expected, actual); } public class Customer { public bool IsNew(String UserName) { //Mocked out Customer class and Methods return Customer.FindbyName(UserName); }

Collaborate through Pairing

Build Quality, Fully Tested Product

Great User Stories and Test Driven Development focused on

the customer is your foundation to Quality, Tested Product

•Are all developers confident making changes to the code?

•Do developers have fewer that one debug session per week?

•Are developers nearly always confident that the code they’ve written

does what is intended?

• Is the Product Owner accepting the DONE story each Sprint?

What have we learned?

• Understand the product through collaborative shared understanding.

• Team members are often like the six blind men. We all see things

differently – remember shared documents are not shared understanding!

• Trust and collaboration is essential!

• To test the “The Right Stuff” we must collaborate to know what that is.

• Ask questions to get great User stories with clear acceptance criteria.

• Tie all Unit tests back to the acceptance criteria of the user story.

• If you don’t write your tests first you’re doing it wrong.

• RED – GREEN – REFACTOR – REPEAT

• Refactoring is not rework.

• Quality code now – or fix technical debt later – you decide.

Contact information

Paul Carter

@AgileFamilyGuy

paulmcarter.pc@gmail.com

Michael Collier

@PappyMcBeard

mwctlc@gmail.com

Sources

User Story Mapping

• Jeff Patton

Impact Mapping

•Gojko Adzic

The Art of Agile Development

• James Shore

www.sourcemaking.com

Cleaner code

•Robert (Uncle Bob) Martin

Refactoring: Improving the Design of Existing Code

•Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts