practical scrum course day 1

Scrum Workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Practical ScrumDay IIlan Kirschenbaum

Agile coach co-founder at Practical Agile

co-founder at Agile Practitioners twitter: @kirschi_

email: [email protected] blog: http://www.practical-agile.com/theblog

http://www.practical-agile.com/

https://www.linkedin.com/groups/81807

mailto:[email protected]

http://www.practical-agile.com/theblog


Connection before content


Parking lot


Physical examination


Agenda

• Introduction

• Overview & History

• Self managing & Empirical approach

• Scrum overview

• The Scrum Master

• Transparency

• Definition of DONE

• Waste

• A Scrum team

• Reduce Waste

• Engineering practices


Requirements

Design

Implement

Test

Acceptance

Analysis

Deliver


Question


The waterfall development model originates in the manufacturing and construction industries

The first description of waterfall is a 1970 article by Winston W. Royce

Royce presented this model as an example of a flawed, non-working model

"I believe in this concept, but the implementation described above is risky and invites failure"

[Royce 1970]


QThe harder we plan and analyze in the beginning, the less there’s

change in the project and the more successful the project.

There is change always and responding to it is vital. Uncertainty is best reduced by

learning from actual implementation


Wishful thinking


"Scrum is a team of eight individuals in Rugby. Everyone in the pack acts together with everyone

else to move the ball down the field in small incremental steps. Teams work as tight, integrated units with whole team focusing on a single goal."


Origins of Scrum

• Toyota’s lean concept.

• 1986 – The new, new software development game (Takeuchi & Nonaka).

• Iterative & incremental development.

• Smalltalk engineering tools.

• Jeff Sutherland.

• Ken Schwaber.


Toyota’s Culture

• “Toyota sincerely believes that teams are more effective and efficient than the sum of individuals, and that when they are given the skills and systems of problem solving, the sky is the limit” [Liker\Hoseus 2008 – Toyota culture]


Origins of Agile

20011970

Agile manifesto

Weinberg: Psychology of computer programming

Rapid Application Development

1980

1990

1995

DSDM

Extreme Programming

Scrum

Gilb: Principles of Software Engineering

deMarco: Peopleware

Royce:Managing the development of large software systems

Cockburn: Surviving OO projects

lean


Exercise


Agile Principles 1…6

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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


Agile Principles 7…12

7. Working software is the primary measure for progress.

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

9. Continuous attention to technical excellence and good design enhances agility.

10.Simplicity – the art of maximizing the amount of work not done – is essential.

11.The best architectures, requirements, and designs emerge from self-organizing teams.

12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Scrum Misconceptions

• Scrum != Adhoc

• Disciplined & structured. Not sequential.

• Not an excuse to be sloppy!

• Scrum != A Set of practices.

• Don’t do agile, Be Agile, do Scrum.


Where Scrum Fits


Self Management


Exercise


Predicted vs. Empirical

• Empirical means we base our actions on our own experience not on someone else’s.

• Requires high level of transparency.

• Facing our real problems requires a high level of integrity.

• It take courage to change our habits.


–Wolfgang Puck - chef

“The biggest difference between home cooks and professional chefs is that home cooks don't taste the dish often enough as they prepare it.

They just follow the recipe step-by-step, without getting that feedback along the way. ”


• In our industry people got used to create and use META solutions to problems.

• The problems we are facing have nothing to do with technology, it is a people issue.

• In this land the basic assumption is that there is no META solution, just an empirical framework to allow inspect & adapt cycles.

• This experience is frustrating for those who are looking for predefined processes and final answers.


Exercise


Scrum


Scrum Principles

• Understanding that we cannot predict the future.

• One size does not fit all.

• Constant improvement.

• Transparency & Visibility

• Team work

• Deliver business value fast (max. 30 days)

• Prioritizing – Industry statistics show: 65% of all features are rarely\never used.

• Empirical approach

• Fun !!!


Who’s Using Scrum?

• Intel

• Microsoft

• Yahoo

• Google

• Electronic Arts

• High Moon Studios

• Lockheed Martin

• Philips

• Siemens

• Capital One

• Boeing

• HP

• Clal Insurance

• Amdocs

• BMC Software

• sviva.gov.il

• Compedia

• Verint

• LivePerson

• Oracle

• eBay

http://sviva.gov.il


Scrum is Used For…

• Commercial software

• In-house development

• Fixed-price projects

• Financial applications

• ISO 9001-certified applications

• Embedded systems

• 24x7 systems with 99.999% uptime requirements

• the Joint Strike Fighter

• Video game development

• FDA-approved, life-critical systems

• Satellite-control software

• Automobile R&D and Manufacturing

• Handheld software

• Mobile phones

• Network switching applications

• Some of the largest applications in use


Scrum Process Overview

Sprint backlog

Working software


Scrum Process Overview

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint retrospective•Daily scrum meeting•Sprint review

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts


The Product Owner

• Defines the features of the product

• Defines release dates and content

• Responsible for ROI

• Prioritizes feature according to value

• Can change features and priority once every predefined interval

• Decides what will be worked on in each iteration

• Accepts or rejects results


The Team

• Cross-functional, Typically 5-9 people

• Provide estimate for the tasks

• Decides how much it can do in each iteration

• Decides how to reach the sprint goal within the project’s boundaries

• Organizes itself and it’s work

• Presents results to the product owner


The Scrum Master


The Scrum Master

• Responsible for the scrum process

• Ensures that the team is functional and productive

• Protects the team

• Helps removing impediments

• He is standing at the nexus between:

• The product management that believes that any amount of work can be done

• Developer’s that have the willingness to cut quality to support the managements belief


The Scrum Master

• Help the product owner to understand how to maximize ROI within the Scrum process

• Improve the life of the team by encouraging creativity and empowerment

• Help the team to improve the productivity

• Help the team to improve their engineering practices so that we have a working product increment at the end of every sprint

Holds a management position but… is not a manager! – a facilitator\leader


The Scrum Master

• Is not a team leader or a project manager

• Team is self organizing

• Has no authority over the team or the product owner

• Asking questions / making observations

• Challenges the organization, a change agent

• A dead Scrum master is a useless Scrum Master


A different Management Style

• Traditional managers (Supervisors):

• Assign task and verify completion

• Micro manage to have the “illusion of control”

• Makes decisions for the team

• Limit the information & resources available to the team

• Traditional managers (Supervisors): DO NOT TRUST THE TEAM!

• This creates an environment which blocks innovation and encourages conformity

• The transition from manager to SM is extremely hard


Ask the Team!

• Replace suggestions with questions.

• What do you think we should do?

• What have you decided?

• What do you think this means?

• Who has any idea about….?

• Is this thing useful ?

• Replace opinions with observations.

• I noticed that <fact>, what shall we do?

• I have seen that <observation> is that important?


The Team is Wrong(?)

• Sometimes failing is the only way to learn

• Let the team fail

• Create an environment where it is ok to fail

• Failure amplifies learning

• Where failure is allowed, innovation and experiments are encouraged

• Increases trust

• Are you sure you are right ?

• All of us are smarter than any of us


Exercise


Ofer Eini’s Project(1)

• Ofer had realized tickets for popular soccer games are being sold on EBay for as much as 100 times the price.

• Ofer decided to start a campaign for prohibition by law of reselling tickets for profit unless done through a specially dedicated system.

• The law was passed.

• This system is similar to EBay in principle, whenever a bid is over, after the money had been transferred, the seller gets a check in the mail with the price the ticket was sold minus 25% commission to the union.



• The law will be affective within three month, Ofer scheduled a press conference for one month from now and hopes to be able to show some functionality.

• In 3 month the system should be up:

• Allowing buyers and seller to register.

• Sellers can make tickets available at full price.

• Buyers can use a credit card to buy tickets, with the union as “middleman” getting 25% of the deal.

• Ofer is willing to invest funds in this product, you can do whatever is needed to have a working system including, outsourcing, buying s/w modules or develop it.

• Ofer would like your assessment regarding the chances of achieving these targets.



• Functional requirements:

• Register and maintain an account of sellers with userid and password for identification.

• Register and maintain an account of buyers with userid and password for identification.

• Allow buyers to store credit card and shipping details.

• The accounts should include personal information such as name, age, id number, email, address, birthday.

• Place tickets for auction, monitor the auction.

• Search feature by match\team\date.

• Email notifications for events such as auction complete, auction started, winning\losing in an auction.

• On line support for buyers\sellers.

• Chat window.

• More Functional Requirements

• Transfer 25% of each transaction to the union’s account.

• Support promotions and advertising.

• Administration capabilities like delete users.

• Support updating latest news from the union.

• Non-functional requirements:

• Support 10,000 simultanious users.

• Response time under 300mSec.

• Secure financial activity according to standard IEEE76.2s

• 95% up time.



• Development (facts)

• Microsoft platform

• .NET environment using SQL server DB

• Development is co-located.

• Developers are sitting in cubicles.

• The team that will be doing it is considered a good one.

• All team members like soccer (Maccabi fans)

• No automatic build\test systems exist.

• You have a good QA team.

• Scrum will be used for this project.



• The union already invested $34m in passing the law and developing the requirements.

• The law will be effective in three month.

• Ofer needs your team to build the system so it will at least allow people to buy and sell tickets, otherwise the law will be useless.

• Money is not a problem.

• Ofer wants to know: Can your team build this skeletal system for him? The unions marketing division wants to set the press conference to one month, do you agree? What should he announce in this conference ?


Exercise


Transparency

• We should stop taking risks for our customers without even letting them know.

• We should share the risk

• maximize the chances of success.

• Create a common interest.

• We should really know the status of our projects, and share it with the customer.


Transparency


Transparency

• It is important to know how is our project really coming along

• Avoid the 90% done syndrome

• It may mean facing hard facts. Early

• Unfinished work is waste

• We achieve this by:

• Having working s/w at the end of the iteration

• Tracking progress with burn down charts


Burndown ChartEf

fort

rem

aini

ng

0

25

50

75

100

Sprint

1 2 3 4 5 6 7 8


Gantt charts

Hierarchy

Low Quality

Core code

What Reduces Visibility?


Core Code

• AKA infrastructure or legacy code

• Most functionality depends on it

• Usually fragile, does not have a test harness

• only a few people really know it

• Changes are time consuming

• Becomes a bottleneck


Technical Debt

Time

Work left

20

10 12 14 16 18


QYou can save time by “good-enough” development.

Any technical debt will slow development down and thus we don’t allow technical

debt to accumulate.


Definition of Done


Exercise


Definition of Done

• Terms of satisfaction of the product owner

• Defined by the PO with the team

• Example:

• Design, code, unit tested, integrated

• Code coverage, system tests

• Refactored, deployable

• Done is a mirror reflecting the technical abilities of the team

• Items that are not Done “do not count”


Expanding the Definition of Done

Designed

Coded

analyzed

Unit tested

Perf. tested

Code coverage

Live

Deployable

Acc. tested

*This is just one example


Undone Work

Undone Undone UndoneUndone

Stabilization sprint(s)

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Undone = risk

Undone = no visibility Can we

release ?


Ball point game


Scrum Teams


What Makes a Team

• Common purpose, basic task, Interdependent

• Common goal

• We ALL are responsible for reaching the WHOLE goal

• Team members need each other to reach the goal

• Complementing technical and social skills

• The team is more than the sum of it’s members

• Trust

• Commonly agreed ways of working


Scrum Team

• Self organizing – Team manages itself

• Typically 5-9 people

• cross functional

• Preferably a feature team

• Decides how much it can do

• The team is responsible for the outcome


Exercise


The Team is Responsible

• Biggest concept change is:

• The team decides what it can do, and how to do it

• The team is responsible for the quality

• The team is in charge of getting the work done, it decides how

• All of the other roles in the scrum are there to provide the team all of the things it needs to get the job DONE in time

• If the job is successful, the team gets the credit

• If the job is not DONE, the team is responsible


Obstacles to Team Growth

• Strong leadership (c&c)

• Lack of authority and responsibility

• Fear of errors

• Lack of trust

• Fear of conflict

• Lack of boundaries


QDivision of work to specialized teams (specification, design and

testing) is efficient

Cross-functional teams reduce the amount of handovers and are more productive


Becoming a Team

Workgroup Team Self Organized Team Self Directed Team

Bruce Tuckman’s Model of Team Development


Team Decision Making - Thumb Vote

• The rules are simple:

• Thumbs up – I agree completely, this is the best solution (how come I did not think of that one…)

• Thumbs down – NO! This is a mistake, I veto this option.

• Thumbs in the middle – I don’t have any strong opinion. I’ll go with the team.

• Everyone can veto, it’s the team responsibility to reach a decision.

• If someone veto’s ask:

• How can we refine this option so you will agree.

• Why do you think this is the wrong choice.

• Do you have another option


Team Decision Making - Dot Voting

• Used to choose from several available options.

• Can also be used to prioritize.

• Depending on the number of people and options, each person gets <x> points.

• After the options are clear each person distributes his points between the options as he likes.

• Can even place all votes on a single option.

• When everyone finished we have a clearer picture of which options the team prefers.


Reduce Waste


Kaizen

• Mindset:

• My work is to do my work and to improve my work.

• Practice:

• Choose and practice techniques the team has agreed to try, until they are well understood—that is, master standardized work

• Experiment until you find a better way

• Repeat forever


Kaizen - Reduce Waste

• Value: The moments of action or thought creating the product that the customer is willing to pay for.

• Waste: All other moments or actions that do not add value but consume resources.

• value ratio = total-value-time / total-cycle-time


Types of Waste - TIMWOODSTransport

Inventory

Motion

WaitingOver Processing

Over Production

Defects

IgnoredSkills/Talent


QResource usage and cost optimization is the key to increased

productivity

Concentrating on value stream optimization, removing waste and

sustainable flow increases productivity


Exercise


Waste I

• Overproduction

• features or services the customer doesn’t want

• large engineering documents, more detailed designs than can be quickly implemented

• duplication of data

• Waiting / delay

• for clarification

• Documents

• Approval

• Components

• other groups to finish something


Waste II

• Handoff, conveyance, moving

• Giving a specification from an analyst to an engineer

• Giving a component to another group for testing

• Extra processing

• Relearning, lose of information.

• Forced conformance to centralized process checklists of

• Recreating something made


Waste III

• Partially done work – WIP \ DIP

• Designs documented but not built

• Things built but not integrated or tested

• Things tested but not delivered.

• Task switching

• Interruption

• Multitasking on 3 projects

• Partial allocation of a person to many projects


Waste IV

• Under-realizing people

• People only working to single speciality job

• Do people have the chance to change what they see is waste.

• Information scatter or loss

• Information spread across many separate documents

• Communication barriers such as walls between people, or people in multiple locations.


Waste V

• Wishful thinking

• “We MUST follow the plan”

• “The estimate cannot increase; the effort estimate is what we want it to be, not what it is now proposed.”

• “We’re behind schedule, but we’ll make it up later.”


Engineering Practices


Common Agile Engineering Practices

• Pair programming

• Refactoring

• TDD \ ATDD

• Continuous integration


Pair Programming

• A technique used to:

• Increase quality level (code review is built in).

• Increase knowledge sharing.

• Over time increase productivity.


Refactoring

• Refactoring ≠ Redesign.

• Refactoring is a form of editing, whose goal is to improve readability while preserving meaning.

• Done as a series of steps, each step does a little.

• Does not fix bugs.

• Most modern IDE’s have auto-refactoring tools.

• Refactoring is not a “standalone” task.


Test First - TDD/BDD

• TDD – Test driven development:

• A Design technique.

• Never write a line of code unless it fixes a failing test.

• Red -> Green -> Refactor.

• ATDD – Acceptance TDD:

• A Requirements management technique.

• Requirements are written as functional tests.

• Usually with tools such as Cucumber / SpecFlow

• For every failing functional test run the TDD cycle.


Continuous Integration

• The system is always integrated (even multiple sites\ multiple components).

• CI systems can and should be aggregated.

• Requires check ins as often as possible.

• Usually done by a system that automatically:

• Generates a new build version.

• Runs all unit tests.

• Creates a deployable package.

• Installs it to production equipment.

• Runs all system tests.

• Run LSP tests.

• Publishes results.


Summary


Agenda

• Introduction

• Overview & History

• Self managing & Empirical approach

• Scrum overview

• The Scrum Master

• Transparency

• Definition of DONE

• Waste

• A Scrum team

• Eliminate Waste

• Engineering practices


References and Additional Sources

• 1970 - Managing the development of large software systems (aka Waterfall Model, Winston Royce) http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

• 1986 – The new, new software development game (Takeuchi & Nonaka) http://files.meetup.com/1671339/The%20New%20New%20Product%20Development%20Game.pdf

• Liker\Hoseus 2008 – The Toyota Way http://www.amazon.com/The-Toyota-Way-Management-Manufacturer/dp/0071392319

• 2001 - Agile Manifesto http://agilemanifesto.org

• 1991-2013 - The Scrum Guide (Schwabber, Sutherland) https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf

http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

http://files.meetup.com/1671339/The%20New%20New%20Product%20Development%20Game.pdf

http://www.amazon.com/The-Toyota-Way-Management-Manufacturer/dp/0071392319

http://agilemanifesto.org

https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf



• 1971 - The Psychology of Computer Programming (G. Weinberg) http://www.amazon.com/The-Psychology-Computer-Programming-Anniversary/dp/0932633420

• 1987 - Peopleware, Productive Projects and Teams (T. De-Marco) http://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113

• 2003 - Lean Software Development: An Agile Toolkit (M&T Poppendieck) http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783

• 1999 - Extreme Programming Explained (K. Beck & C. Andres) http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658

http://www.amazon.com/The-Psychology-Computer-Programming-Anniversary/dp/0932633420

http://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113

http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658



• 2004 - Working Effectively with Legacy Code (M. Feathers) http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

• 1975 - The Mythical Man-Month (F. P. Brooks) http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

• Promiscuous Pairing and Beginner’s Mind http://user.it.uu.se/~carle/softcraft/notes/PromiscuousPairing.pdf

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

http://user.it.uu.se/~carle/softcraft/notes/PromiscuousPairing.pdf


End of day 1

practical scrum course day 1

Leadership & Management