Scaling Agile: Integrating Lean UX into Agile Delivery Models
Scaling agile. How one company did it
21
Scaling Agile how one company does it
-
Upload
mark-neumann -
Category
Internet
-
view
132 -
download
2
description
Transcript of Scaling agile. How one company did it
Scaling Agilehow one company does it
DisclaimersI represent myself: mark neumann
No secrets, all of this published beforehttp://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 ideasQuestions & Discussion welcome
"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
History: “Year of Living Dangerously”*
Big Bang Transition to Agile** in 2006** Adaptive Delivery Methodology
Well published: Chris Fry and Steve Greenhttp://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
So what is different?
Between “core agile” (scrum) and the Salesforce Adaptive Development Method?
Between the Salesforce approach and other approaches?
What’s common?Scrum
SprintsPrioritized BacklogsTeamsScrum MastersScrum, SoS, RetrospectivesAutomated Testing
What’s differentV2MOM3 Release RoadmapHeavy MatrixCloudsSprint ReviewsIn-house toolsPTOn, Open MarketIdeaExchange
Between “core agile” and the Salesforce Adaptive Development Method?
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
A Network of V2MOMsEvery person has a V2MOM for themselves (and by extension, the group they are accountable for).Defined yearly but changeableMostly hierarchical at the topBut V2MOMs can reference any other V2MOMNo formal traceability, but…
Stored in Work.com for every individualUsed 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.
Some Methods translate into Product features
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, SoSbudgeting is yearly, with adjustments
3 Release RoadmapRelease every 4 months (continuous bug fixes ongoing)Roadmap for next year (3 releases)
based on Product (cloud) GM V2MOMmore detail on the next release, less details on the out 2 releasesdriven by the Product organization
3 Release Roadmap ReviewReview 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)
OrganizationApprox. 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.
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 lineburn down, burn up charts less common nowopportunity for scrum master to ask for help
Typically Product Owner demos, Scrum master presents status.
Build & Release Management
Dedicated Build Team organizationExtensive test automation
100,000+ functional & performance tests70%+ coverage99% Pass Rate target for release
Release to Technology group instance firstPhased rollout to production
Automated Testing
When failure counts are too high
Stop the codelineFix the bugs
Tools
Dedicated Salesforce instance for Technology groupCustom Agile tools built in-house
And licensed to CA (Agile Planner)
Heavy use of Chatter, Google Sites, GmailFlexibility: teams can use what they need (to some extent)
Other approaches to scale - SAFe
SAFe vs ADMSimilar but different
SAFe ADM
3 levels (Portfolio, Program, Team)Fairly structured hierarchyHierarchy of EpicsFeatures in releasesVelocity normalized across teams10 week PSI, demoSeparate Build TeamSCRUM, XP at the team levelMore formal
Portfolio, Cloud,TeamLoose V2MOM connectionsEpics used infrequentlyFeatures in releasesVelocity an internal team tool17 week release, monthly demoSeparate Build TeamSCRUM, XP at the team levelBased on trust
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
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
