© conchango 2006 An Introduction to Agile and Scrum By Alf Ogundeyin.

© conchango 2006 www.conchango.com

An Introduction to Agile and Scrum

By Alf Ogundeyin


Agenda

• Introduction

• The Agile Principles

• Introduction to Scrum

• Roles

• Scrum Meetings

• The Sprint

• User Stories

• Estimation and Planning

• The Scrum Team

• Defining Done

• Questions and Answers


Introduction

By Alf Ogundeyin


• Traditional approaches to application development have resulted in high failure rates

• Traditional methodologies can prove bureaucratic and slow to deliver• The business can’t conceptualise all requirements in one go, let alone

document completely• Business is changing, the longer the project the greater the risk• Traditional methodologies focus on the process rather than empowering

people

Tarnished IT Projects

Sou

rce:

For

rest

er R

esea

rch

Inc


Wasted Effort

Features and Functions Used in a Typical System

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Always7%

Often13%

Sometimes16% Rarely

19%

Never45%

Rarely or Never Used: 64%

Often or Always Used: 20%


Origins of Waterfall

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

System Requirements

Software Requirements

Analysis

Program Design

Coding

Testing

Operations

From: “Managing the Development of Large Software Systems” by Winston W. Royce (1970)


The Agile Principles


What is Agile?

AgileAgile Software Development is an umbrella term for approaches to software development that follow the principle of ‘Inspect and Adapt’ and advocate team empowerment

• “Agile” approaches emerged concurrently from a number of leading thinkers who were successfully delivering software with “Lighter” methods in the 1990s

• Out of a meeting at Freebird in 2001 to find commonality between their approaches came the Agile Manifesto

• Agile methods include DSDM, Extreme Programming (XP), SCRUM, FDD and Crystal


The Agile Manifesto

While there is value in the items on the right, we value the items on the left more.

overoveroverover

Individuals & InteractionsCustomer CollaborationResponding to ChangeWorking Software

Processes & ToolsContract NegotiationFollowing a PlanComprehensive Documentation

“Inspect and Adapt”


Agile Manifesto Principles 1 of 2

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

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

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

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

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

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


Agile Manifesto Principles 2 of 2

Working software is the primary measure of progress.

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

Continuous attention to technical excellence and good design enhances agility.

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

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

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


Introduction to Scrum


Scrum Timeline

1986 Harvard Business Review article

1996 SCRUM techniques published at conferences

2001 Agile Manifesto

2001 Agile Software Development with SCRUM book

2003 SCRUM certification

2004 Agile Project Management with SCRUM book

2004 SCRUM Alliance


Scrum Overview

Scrum provides the project delivery approach:

• Improve communications and maximises co-operation

• Incremental & Iterative – 2 to 4 week iterations delivering production quality code

• Regular input and feedback from users/business

• Continual focus on highest priority business requirements

• Analysis, design, development, testing performed throughout iteration

• Self organising cross-functional teams - including the customer

• Minimal creation of “Interim” documents - focus on working software

• Inspect & Adapt at the end of every iteration


Scrum on a Slide


Maintain Intensity

Months

Waterfall

Scrums

© Mike Cohn, Mountain Goat Software


Scrum Rhythm

SprintDaily Scrums

Sprint Review

Sprint Planning

Sprint Retrospective

Potentially Shippable

Code

Iterate

Pro

du

ct B

acklo

g


The Product Backlog and the Product Owner


Product Backlog

• Prioritised list of product or project requirements• Expressed in business language, ideally User Stories

• Not a detailed breakdown of requirement, can be 1 sentence

• Prioritised, by business value, at beginning of each Sprint

• Anyone can contribute items for the backlog• But they will be prioritised along with all other requirements

• One person (Product Owner) is responsible for prioritisation and making sure requirements are well formed

• High level estimates• Size only - can use Story Points

• Planning Poker


Exercise

Role of the Product Owner

Pair with someone, turn to each other and discuss what are the responsibilities of the Product Owner

You have 5 minutes


Product Owner

• Voice of the customer• Manages the Vision• Defines customer value-added and the

key features of the product• Continuously refines requirements

• Sets development schedule by

prioritising the Backlog

• Works with others to estimate items on

Product Backlog• Responsible for the project success and

ROI• Decides on release date, content and

budget


Product Owner

• Creates and updates the release plan and reports

• Manages stakeholders and interests proactively

• Selects the Sprint Goal, steers and guides the work, answers questions on a daily basis

• Attends all Scrum meetings• Accepts or rejects work results in the

Sprint Review meeting• Available to the Team for clarifications

during the Sprint• Takes advice from the Team on Product

Backlog dependencies


Characteristics of a Product Owner

• Understands customer needs thoroughly

• Able to create and communicate the product vision

• Empowered to make decisions, is decisive and knows when to say no

• Has good working relationships with the stakeholders

• Has good working relationships with the team

• Understands value creation• Leader and facilitator

Product Owner = Superman?


The Scrum Master and the Team


Scrum Master

• Responsible for establishing SCRUM practices and rules, ensures the process is followed

• Shields the team from distractions and helps remove obstacles.

• Ensures that the team is fully functional, productive and improves quality

• Enables close cooperation across all roles and functions and removes barriers

• Educates everyone on the Scrum process


The Sheep Dog

• An important part of the Scrum Masters role is to ring fence the team so that they can concentrate on their Sprint Backlog• Disruptive outside influences• Irrelevant meetings

• The Scrum Master is inward facing• Morale• Remove impediments• Environment

• The Scrum Master is outward facing• Educating the organisation• Removing organisational impediments• Managing external communications


Chickens and Pigs

Members of Scrum Team are known as Pigs because they are committed to delivering Sprint Goal.

People who are involved but not dedicated to the project are known as Chickens. They can attend Scrum meetings but only as observers.


Scrum Team

• Responsible for committing to work

• Cross-functional

• Self-organizing

• Authority to do whatever is needed to

meet commitment

• Ideal team Size 5 – 9

• Demonstrates iteration output to Product

Owner, users and stakeholders


Scrum Meetings


Sprint Planning Meeting

Sprint Planning Meeting

Updated Product Backlog

Business Conditions

InputTeam Capacity

Definition of Done

Pro

du

ct O

wn

er

Scr

um

Tea

m

Scr

um

Mas

ter

Input

Sprint Goal

Sprint Backlog

Output


Sprint Planning

Determine the work that can be completed next Sprint

• Two parts to Planning:

• Choose Goal: the Team and the Product Owner collaborate to decide how much of the prioritised backlog can be turned into potentially shippable functionality

• Create Sprint Backlog: the Team defines the tasks required to build that functionality during the next Sprint, including estimates to achieve the Definition of Done


Sprint Planning

• Things to note:

• Make sure the Backlog is prioritised beforehand

• Not only the highest priority items have to be chosen!

• Use previous Sprint results to inform estimation• Take cards from previous Sprint with you

• If planning is taking too long don’t rush it – schedule a session for the next day

• Success or failure of the entire Sprint relies on this session• Don’t underestimate how long estimation takes (!)• Get input from content leads and architects, and data and migration

• Make a nice organised wall-chart to begin the next Sprint with


Daily Scrum

• Daily 15 minute status meeting

• Team stands in a circle facing each other

• Each team member answers 3 questions:

• What have you done since the last Scrum?

• What will you do between now and the next

Scrum?

• What is in your way?

• For synchronization not problem solving!

• Not a Scrum master status meeting,

commitments between peers


The Sprint Backlog

Story Not Started In Progress Done

As a online customer, I need to be able to LoginSo that I can securely Access my account details

As a online customer, I need the ability to change my password, so that I can be confident my account ....

8

As a site administrator, I need to be able to disableaccounts so that I can stopaccess on the clients request

3

5

As a prospective customer, I want to request an accountSo that I can become a clientAnd manage my accounts

13


Sprint Review

Demonstrate what was achieved in the Sprint and collect feedback

• The Team presents, not the Scrum Master• Typically a demo of new features

• or underlying architecture etc

• Informal• No more than 2 hours prep

• Avoid slides

• Whole team participates

• Invite anyone and everyone


Sprint Review

Sprint Review Agenda:

1. Intro – what the purpose of the meeting is and the agenda

2. Describe the Sprint Goal

3. Point out which Product Backlog Items were committed to

4. Explain which ones were completed

5. Have a look at key moments on the Sprint Burndown – honestly

6. Demonstrate completed features by product backlog item and answer questions

7. Check the Definition of Done for each of the product backlog items

8. Debrief: Poll each stakeholder one by one for their views


Sprint Review

Possible results of the Sprint Review

• Put unfinished features back onto the Product Backlog • as well-worded product backlog items

• Remove items that were unexpectedly completed• Adjust the team• Reprioritise the Product Backlog

• to take advantage of completed work• Release!• Stop the project• Add teams to speed up the project



Take a look at what is and what isn’t working

• Team and Scrum Master participate• Product Owner also allowed if involved during Sprint

• Can get emotional

• Exercise-driven

• Drive out actions, tasks for next backlog

• Or add to wallchart in team area



• Agenda:

• Set the Stage 10-15%

• Gather Data 15-20%

• Generate Insight 15-20%

• Decide What To Do 20-25%

• Close 10-15%

• (Breaks 10-15%)

N.B. These timings include explanation and shuffle time


The Sprint


Sprint

• A fixed period to accomplish the Sprint Goal, which is agreed between the team and the Product Owner

• Sprint lengths usually range from 2 to 4 weeks

• Once a Sprint has started only the Scrum Team can add or remove items in Sprint Backlog

• Abnormal termination of Sprint is called for when the Sprint Goal no longer makes sense – extreme circumstances only


Sprint Length

• Factors to consider• How long the business can go without changing its mind

• Pick a length that spreads intensity appropriately

• Ability to reliably predict effort on tasks several weeks out

• Length of the overall release

• Amount of uncertainty on the project

• The overhead of iterating

• Experience and cohesion of the team

• You cannot change your Sprint length• Except e.g. Release Sprint

• Sustainable working

• Cadence

• Predictability


Sprint Backlog Contents

• The list emerges during Sprint planning

• The Sprint backlog is a list of tasks that defines a Team's work for a Sprint

• The tasks are what the Team has defined as being required to turn committed Product Backlog items into system functionality• Task size: 1-16 hours

• Estimated as a team

• The Sprint Backlog should be updated daily• After the Scrum Meeting works well

• Or when a task is completed

• Anything that gets done should be visible on the backlog• Emergent tasks are added by the team to the backlog throughout the

Sprint


Sprint 0 – Project Initiation

Just enough to get the team up and running

• Amount of time and effort will vary from project to project• Architectural complexity• Predictability and commitment required for functionality and delivery timescale

• Potential Sprint 0 Tasks/Deliverables• Business Case and funding• Vision• Initial Product Backlog• Initial Release plan• Stakeholder buy in• Assemble team• Logistics


User Stories


User Stories

• User Stories are an established method of clear communication between the team and the business


What makes a good story?

• INVEST acronym can be found in Mike Cohn’s “User Stories Applied”


Exercise – Backlog Shaping Workshop

• Split into teams of about 5 people

• You will use as an example a project that one of you is on, that person becomes the Product Owner

• Elect one person as a Scrum Master, whoever you feel is most suitable

• The rest of you are the team

Create an initial product backlog for the project you have selected

• Try to identify the most important requirements for the project

• Think how they can be broken up to give slice’s of business value

• Try to write the them as user stories

• Continually prioritise


Estimation and Planning Poker


Estimating Using Story Points

This takes the relative sizing of each item into account

• Pick a reference task and estimate that

• Then estimate the sizes of all the other tasks in comparison

• E.g. if story 1 has been given a size of 2 and story 2 feels a bit bigger it will be given a 3


Exercise – Planning Poker

• For our prioritised Product Backlog that we produced in the previous exercise we are now going to supply some estimates, so back in your teams


The Scrum Team


Team Responsibilities

• Working in a Scrum team is slightly different than a traditional team

• You are now committing to the iteration target, as a team• You now have the authority to do anything you need to hit your target• You are working closely with people with other skillsets• The way you communicate inside and outside the team has changed• You are now being allowed to work rather than being instructed to work

• This means you have a slightly different role

• TEAM focus, not individual• Much more face-to-face communication• You are trusted and empowered to solve problems• Your skills are used in a different way…


Scrum Team Members

• A Scrum team acts as a self-organising unit with the right to do anything they need to in order to hit the Sprint target

• They manage their own interactions with users and stakeholders, they promote and stick to the Scrum rules and they focus on one thing: delivery


As a Scrum Team Member...

• Communication• Values face to face communication• Manage environment to promote communication and teamwork• Takes part in the daily stand-up meeting• Brings challenges into the open, not sweeping them under the carpet • Identifies impediments and shares them with the team

• Ownership/Responsibility• Takes ownership of all the work the team commits to• Follows up actions from the team retrospectives, looks to continually improve• Meets with Product Owner, users and stakeholders frequently to clarify tasks and

monitor progress

• Teamwork• Solves rather than blames• Asks for assistance or guidance when required• Is aware of what the other team members are doing• Helps other team members, professionally and personally• You have fun delivering working software


Business Analysis in Scrum - Overview

• Scrum analysis is a highly evolutionary and collaborative process• In Scrum, analysis is not a phase of the project nor a task in a project plan

• Actively working together with developers and project stakeholders on a just-in-time basis to:

• understand the domain• identify what needs to be built• to estimate that functionality• to prioritize the functionality

and in the process optionally producing

artefacts that are just barely good enough


A Business Analyst in Scrum…

• Collaboration/Communication• Primary goal is to identify and understand what your project stakeholders

needs, and communicate this to everyone involved• Promotes understanding of, and agreement with, the overall vision of the

project • Communication rich: prefers conversations to documentation and email• Works as closely as possible with Product Owner and stakeholders• Helps to transfer skills rather than specialise in analysis

• Working methods• Works in an iterative i.e. cyclical fashion: design and analysis rely on each

other • Works in an incremental fashion: systems don’t have to be built all in one go • May take the role of stakeholder if they are unavailable• May work a sprint ahead of the team to make sure backlog items are just

good enough


Testers in Scrum - Overview

• A Scrum tester takes more of a quality assurance role than that of a basic tester

• They collaborate with the analysts and developers to break down tasks to achieve the definition of ‘Done’

• They start work at the very beginning of a Sprint, developing test strategies and automated unit tests etc rather than waiting for code to be developed

• They act as the conscience of the team!


A Tester in Scrum…• Quality

• Helps the business owner to assess the level of quality in a delivered release • Cares about getting work done right first time • Encourages team members to follow the principles of quality• Uses more judgement, the application of more expertise about what's good and what's not,

has confidence in own knowledge of what good looks like• Owns all the items in the Definition of Done

• Collaboration• Works closely with business users to gain their input into their understanding of how the

system should function as early as possible • Collaborates with team members rather than working in isolation • Seeks product information individually through testing, and work with other team members

to figure out what to test, rather than testing from requirements

• Working Methods• Tests the software continuously throughout its development • Tests within each iteration, rather than at the end of a development lifecycle • Writes test scripts at the same time or before the developer is coding• Works towards the notion that the test scripts document the system functionality • Decides what to test when a product is still unfinished• Works with other teams to maximise efficiency and effectiveness of testing


Developers in Scrum - Overview

• A Scrum developer is known within the organisation as:

• Trusted• Empowered• An active team member

rather than a machine which processes requirements handed to them by analysts

• The Scrum developer collaborates with architects, analysts and testers within their team to build production-quality code, preferring conversations over documents to clarify requirements


A Developer in Scrum…

• Responsible and Empowered• Participates in planning the next Sprint, advising the team on which

features can realistically be committed to • Advises on estimation of the full set of tasks required to get those features

to ‘Done’ i.e. production-quality • Takes responsibility for the outcomes of all work done by the whole team,

not just their own tasks• Takes an active role in Sprint Review sessions, presenting clearly to large

groups of people if necessary• Participates confidently in Sprint Retrospective sessions to improve how

the team works in future Sprints

• Collaborates• Works closely with the Product Owner and stakeholders to ensure the

features built satisfy their current needs • Shares knowledge between team members, especially for any tasks that

affects the whole team, e.g. deployments


Others in Scrum…

Architects, User Experience, Authors, Marketing, DBA’s, and other domain experts often work across multiple Scrum Teams, but will sometimes be part of the team

• Need to agree how other domain experts will interact with the team before the start of each sprint

• Often architects and user experience designers work just ahead of the team• Ideally ‘just ahead’ means that the work is done as part of the team in a

sprint• For new Scrum teams ‘just ahead’ will probably mean a sprint ahead to

make sure product backlog items are just good enough in order for the team to start


Defining Done


Exercise – Defining Done

Pair with someone, turn to each other and share short answers to the following for 5 minutes:

• What does “done” mean in your current project?

• What issues do you see with this definition of done?

• How would you address them?

• What engineering problems do you see with this approach?

• How would you rectify them?


Definition of Done

Some example of items that may appear on a teams definition of DONE:

• Coding standards followed and checked.• No outstanding bugs• Evidence of testing (Unit, System, Regression, Platform(s), Automation,

Usability, Confirmation)• Documentation (User, Technical)• Update component roadmap

• Peer reviewed (pair programming counts as peer review)

• 90 percent code coverage achieved

• Build and package changes are communicated to build master (i.e. introducing a new file or something) and build is deployed

• Task list hours are updated and task is closed out


Scrum Top 10 Tips


1 – Always Deliver

• Focus on delivering functionality that has business value

• Always deliver functionality you can demonstrate at the end of the sprint

• Always fix the sprint length at the beginning of the sprint NEVER extend the sprint end date


1 – Always deliver no matter how small

• Login screen• Master Pages• Exception handling

framework• Initial database schema• Data Access blocks

Key PrincipleEach Sprint must deliver business value

Functionality

Business Functionality

Architecture building blocks

Sprints


2 – Deliver Slices of Business Value

• In order to deliver functionality of value to the business in a short amount of time software needs to be delivered incrementally• Tracer Bullets• Layer functionality, simple, then build on it• Functionality should cut across all layers of the architecture• Integrate often to drive out incompatibilities

• Continually review priority of business requirements• User group and/or representative relationship is key

• At the beginning of the project

• After every iteration

• Ensure that “Technical” features/architecture directly support priority business features• Use business language to show the benefit of “Technical” work


• The sprint has strict, well defined boundaries • Entry Criteria Product backlog item• Exit Criteria Definition of done

Analysis

Design

Code

Unit Test

System Tested

UAT Test

Performance

UAT Accepted

Pilot

Live

Planning

This is a minimal baseline, but extend done as far as possible,

3 – Done


4 – Quality is King

Engineering PracticesThose practices at the top of the pyramid represent the pinnacle of development engineering practices, whereas those at the bottom represent the foundations without which those practices at the top would not usually take place.

Find bugs quickly Fix them as soon as you can

Don’t get into “Bug Debt”Otherwise you’ll need a

“Bug fix” iteration


5 – Reciprocal Commitments

• A fundamental trust building framework

• The team commits to deliver functionality within the sprint

• The stakeholders commit to not changing the work the team committed to within the sprint

• DO NOT ever change the work committed to in the sprint. • This breaks the established trust.• The next sprint the order of work can be changed


6 – Release Value Early

• Shorter release cycles provide many benefits:• Realises the value in the code sooner

• Reduced gap between specification and production - increases likelihood of solution relevancy

• Reduces risk

• Production feedback

• Need to work with the business to be pragmatic• Minimum set of functionality that provides value

• Legacy of sign-off – specify everything just in case!

• Release in a single region or market or customer

• Competition is a good motivator: Region with the smallest set of functionality can go live first!


7 - Get User Group Feedback

Get regular user feedback on the functionality delivered in each iteration

• Usually harder than it should be

• User review presentation at the end of each iteration

• Breakout groups to work through the functionality

• Provide access to test previous iteration’s delivery

• Structure user testing and feedback by asking specific questions

If feedback is not successfully gathered the system is unlikely to deliver what the users want or need


8 – Prioritise Work

In a sprint always work on the highest priority items as a team

• Avoid cherry picking tasks which are easy to complete

• Work down the sprint backlog as a team from the top, to ensure the highest priority items get ‘Done’


9 – Don’t do “Mini-waterfalls”

Sprint 3 User Review & Feedback

Review Product Backlog & Define Sprint Backlog

An

alys

e

Des

ign

Bu

ild

-Tes

t

Dep

loy

UA

T T

est


9 – Don’t do “Mini-waterfalls”

• Key indicators• Too much documentation

• Time taken from defining a feature to receiving it into test (can also indicate that features are too big)

• Developers and/or Testers bored twiddling thumbs for first ½ of iteration

• Runaway defect count at the end of an iteration

• Large quantity of untested code at the end of the iteration

• Failure to deliver production quality code


10 - Evolve Architecture• Delay design decisions until last responsible moment

• Maximises information before commitment• Minimises opportunity of change before software is delivered• But don’t procrastinate!

• Do ‘enough’ architecture• Varies per project• Identify the areas of high cost of change• Enough to start developing• Keep doing it until the project ends• Architecture will be more flexible

• Keep documentation light• Loss of fidelity in translation to document form• Resistance to change once its “on paper”• Diagram the essentials but don’t be precious as they will need to change


Agile Resources

• Books• “Implementing Lean Software Development: From Concept to Cash” by Mary

Poppendieck and Tom Poppendieck• “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle• “Agile Estimating and Planning” by Mike Cohn• “Agile Retrospectives” by Esther Derby and Diana Larsen

• Web resources• www.agilealliance.org• www.controlchaos.com• www.scrumalliance.org• www.scrumforteamsystem.com (by Conchango)


Questions?

[email protected]

http://blogs.conchango.com

www.scrum-master.com


Scrum Smells


Scrum Smells – Bug Debt

• Symptoms• Teams worry about how to manage issues that they find in testing• Outstanding ‘known’ bugs at the end of the sprint, which mean the stories fail their

acceptance tests• Testing only happens at the end of a sprint• The team have a high number of bugs at any one time• System crashes at Sprint Review

• Discussion• System with a large bug debt is unstable and therefore it is difficult to add new features• People waste time managing the backlog of bugs

• Actions• Fix bugs as early as possible• Stop the line culture, when a problem is found the whole line stops to investigate

• Fix the problem• Learn from the problem and make sure it never happens again


Scrum Smells – Loss of Rhythm

• Symptoms• Daily Scrum ritual is inconsistent or is drifting (subtly changing) • Daily Scrums are skipped or meeting times vary • Sprint durations are inconsistent or change arbitrarily mid-sprint • Sprint planning ritual is inconsistent or drifts • Sprint planning meetings are skipped

• Discussion• Rhythm helps make routine things routine

• Actions• Scrum Master enforces the process• Clarify expectations • Conduct training • Be consistent • Resort to mommy rules


Scrum Smells – Poor Backlog Management

• Symptoms• A Product Backlog doesn’t exist• An unmanageably large number of Product Backlog Items exist• All the Product Backlog is fully defined• The top of the Product Backlog is not good enough for items to be accepted into the next

sprint• The Product Backlog is not driven by someone who understands and can speak for the

customer’s needs• The Product Backlog is not prioritized• Product Backlog Items are not estimated by the team

• Discussion• The Product Backlog is what the business uses to drive the development

• Actions• Scrum Masters responsibility to enforce the process• Conduct training• Mommy rules


Scrum Smells – Missing Pigs

• Symptoms• Team members failing to attend Daily Stand-up meetings• Even when developers attend Scrums reliably, they can be absent in other ways:

• Perfunctory reports• Withdrawal or non-participation• Disruptive behavior

• Discussion• Scrums are about the team achieving results and synchronising towards a

common goal

• Actions for:

• Circumstantial Problems• Establish rhythm• Role model• Change meeting time and location• Explanation, persuasion and negotiation• Embrace technology• Reorganise team

• Behavioral Problems• Act from knowledge• Clarify expectations• Individual accommodation• Shuffle the team• Manage the personality• Be a heavy


Scrum Smells – Talking Chickens

• Symptoms• External stakeholders talk in the daily Scrums • Features are selected or priorities switched outside of sprint planning meetings • The team cannot make purely technical decisions without an outsider’s blessing • Status reports are required outside sprint planning meetings • Team managers or executives who sponsor the team receive requests to influence the

team

• Discussion• There is a balance between the business being involved to answer questions and the

business trying to influence the team during the sprint

• Actions• Be consistent• Conduct training• Have a contract on how people work together• Move chickens away from the pig-pen• Bring the chicken into the Scrum• Remember you’re a sheepdog!


Scrum Smells – Other Smells

• Disengaged Product Owner• The Product Owner is not available to answer questions and/or the Product Backlog

is not good enough for the team to start work

• Missing Domain Experts• The right people are not available to the team at the right time

• Persistent Signatures • The wild fluctuations shown on a team’s initial sprint burn-down charts continue to

be seen in much later sprints.

• Scrum Master Assigns Work • Work is assigned by the Scrum Master rather than signed up for by developers

• Specialized Job Roles • A project team has highly specialized job roles or descriptions such as Architect,

Designer, DBA, or Tester

• The Daily Scrum is For the Scrum Master • The Daily Scrum feels like it is a status update from the team members to the Scrum

Master


Quality


Quality is King

Engineering PracticesThose practices at the top of the pyramid represent the pinnacle of development engineering practices, whereas those at the bottom represent the foundations without which those practices at the top would not usually take place.

Find bugs quickly Fix them as soon as you can

Don’t get into “Bug Debt”Otherwise you’ll need a

“Bug fix” iteration


Continuous Integration

“Continuous Integration is a software development

practice where members of a team integrate their work

frequently, usually each person integrates at least daily

- leading to multiple integrations per day. Each integration

is verified by an automated build (including test) to detect

integration errors as quickly as possible. Many teams find

that this approach leads to significantly reduced integration

problems and allows a team to develop cohesive software

more rapidly.”

--Martin Fowler, May 2006 (http://www.martinfowler.com/articles/continuousIntegration.html).


Practices of Continuous Integration

1. Maintain a single source repository

2. Automate the build

3. Make your build self-testing

4. Everyone commits at least every day

5. Every commit should build the mainline on an integration machine

6. Keep the build fast

7. Test in a clone of the production environment

8. Make it easy for anyone to get the latest executable

9. Everyone can see what’s happening

10. Automate deployment

Teams have found that they get the best quality results when they combine Continuous Integration with Test Driven Development (TDD)


Build Quality In

Acceptance TestsBusiness Intent

(Design of the Product)

Business Facing

Usability Testing

Exploratory Testing

Unit TestsDeveloper Intent

(Design of the Code)

Production Testing

Load Testing, Production Resilience, Security Leaks, Etc,

Technology Facing

Manual: As Early as Possible

From Brian Marick


Every Release: Deployed and Running in Production

Every Iteration: Deployment Ready Code

Weekly Integration Test

Daily Acceptance

Test

Nested Synchronisation

Every few minutes• Build and run unit tests• STOP if the tests don’t pass

Every day• Run acceptance tests• STOP if the tests don’t pass

Every week• Run production tests• STOP if the tests don’t pass

Every iteration• Deployment-ready code

Every release• Deploy and run in production

10 minute build test

From Mary Poppendieck


Refactoring

Continuous Improvement of the Code-Base

• Just-in-time NOT Just-in-Case• Start with what you know is needed now

• Add features only when you know you need them

• Refactor: Simplify the code based on what you know now

• Maintain a Simple, Clean Design• No features ahead of their time

• No features after their time

• No Repetition

• Safety First!• You can’t refactor without test harnesses

Date post:	17-Dec-2015
Category:	Documents
Upload:	daniel-peters
View:	214 times
Download:	1 times

© conchango 2006 An Introduction to Agile and Scrum By Alf Ogundeyin.

Documents