2. Disclaimers
I represent myself: mark neumann
No secrets, all of this published before
http://www.sfisaca.org/images/SFDC%20ADM%20Lifecycle-%20V2.pdf
(but I will present a slightly different perspective)
Not proscriptive: YMMV
Goal: Encourage the continued exchange of ideas
Questions & Discussion welcome
3. "We've changed our internal motto from
'Move fast and break things' to
'Move fast with stable infrastructure,'"
founder and CEO Mark Zuckerberg told to Wired
Read more: http://www.businessinsider.com/mark-zuckerberg-on-facebooks-new-motto-2014-5#ixzz30toK1100
Small agile vs. large agile
4. History: “Year of Living Dangerously”*
Big Bang Transition to Agile** in 2006
** Adaptive Delivery Methodology
Well published: Chris Fry and Steve Green
http://quarry.stanford.edu/xapm2211116ecp/docs/SalesForce_The_Development_Dilemma.pdf
http://www.cfry.net/docs/cfry-agile-2007-final.pdf
* http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation
5. So what is different?
Between “core agile” (scrum) and the Salesforce Adaptive
Development Method?
Between the Salesforce approach and other approaches?
6. What’s common?
Scrum
Sprints
Prioritized Backlogs
Teams
Scrum Masters
Scrum, SoS, Retrospectives
Automated Testing
What’s different
V2MOM
3 Release Roadmap
Heavy Matrix
Clouds
Sprint Reviews
In-house tools
PTOn, Open Market
IdeaExchange
Between “core agile” and the
Salesforce Adaptive Development Method?
7. V2MOM (it’s about alignment)
Vision:
The big picture idea for the next 12 months
Values:
The main 3-5 values for the unit (organization, cloud, group, person)
Methods:
The specific tactics to achieve desired goals
Obstacles:
Encourage people to identify up front
Metrics:
Key performance indicators. Measurable numerical result(s)
Google adopted something similar:
Objectives, Results, Key Indicators (ORK)
from Intel
8. A Network of V2MOMs
Every person has a V2MOM for themselves
(and by extension, the group they are accountable for).
Defined yearly but changeable
Mostly hierarchical at the top
But V2MOMs can reference any other V2MOM
No formal traceability, but…
Stored in Work.com for every individual
Used for performance reviews
(it’s about trust)
Formal traceability is not necessary. People are accountable for the
methods on their V2MOM, making sure others have it on their V2MOM
as required.
10. Cadence
Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan
Release Release Release
Sprint
Reviews
Sprint
Reviews
Sprint
Reviews
Sprint
Reviews
Sprint
Reviews
Sprint
Reviews
Sprint
Reviews
Sprint
Reviews
Sprint
Reviews
yearly - V2MOM → 3 Release Roadmap
1-4 weeks - Sprints
weekly - Release Readiness
daily - Scrums, SoS
budgeting is yearly, with adjustments
11. 3 Release Roadmap
Release every 4 months (continuous bug fixes ongoing)
Roadmap for next year (3 releases)
based on Product (cloud) GM V2MOM
more detail on the next release, less details on the out 2 releases
driven by the Product organization
3 Release Roadmap Review
Review last 3 release results (metrics)
Review next 3 release plans (methods)
Acknowledge agreed upon dependencies (obstacles)
Overlaps testing of current release
Drives Backlog generation/prioritization and sprint planning
(each cloud owns their planning process, decisions pushed downward)
12. Organization
Approx. 150 scrum teams
Typical size 3-10
Scrum Masters role typically rotates through team members
(with some Scrum coaches lurking)
Product (Cloud) Product (Cloud) Product
Function
o o o o o
Team Team Team
o o o o o
Dev 4 2 3
QE 2 1 1
PE .5 .2 .3
PM 1 .3 .5
UX, Doc, TPM
.3 .2 .3
The Open Market program allows people to bid
for for other team assignments every release
The matrix: typically 1 VP of Dev for all
Developers in a cloud. Some directors owning
development for distinct product areas.
13. Sprints & Reviews
Sprint duration originally standardized at 4 weeks, but now
varies by team (2-4 weeks)
Monthly Sprint Review is at product (cloud) level review.
Audience includes all leaders in Product cloud, plus leaders from other
clouds and from the functional orgs.
Bit of a marathon (all day, some go two days)
Demos + high level metrics
Avoid slideware. Some standardization in each cloud.
Simple subjective R|Y|G on status (hiring, morale, velocity)
what’s done, what’s in progress, what’s below the line
burn down, burn up charts less common now
opportunity for scrum master to ask for help
Typically Product Owner demos, Scrum master presents status.
14. Build & Release Management
Dedicated Build Team organization
Extensive test automation
100,000+ functional & performance tests
70%+ coverage
99% Pass Rate target for release
Release to Technology group instance first
Phased rollout to production
16. Tools
Dedicated Salesforce instance for Technology group
Custom Agile tools built in-house
And licensed to CA (Agile Planner)
Heavy use of Chatter, Google Sites, Gmail
Flexibility: teams can use what they need (to some extent)
18. SAFe vs ADM
Similar but different
SAFe ADM
3 levels (Portfolio, Program, Team)
Fairly structured hierarchy
Hierarchy of Epics
Features in releases
Velocity normalized across teams
10 week PSI, demo
Separate Build Team
SCRUM, XP at the team level
More formal
Portfolio, Cloud,Team
Loose V2MOM connections
Epics used infrequently
Features in releases
Velocity an internal team tool
17 week release, monthly demo
Separate Build Team
SCRUM, XP at the team level
Based on trust
19. Trust is value #1
Customers need to trust the company
The company must trust it’s people
The trend is to push more decision making
down, become less proscriptive, less managed
20. Unanswered questions
Continuous Delivery? → 4 months?
#NoEstimates? → commitments up front
Innovation vs. Customer Requests
“If I had asked people what they wanted, they would have said faster horses.”
― Henry Ford
