Cloud Journey- Post Sales

1. Partner Enablement
Cloud Journey Webinar Series - Post Sales Track
Agile Development and
Implementation
Gil Shaham
Director, Post-Sales Enablement
gshaham@salesforce.com
James Burns
Solution Architect Senior Director
jburns@salesforce.com

2. ▪ 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 Series
Ongoing Enablement Series across the customer lifecyle
ACCESS:
Registration Link
Registration: http://go.pardot.com/l/232132/2016-09-28/7bf

3. The World of Agility
Align your Business and IT
James Burns
Senior Director and Solution Architect, Customer Success
Office of CTO
jburns@salesforce.com

4. ​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

5. Key Elements of a Salesforce Governance Framework
• Center of Excellence (CoE)
The process of managing governance.
• Change Management
The process of managing the overall program or project
lifecycle – from collecting Business requirements to
moving code from development through production.
• Org Strategy
The design and structure of the foundational “orgs” or
areas where the customer’s Salesforce applications will
reside and run.
• Technical Governance
The guiding principles for effectively developing the
technical aspects of Salesforce.
Center of
Excellence
Change
Management
Org Strategy Technical
Governance

6. 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

7. The World of Agility
​Effects more than development

8. The World of Agility is a BIG Behavioural Change
​The way the development team operate.
​The way that the business operates:
• Requirements.
• Release cadence.
​The end users.

9. Agility Principles
​To 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

10. Small steps to achieve the world of Agility
​Drive 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

11. 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.

12. Business and IT Partnership
Define 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.

13. Go Fast and Iterate
Break 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.

14. Continuous Improvement
​To 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.

15. 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.

16. Development Methodology
​Achieve better planning and management

17. Waterfall
Common Development Methodologies
Kanban
Hybrid Agile
Agile
Requirements
Architect
Develop
Test
Accept
Train
Deploy

18. Agile
​adjective: 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.

19. The 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
Learn more about the Agile Manifesto

20. 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.

21. This Isn’t Agile
​You 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

22. 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

23. The Value of Agile
Agile Deployment
BenefitPotential
100%
Time
Traditional Implementation Traditional Deployment Maturation
Agile Implementation

24. Scrum
​Learn the benefits and get an overview

25. 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.
=++

26. 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.

27. 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

28. 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

29. 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.

30. Write a User Story
​Bridge the communication gap

31. Traditional Requirements: Language Obstacle
​The 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?

32. User Stories: The Solution
​User stories bridge the communication gap by capturing requirements in the language of the Business end user.
Business End UserDevelopment Team
User Story

33. 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

34. Who Benefits From Quality User Stories?
User
Interface
Design
Business Analyst
Design and
Prioritization
Quality
Assurance
Validation
Program
Management
Planning
User Stories
Product Owner
Prioritization
Development
Execution

35. 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].”

36. 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

37. 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.

38. 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.

39. 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.

40. 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.

41. 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.”

42. The Lifecycle of a User Story
​These 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.

43. 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 Theme
Collection of Related Stories
EPIC
Large User Stories
User Stories Elaborated
for the Next Release
In Development
Runway
Progressive Elaboration
Stories Move Up in Priority

44. 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.”

45. 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

46. Problems With User-Story Quality
​These 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.

47. 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

48. Salesforce Best Practices
​Discuss Scrum for Salesforce projects

49. 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.

50. 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.

51. At the start of the Project Consider a Sprint 0
​Document the current architectural landscape.
​Using the EPIC’s design a future state architectural.
​Design and implement your SDLC process.
​Agree project tooling.

52. Summary
​Discuss what we know now and the next steps

53. Remember the Salesforce Project Stages
Test
Ideas
Maintenance
Implement
Design

54. You need the guide rails for agility
Backlog
Release
Management
Development Process
Ideas
Business
Backlog
Sprint
Developers
• Code or Configure
• Unit Test
• Migration Scripts
Testing
User
Acceptance
Testing
Production
Environmental Management
Agile Methodology
Break-Fix

55. thank y u