Partner EnablementCloud Journey Webinar Series - Post Sales Track

Agile Development and Implementation

Gil ShahamDirector, Post-Sales Enablement

gshaham@salesforce.com

James BurnsSolution Architect Senior Director jburns@salesforce.com

▪ Cloud Journey is specifically available to our Salesforce Reseller Partner Community as an additional learning resource.

▪ Join these sessions to learn more about business with Salesforce and have an opportunity to hear best practices across key topics: Sales & Pre Sales, Post Sales and Customer Success.

Cloud Journey Webinar SeriesOngoing Enablement Series across the customer lifecyle

ACCESS: Registration Link

Registration: http://go.pardot.com/l/232132/2016-09-28/7bf

The World of AgilityAlign your Business and IT

James BurnsSenior Director and Solution Architect, Customer SuccessOffice of CTOjburns@salesforce.com

Statement under the Private Securities Litigation Reform Act of 1995:

This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.

The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.

Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

Forward-Looking Statements

Key Elements of a Salesforce Governance Framework• Center of Excellence (CoE)

The process of managing governance.

• Change ManagementThe process of managing the overall program or project lifecycle – from collecting Business requirements to moving code from development through production.

• Org StrategyThe design and structure of the foundational “orgs” or areas where the customer’s Salesforce applications will reside and run.

• Technical GovernanceThe guiding principles for effectively developing the technical aspects of Salesforce.

Center of Excellence

Change Management

Org Strategy Technical Governance

10 Reasons to Use Agile

1. Offers a superior ROI

2. Embraces business agility

3. Reduces risk

4. Increases productivity

5. Creates a sustainable development environment

6. Enables emergent innovation

7. Builds trust and relationships

8. Expects continuous improvement

9. Inspires motivation and engagement

10. Addresses the realities of software development and the needs of Business

The World of AgilityEffects more than development

The World of Agility is a BIG Behavioural ChangeThe way the development team operate.

The way that the business operates:• Requirements.

• Release cadence.

The end users.

Agility PrinciplesTo achieve the world agility you need to embrace the following principles of the agile manifesto*:• Business and IT need to work in a partnership.

• Focus on the highest priority and continuous delivery.

• Continuous communications.

• Well balanced team with regular reviews on how to become more effective.

* http://agilemanifesto.org/principles.html

Small steps to achieve the world of AgilityDrive alignment between all stakeholders.

Break silos by driving business and IT partnership.

Apply agility principles.

Go fast and iterate by defining a regular release cadence.

Continuous Improvement.

Redefine business & IT processes to enable agility eg:• Budgeting processes.

If you achieve these steps it’s the start of your behavioural Journey

Drive Alignment• Identify all stakeholders, business and IT.

• Develop a shared vision and strategy with measurable business outcomes:

• Recommended to use the V2MOM methodology.

• Secure feedback from all stakeholders on vision and strategy:

• Iterate until agreement.

• Communicate the vision and strategy widely to all stakeholders including end users.

Business and IT PartnershipDefine clear roles and responsibilities:

• Business owns and prioritize the requirements (backlog) using:

• V2MOM.

• Value management.

• Business are involved thought the whole project lifecycle.

• IT owns the implementation.

Partnership achieves:

• Increases focus on business priorities.

• Promotes rapid response to business requirements.

• Reduces the overall backlog, since only important items are put forward.

Go Fast and IterateBreak each initiative into multiple releases and consider:

• Is the out of the box capability good enough.

• Can you define a Minimum Viable Product (MVP) approach.

• Always think 80/20 rule and leave the advanced features within the requirements to future prioritization meetings.

• At the last resort only approve items that need code.

After each release constantly secure feedback from all stakeholders including end users:

• The feedback is feed into the prioritization meetings for a future release.

This approach will need effective communication and adoption processes in-place.

Continuous ImprovementTo drive innovation you need to constantly review your processes based on:• Feedback from all stakeholders including end users and all project team members.

• Trends within the support logs.

• Trends within the project risk register.

• Project KPI’s defined within your V2MOM.

The advantages of the continuous improvement:

• Improvement in efficiency.

• Increased alignment.

• Increased business value delivered.

Budgeting processes• With traditional IT projects there is a clear beginning and ending.

• With Salesforce and the 3 releases a year, means no Salesforce solution has an ending.

• IT budgeting process traditional follow:

• Change the organization – new projects and can be capitalised (CAPEX)

• Run the organization – ongoing project support and is operating expenditure (OPEX)

• To achieve optimum value from Salesforce, it is recommended a DevOps approach is followed:

• Minor modification in your accounting processes will be required.

Development MethodologyAchieve better planning and management

Waterfall

Common Development Methodologies

Kanban

Hybrid Agile

Agile

Requirements

Architect

Develop

Test

Accept

Train

Deploy

Agileadjective: able to move quickly and easily

What is Agile and where did it come from?• In 2001, 17 software developers met

at the Snowbird ski resort in Utah for two days of discussion.

• Their goal: To find an alternative to the current “heavyweight” methods of software development.

• The result: The Manifesto for Agile Software Development.

• Agile is a balanced, yet adaptive approach to planning that can be used in many different industries.

The Manifesto for Agile Software DevelopmentWe 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

Learn more about the Agile Manifesto

The 12 Principles of Agile Software

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 the shorter timescale.

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

5. Build projects 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 a development team is face-to-face conversation.

7. Working software is the primary measure of 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.

Learn more about the Agile Manifesto

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

This Isn’t AgileYou may gain speed in the short term, but you’ll pay a higher cost for it over time

• Rapid coding without design

• No planning

• Poor quality

• Compressing the schedule

• No documentation

• Making changes at any time

• Developer approach of “We’ll fix that later”

• Constantly delaying the schedule

Waterfall or Scrum?

Waterfall Scrum

• Aligns to the initial plan

• Assumes we know everything up front

• Avoids change when possible

• Delivers the full value when the project is completed

• Plans by adaptation

• Maximizes learning as you go

• Encourages change throughout the process

• Delivers value in increments

Requirements

Architect

Develop

Test

Accept

Train

Deploy

The Value of Agile

Agile Deployment

Ben

efit

Pote

ntia

l100%

Time

Traditional Implementation Traditional Deployment Maturation

Agile Implementation

ScrumLearn the benefits and get an overview

Scrum

Overview Roles and Structure Artifacts and Events Output

What is Scrum?

What are the benefits of Scrum?

What is the Scrum framework?

Product Owner

Development team

Scrum master

Sprint

Sprint planning

Daily stand-up

Sprint review

Sprint retrospective

Sprint artifacts

Understand the Scrum methodology.

=++

What Is Scrum?

• Scrum is a simple framework that can be used to manage projects such as a Salesforce development project.

• The goal of Scrum is to deliver the highest business value in the shortest amount of time.

• Here’s how it works:

• The business sets the work requirements and priorities for its development team(s).

• The development team works in organized amounts of time — called sprints — to deliver the project. A sprint is usually one to four weeks long.

• A user story is a set of work requirements.

• The product backlog is a list of user stories in order of priority.

• The development team self-organizes to decide on the best way to deliver features in order of highest priority.

Note: Scrum is not a replacement for good project management.

The Benefits of Scrum

• Sets a strong foundation for product iteration and agility

• Improves insights into business risks and rewards

• Helps you make project adjustments with minimal investment

• Helps you identify and quantify project requirements

• Tracks individual productivity with daily meetings

• Improves overall productivity

• Reduces overhead in process and management

• Helps teams focus on delivering within a set timeframe

The Scrum Framework

Roles Activities Artifacts

• Scrum master

• Product owner

• Development team

• Product backlog

• Scrum backlog

• Sprint burndown chart

• Release burndown chart

• Sprint planning

• Daily Scrum meeting

• Sprint review

• Retrospective

The Scrum Team

• The Scrum team consists of a:

• Product owner (From the Business)

• Development team

• Scrum master

• Scrum teams are self-organized.

• The team model is designed to optimize flexibility, creativity,and productivity.

• Scrum teams deliver in stages, with maximum opportunities for feedback.

• In the Scrum approach, a working product is always available.

Write a User StoryBridge the communication gap

Traditional Requirements: Language ObstacleThe challenge with traditional requirements is that Business and developers speak different languages.

Business End UserDevelopment Team

?result = base10Num

+ result; assert all0sAnd1s(result);

What’s the best way to protect the data

from fraud?

User Stories: The SolutionUser stories bridge the communication gap by capturing requirements in the language of the Business end user.

Business End UserDevelopment Team

User Story

What Is a User Story?

“As a [persona], I want to [do something] so that I can [derive a benefit].”

• Persona: Business end user

• Do something: The action the user wants to do or achieve

• Derive a benefit: The value that the user will achieve by doing the action

“As [who] [when] [where], I [what] because [why].”

• Who: Usually, this is the type of user

• What: What the user in the [who] is going to do

• When: May describe a time or date or relative time

• Where: Where the user is on the page or in the application

• Why: What triggered the user’s actions

Who Benefits From Quality User Stories?

User Interface

Design

Business AnalystDesign and Prioritization

Quality AssuranceValidation

Program Management

Planning

User Stories

Product Owner Prioritization

DevelopmentExecution

User Stories

A user story represents a small piece of business value that a team can deliver in an iteration. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally and in three stages:

• The brief description of the need

• The conversation that happens during iteration planning to nail down the details

• The tests that confirm the story's satisfactory completion

“As a [persona], I want to [do something] so that I can [derive a benefit].”

Breadth Before Depth

Best practices for user stories:

• When creating user stories, capture the major stories at a high level before moving on to detailed notes, acceptance criteria, and so on.

Note: Think of it as taking multiple passes through building stories.

• Avoid discussing the fine details of a user story before getting a sense of the big picture.

• Use the different methods to organize user stories by category or a bucket of work.

Method example: Use parent-child stories.

• Consider storyboarding your user stories.

STORYBOARD

Personas

Personas are:

• Designed to paint a picture of your users’ needs and characteristics

• Fictional characters whose effectiveness in projects is backed up by research*

You can use personas to:

• Help you create better products by knowing these different needs and characteristics

• Enable you to communicate ideas to stakeholders

Personas examples for a Sales Cloud project:

• Sales person

• Sales manager

• Sales executive

• Sales operations

• Inside Sales

* Frank Long. “Real or Imaginary: The effectiveness of using personas in product design.” Irish Ergonomics Review, Proceedings of the IES Conference 2009. Last modified: 2009.

Good User Stories

• Describe the “why,” which allows us to be strategic partners and not just order takers.

• Are sized to enable the project manager to do capacity planning.

• Are easily prioritized to help the client maximize the value of our work.

• Have clear acceptance criteria that help QA write effective test cases to reduce defects.

• Are written clearly to reduce the time BAs spend explaining stories to the team.

INVEST Technique

Independent The user story should be self-contained, and it should not have a dependency on other stories.

Negotiable Until the story is pulled into the sprint, the team and product owner should be able to rewrite or change the scope of the story.

Valuable The value to the “actor” or “user” should be clear once the story is completed.

Estimable The team should be able to determine the size of the story in relation to the rest of the stories in the product backlog.

Small User stories should ideally be broken down until they are able to be completed within a manageable timeframe.

Testable The information needed to test the story should be provided to the team.

Acceptance Criteria

What to know:

• Acceptance criteria represents the “definition of done” for a user story.

• When the product owner validates that a user story meets the acceptance criteria, it should be marked as “accepted.”

Acceptance criteria should be:

• Expressed clearly, in simple language the user would use and read like a user story

• Actionable and easily translated into one or more test cases

• Focused on user outcomes

Note: The criteria should state the intent but not a solution.

Types of Acceptance Criteria

Functional Nonfunctional Performance

• Identify specific functionality that must be in place to provide value to a user.

• Example: “The manager can approve employee expense reports.”

• Identify other critical elements of the user experience.

• Example: “The navigation elements are styled in accordance with the approved wires and style guide.”

• Set performance expectations, which are usually measured in terms of response times.

• Example: “Approvals are processed within five seconds.”

The Lifecycle of a User StoryThese steps take you through a user-story lifecycle

1. Receive an idea or concept (focus on “why”).

2. Gather details and questions (focus on “what”).

3. Groom larger stories into a runway (the agreed-upon set of smaller stories).

4. Determine if the story meets acceptance criteria (the contract).

5. Schedule into release.

6. Schedule into the sprint.

7. Build story functionality.

8. Demo the story.

9. Accept the story.

10. Conduct UAT.

11. Deploy the user stories into production.

What Is Grooming?It is estimated that the development team reserves 10 percent of their total capacity during each sprint to help the product owner with product backlog grooming.

A ThemeCollection of Related Stories

EPICLarge User Stories

User Stories Elaborated for the Next Release

In Development

Runway

Progressive ElaborationStories Move Up in Priority

User Stories: Bad Example

• The team doesn’t have context to build the best possible solution.

• The product owner will have a difficult time accepting completion of the story.

• The stories don’t have much meaning to the steering committee.

• The development team cannot estimate the effort.

• They are difficult to prioritize.

• The developer is unclear what to build.

• QA doesn’t know what to test or how to test.

“As an administrator, I want to set org-wide defaults.”

User Stories:

“As an administrator, I want to set org-wide defaults.”

“As an administrator, I want data to be private so that it doesn’t fall into the wrong hands.”

“As an account manager, I want my sales opportunities to be visible only to my account team, so that we satisfy the terms of our nondisclosure agreements.”

Bad Example

Better Example

Even Better Example

Problems With User-Story QualityThese situations could reduce the quality of your user stories

• The inability to size stories.

• You don’t have enough runway.

• Your velocity measurements are meaningless.

• You can’t use burndown charts to predict your end date.

• The development team, not the product owner, is forced to do demonstrations.

• Sprint planning is taking more than a couple hours.

• Daily stand-ups are taking more than 15–20 minutes.

• Stories are getting accepted well past the completion of the sprint.

• You have “phantom” defects.

• Your team does not realize the benefits of Scrum.

Summary of Impacts

Good User Stories Bad User Stories

• It’s easy to prioritize.

• It’s sizable.

• Your team is clear on what to build.

• The acceptance criteria is obvious.

• You have support for continuous QA.

• High value functionality is skipped while low value is built.

• You can’t forecast and velocity is difficult to measure.

• Developers guess at requirements. Time is wasted asking BAs for details, and the definition of “done” is unclear.

• Stories aren’t accepted, which impede the team from moving forward.

• QA is incomplete.

Result: Happy business users Result: Unsatisfied business users

Salesforce Best PracticesDiscuss Scrum for Salesforce projects

Salesforce

Let’s look at some Scrum best practices for Salesforce projects:

• The product owner needs to be from Business.

• Business needs to define “done.”

• On a technical debt sprint, you may need to re-architect the solution:

• As custom fields grow, consider creating new custom objects.

• As the volume of your data grows, consider strategies to manage the larger volume.

The Role of Business

Strategy Process Measurements Compliance

• Create the Business backlog.

• Define Business obstacles and create strategies to address them.

• Own and manage budgets.

• Define process maps.

• Evaluate existing processes.

• Map the Business process and requirements.

• Define the prioritization and decision criteria.

• Decide how to gather end-user feedback.

• Define key performance indicators (KPIs).

• Decide how to manage investments and innovation.

• Ensure that the new data architecture meets company policies.

• Decide how to manage the new changes within Business.

At the start of the Project Consider a Sprint 0Document the current architectural landscape.

Using the EPIC’s design a future state architectural.

Design and implement your SDLC process.

Agree project tooling.

SummaryDiscuss what we know now and the next steps

Remember the Salesforce Project Stages

Test

Ideas

Maintenance

Implement

Design

You need the guide rails for agility

BacklogRelease

ManagementDevelopment Process

IdeasBusiness Backlog

Sprint

Developers• Code or Configure

• Unit Test

• Migration Scripts

Testing

UserAcceptance

Testing Production

Environmental Management

Agile Methodology

Break-Fix

thank y u