A Day in the Life of an Agile Team

YOUR Day in the Life of Agile

• Build a working video game
• We will break for lunch
• We should end by 4:30PM
• There will be an "afterglow" after class

Marshmallow Challenge

• Build the Tallest Freestanding Structure:

  The winning team is the one that has the tallest structure measured from the table top surface to the top of the marshmallow. That means the structure cannot be suspended from a higher structure, like a chair, ceiling or chandelier.

• The Entire Marshmallow Must be on Top:

  The entire marshmallow needs to be on the top of the structure. Cutting or eating part of the marshmallow disqualifies the team.

• Use as Much or as Little of the Kit:

  The team can use as many or as few of the 20 spaghetti sticks, as much or as little of the string or tape.

• Break up the Spaghetti, String or Tape:

  Teams are free to break the spaghetti, cut up the tape and string to create new structures.

• The Challenge Lasts 18 minutes:

  Teams cannot hold on to the structure when the time runs out. Those touching or supporting the structure at the end of the exercise will be disqualified.

Marshmallow Challenge Video

WHERE do you come from?

• Your agile experience?
• Expectations for today?
• Concerns?

Why do plans fail?

Google Maps is wrong: this trip takes longer than 43 hours.

Why do plans fail?

"We're deploying to prod this weekend"

Penny Game

Form Team:

• Business Analyst + Manager
• Developer + Manager
• QA Tester + Manager
• Product Owner
• Executive

Penny Game

Perform Trial:

• Flip coins to perform work (requirements, coding, testing)
• Work is done in BATCHES (flip all coins before passing on to the next phase)
• Product owner touches coins to verify deliverables
• Managers measure total time worked by their employee, from first coin to last coin
• Executive measures time from start until PO verifies first coin & last coin

What did we learn?

• Optimize the Whole:

  Look at ways to optimize the overall process instead of simply trying to optimize individual contributions.

• One Piece Flow:

  Smaller batch size results in greater throughput, mitigates rist, and incurs less waste.

  (Phase Gates → Sprints → Flow)

• Queueing Theory:

  Resist the temptation to fully load resources by splitting individuals across projects. This will result in less total throughput.

• Prioritize Highest Value First:

  Deliver the most important things with less. Early incremental value improves overall ROI.

• Continuous Improvements:

  Servant Leadership is key to allowing teams to continuously inspect and adapt their processes.

Manifesto for Agile Software Development

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.

Principle

"Our highest priority is to satisfy the customer through early and continuous delivery of Business Value"

Value Story

"As a video game startup, I need an early Asteroids game release with basic game play, so that I can get market feedback and start generating revenue."

Value Story

• Specific
• Measurable
• Actionable
• Realistic
• Time bound

Value Story

Make or save the company money.

Defend the market.

Find a market (learn).

Meet a policy or regulation.

Awareness, consideration, conversion, loyalty, advocacy

Value Story Exercise

Think like a CFO. Why invest in instituting an agile process?

• Get most important things done with less
• Reduce revenue or reputation impacting defects
• Mitigate rist and reduce project failure rate
• Respond quickly to market feedback
• Deliver demanded product(s) faster than the competitor
• Innovate to open new market opportunities

As an organization, we want business agility, so that ___

Time to assign teams and choose your game for the day

User Story

A small unit of estimated, prioritized work, with some demonstrable business value, that can be delivered in at most a single iteration.

User Story

• Independent: "Soften dependencies." Acceptance criteria define boundaries.
• Negotiable: Can be changed. Prioritized.
• Valuable: Story is demonstrable and directly contributes to the value story.
• Estimable: All stories are relatively sized.
• Small: 1-2 days; no more than 1/2 sprint.
• Testable: Acceptance criteria are defined as testable scenarios.

Good or Bad?

As a Pac Man game player, I'd like the game to be fun and challenging.

BAD

As a Pac Man game player, I'd like the Pac Man to move around the maze and consume all the dots.

BAD

As a Pac Man game player, I'd like the Pac Man to move left when I press the left arrow key, so that I can move left on the screen.

GOOD

User Story Exercise

Exercise goal: Write as many User Stories on 3x5 cards as you can come up with for your game.

Value Story

"As a video game startup, we want to release a demonstrable game by end of day, so that we can learn if there is a market for it."

User Story Example

"As a game player, I want my rocket to move left when I press the left arrow key, so that I can aboid asteroids."

Are you ready to estimate?

Spike

A time-boxed investigation that addresses unknowns and risks (which prevent confident estimation).

• Example: "As a developer, I want to know how to detect sprite collisions, so that the rocket blows up when it hits an asteroid."
• When time is up for a spike, STOP and analyze the results.
• Results might beget estimable stories or more spikes.

Spike Exercise

Instructions:

• Write your spikes on a different color 3x5 card
• Do not start building your game

Examples:

• How do I move sprites?
• How do I detect collisions?
• How do I integrate Scratch code developed with multiple laptops onto a single laptop?

Scratch Tutorial

Definition of Done

• It compiles on my machine.
• It seems to work on my machine... manually.
• It doesn't blow up when deployed to production.
• All the automated tests (unit, integration, acceptance) run green on my machine.
• My merged code builds and all automated tests run on the CI box.
• Exploratory testing, in addition to static checks, verifies it works.
• The business stakeholders verified it as DONE.
• All automated tests run on the Staging Server.
• The automated tests run green, software deploys automatically to Production and automated smoke tests are green.

Story Points

Estimate effort not duration

Story points are a relative measure of the size of a user story.

Story Points

Size Considerations:

Planning Poker

• A team estimation ritual that harvests the "wisdom of the team"
• Development team gets to decide difficulty to deliver to DONE
• Business gets to decide the priority
• Both collaborate on delivering underlying business value least expensively
• Break down stories into smaller chunks if they don't fit into a Sprint

Time to Size! (for real)

• The product owner presents the story card along with its acceptance criteria.
• The delivery team asks clarifying questions. The team resolves any issues or disagreements that are brought up.
• When ready, the delivery team provides "blind" individual estimates to avoid anchoring. May use "fist of five", planning poker, or other tool.
• The range of estimates is discussed. If there is a convergence the estimate is used. Move on to the next story.
• If the range of estimates is not acceptabe then the extremes are discussed.
• The story is re-estimated until convergence or a go forward agreement is reached. Often teams will have policy to go forward with the larger estimate if convergence is not reached quickly.

Two goofy realities you must face on every project

Business people don't know what they want until they see it.

Technical people don't know how to build it until they've built it.

Iteration

• Iteration (aka Sprint): time-boxed period during which the team, together, delivers working software
• Stand-Up: a daily meeting for the team to checkpoint
• Cadence Day: Demonstration, Retrospective, Planning

Big & Visible Card wall

• The heart and soul of an agile team room
• A living, breathing window into progress, completed work, blockages, spikes, and other work status
• On distributed teams, it is often beneficial to keep a card wall in a central location in addition to using electronic tools

Time for your first development iteration

• Build your card wall
• Product Owner presents desired cards in priority order
• Delivery Team commits to cards they can complete
• Delivery Team works the highest priority cards first
• Product Owners do not code!

Show and Tell Time!

Each iteration is required to deliver a potentially shippable product increment.

The team has produced a coded, tested, and usable piece of software that is technically production ready (aka DONE).

Provide an open demonstration of each completed sotry.

Retrospective

• Safe, open, honest conversation
• Brainstorm items first (do not solve)
• Focus on most important items for the team now
• Agree on 1 or 2 improvement experiments for next iteration
• Inspect and adapt... rinse, repeat

This is our primary self-improvement mechanism. The most vital thing to learn today.

Retrospective Exercise

☺   ☹   ?

• What went well (start with proposals from last retro)?REPEAT
• What might we improve?STOP or DO DIFFERENT
• What is still puzzling us?TALK ABOUT

"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain pace indefinitely."

Velocity

The rate of delivering story points per iteration

Forecasted Duration = #Story Points x Velocity

Velocity

• Keep track of how many story points you complete each iteration... that is your velocity
• A steady velocity often requires a "norming" team, far past "forming and storming"
• Velocity is expected to change
  • Increases as team improves
  • Initially drops when trying new improvements
  • Team size changes
• Forecast adjusts on the Burn Down Chart based on the actual production rate

Project Burn Down Chart

"Will we make our end date?"

Time for your second development iteration and demonstration

20 Minutes

Show and Tell time!

Demo your working stories

"Business people and developers must work together DAILY throughout the project."

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Cross Functional Team

Cross Functional Team

Business

• Provides the vision
• Owns the business case
• Empowered to:
  • Drive acceptance criteria
  • Provide business verification
  • Set priorities
  • Make tradeoffs

Cross Functional Team

Delivery

Includes members with all the necessary skills and expertise to deliver and feature the customer needs end to end.

• Feasibility
• Lowest cost solution
• DELIVERY

Cross Functional Team

User

POs and even SMEs are proxies for the end user.

• "I am not the target user"... try personas
• Make opportunities for real end user feedback
• Usability: Is there a market? Will they use it?

Gantt vs. Burn Down

Key Difference: Burn Down measures output

Counting Story Points

Time for your final development iteration and demonstration

20 Minutes

Show and Tell time!

Demo your working stories

Goals for Teams

• Output/progress is measured on a team level, not on an individual level
• New work comes to the team, over teams getting formed around new work
• What does the team commit to getting DONE this iteration?

Quality Assurance

Test within the Sprint

• Business Verification
• Specifications as Tests
• Test Driven Design

Quality Assurance

Pairing

Pair Programming

• Two people at one station
• One writes code while the other reviews/observes
• While reviewing, the observer is freed to consider the big picture

Pairing

More than assuring the quality of code

• Story breakdown
• Communication practices
• Training new team members

Big Visible Charts

• Material artifacts in our environment (team roon) that carry information make it easier to comprehend complexity
• If you want to improve something, measure it
• If you make a problem visible, it will resolve itself
• Chart what you care about, what you worry about, what you want other people to know
• Is the build broken? Is there lots of technical debt? Is the team/product owner happy? Are we all in denial?

Big Visible Charts

vs

What is the chart telling you?

What is the chart telling you?

What is the chart telling you?

Is the codebase healthy?

What is the chart telling you?

Is the Product Owner happy?

Which of these practices are you still unclear on?

Transformation

Round Table Discussion

Why would this "never work in your organization"?

Class Survey

Please take a few minutes to complete a class survey

Class Retrospective

Thank You

www.pillartechnology.com