Post on 06-Aug-2015
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Agile @ Scale
Speed, Scale, Skills, Simplicity
http://www.flowcracker.com
1
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
FLOW Consultant – Durgaprasad B. R
2
Durgaprasad B. R 20+ Years of IT experience B. E (E & C), Alumni of
IIM, Bangalore Certifications
PMI-PMP, PMI-ACP SCP from Scaled
Agile Academy
Durgaprasad B. R 20+ Years of IT experience B. E (E & C), Alumni of
IIM, Bangalore Certifications
PMI-PMP, PMI-ACP SCP from Scaled
Agile Academy
Developer, Project/ProgramManager, Location DeliveryHead, Agile Coach
Industries: Telecom,Healthcare, ConsumerElectronics, Automotive
Past few Clients: Avaya,Nortel, ALU, Microsoft,Qualcomm, Intel, Toshiba,Continental
Technologies: WebTechnologies, Embedded,Legacy large systems
Developer, Project/ProgramManager, Location DeliveryHead, Agile Coach
Industries: Telecom,Healthcare, ConsumerElectronics, Automotive
Past few Clients: Avaya,Nortel, ALU, Microsoft,Qualcomm, Intel, Toshiba,Continental
Technologies: WebTechnologies, Embedded,Legacy large systems
Led large Telecomprograms, IP Switches,Voice Messaging System,Contact Center, ConsumerElectronics products,Automotive productdevelopment
Well versed in new agetechnologies as well as sun-set technologies
Trained and coachedindividuals and teams onAgile, Kanban, Scrum andSAFe methodologies
Regular public workshopson PMP, ACP and SAFeCertifications
Led large Telecomprograms, IP Switches,Voice Messaging System,Contact Center, ConsumerElectronics products,Automotive productdevelopment
Well versed in new agetechnologies as well as sun-set technologies
Trained and coachedindividuals and teams onAgile, Kanban, Scrum andSAFe methodologies
Regular public workshopson PMP, ACP and SAFeCertifications
http://www.flowcracker.in/about-durgaprasad-b-r/Contact: prasadbr@flowcracker.com. Cell: 9845558474
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
THE OATH OF NON-ALLEGIANCE
I promise not to exclude from consideration any idea based on its source, but toconsider ideas across schools and heritages in order to find the ones that best suit thecurrent situation.
- DURGAPRASADhttp://oathofnonallegiance.com/
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Objective• Look at issues related to scaling Agile
• Different frameworks for Scaling Agile
• High level overview of these frameworks
• Help teams to explore which framework suits thembest & how to tailor them
• Understand your context, objectives and cultural fitbefore deciding on the framework
4
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Why Agile @ Scale
• Customers asking for more features• Responding to changing market needs• Speed of feature delivery• Frequent releases, custom releases etc.
The reason’s are same as the need for Agile forSmall teams. Customers do not care about theinternal team size, structures etc.
5
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
What is Agile @ Scale ?
2 Pizza Team Size Large teams > 1000
Low Compliance/Risk
Co-located
Collaborative
Regulatory/High Risk
Geographically Distributed
Contractual/Contractors/Outsourced
What’s your Sweat Spot?
Simple Scale
?
Project Focus Enterprise/Program/ Portfoliofocus
Same Technology Complex Technology, Legacy
Agile Organization Large Complex Organization
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Operational Challenges• Many teams, many plans• Broken builds way of life• Top-down optimistic
schedules• “We didn’t start the fire”• Underestimating program
complexity• Undefined success criteria• Story point/Velocity based
metrics not adequate toprovide release forecasts
• Poor cross-functionalcommunication
• Poor requirementsmanagement
• Poor collaboration• Lack of focus on priority
activities• Off-target – Poor
Vision/roadmap awareness• Integration into business
7
On Scale, complexities increase exponentially.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Typical organization profiledesiring Agile @ Scale
• Multiple Software Development team, Verificationteams
• Common operations team• Multi location, distributed teams• One company different cultures• Code base which is old (> 5 years old) and evolved over
time (“just do it”)• Successes seen in individual Scrum teams, but does not
percolate to the program level• Because Agile is a fad and most likely CIO/CTO/CxO
mandate
8
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Considerations in Scaling Agile
• Defining common goals and roadmaps• Co-ordination across/among teams – resolve
dependencies• Integrating outcomes from each teams• Sustaining architectural/design integrity• Technical practices to help collaborate
Yet adhering to Agile doctrines - Empowered teams, fastfeedback, early and small releases, collaboration etc.
9
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Potential Candidates for
Scaling Agile
10
Large Scale Scrum(LeSS)
Disciplined AgileDelivery (DAD)
Toward beingSAFe™
…Scrum ofScrums
…Scaling with
Kanban
Rational UnifiedProcess
Rational UnifiedProcess
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scrum - Background• Typical Scrum
– 3 Roles, 4 Meetings, 5 Artifacts– Sprints, Product Backlog, Chicken and Pigs
• Product Owner– One of the most challenging roles– Inward facing towards team and– Outward facing towards business
• How to scale Scrums ?– Use Scrum-of-Scrum-of-Scrum-Of-Scrum
Based on the Scaling Scrum from the book “Succeeding with Agile” byMike Cohn
11
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scaling Scrum throughScrum of Scrums
12
…F9F8F7F6F5F4F3F2
F1
F..F..F..
F1
F..F..F..
F9
F..F..F..
F8
F..F..F..
F7
F..F..F..
F2
F..F..F..
F3
Product Manager/Chief PO (CPO)
Product Owner
Scrum Master
Team members
Cross FunctionalScrum Teams(Feature Teams)
Scrum of ScrumTeams
Scrum of ScrumTeams
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scrum-of-Scrum• Individual Scrum teams are full fledged cross functional feature teams
• PO being a busy role, would be responsible for 1 or 2 teams only
• As projects get added & program grows, a hierarchy of Product Owners will getformed to collaborate
• This team would be led by a Chief Product Owner. CPO would be responsible foroverall vision, roadmap and Master Product backlog
• At this point, the PO group may be split into customer facing Product owner /business analyst roles and the team facing traditional PO role
• Scrum of Scrum team consists of Product Owners from individual teams and/orteam representations
13
Ensuring a single Product Backlog at SoS level, is a great collaborationtool for teams to work towards a single goal.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scrum-of-Scrum• Scrum Teams should ensure some bandwidth to co-ordinate and help other teams
• One Product – One Product Backlog (Master Product Backlog)
• Master Product Backlog should be prioritized high level backlog and kept at amanageable size to ensure Program/Product Scope creep (<100).
• General practice for teams is to manage requirements in a hierarchy :Epics / Themes
FeaturesUser Stories
• Features from the Master Product Backlog is picked and self assigned by individualteams. Dependencies are resolved during the release planning.
• Daily Scrum of Scrum meeting agenda– Co-ordination– Resolving dependency issues– Issues impeding the release etc.
14
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Strategies to manage teamdependencies
• Teams are good at figuring out and resolving issues within theteam. But dependencies between teams is a major challenge
• Few strategies to manage dependencies– Rolling Look-ahead planning meeting– Release kickoff meeting– Share team members
• To help identify dependencies or to resolve dependencies quickly– Use an integration team (part time/full time depending on program size)
• Helps to work on dependency activities which are unidentified or unattended• Look out for broken build issues and get it fixed on war footing• Help setup environment, define common tools, automated test tools etc.
From: Succeeding with Agile, Mike Cohn
15
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Rolling Look-ahead meeting• End of sprint would be too late to learn about dependencies
• Dependencies need to be managed proactively.
• Look-ahead planning meetings greatly reduces dependency issues• Preferred Duration: 1-2 hours Frequency : end of Sprint planning on
Day 1 of every sprint
• Teams will only look at the Features/User Stories for the next twosprints and identify dependencies that needs to be resolved.
• Team do not break down the Features/User Stories into tasks or getinvolved in estimation in Look ahead planning meeting
• This gives additional time for teams to resolve dependencies &replan
16
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Release Kick-off meeting• Meeting to get everyone together for planning at the start of
project/release.
• Helps teams to synchronize and realign towards common goal
• Helps review the vision and define roadmap for the product release
• Owned and driven by the Chief Product Owner
• Teams can come up with a tentative plan of action for the nextrelease/period (4-6 sprints). This helps teams to know upfrontdependencies that needs to be resolved during the release kick-offmeeting
• PO of each teams will share these plans with all the other teams
17
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Co-ordination between teams
• Scrum of Scrum meetings• Synchronization sprints
18
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scrum-of-Scrum Meetings
Agenda• Review meeting agenda & guidelines• The 3 questions which needs to be
answered by every teamrepresentative
– What have team done since we last met whichaffects other team?
– What the team plan to do till we meet next timethat affects other team?
– Any impediments that affects teams work?
• Resolve problems and issues• Update the issue backlog
Attendees:Scrum Team RepresentativesWhen: 2 or 3 times per weekDuration: 60 minutesInput:Issue backlog, individual team update, team issuelistOutput:Team communication and understanding of overallprogress, critical issues, impediments, UpdatedKanban wall, issue backlog updatedKey Obstacles:Only SM/PO attends the meeting and does notrepresent the current issue properly is SoS meeting
Note: Daily scrum is a synchronization meeting.Scrum of scrum is a problem solving meeting.
To co-ordinate and resolve daily issues during sprint executionbetween Scrum teams. They are problem solving meetings.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Rule #1 : Teams should have identical Sprint durationRule #2 : Teams should be synchronized
Team Synchronization
Team 1
Team 2
Team 3
Team 4
Sprint #1 2 3 4 5
Team 1
Team 2
Team 3
Team 4
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scrum Vs. Scrum of Scrum
21
Day 1 (First Day) Day 2 to Day (n-1) Day n(Last Day) (I&A)
Sprint Planning(4 hrs)
Daily Standups(15 min
Sprint Review (I)(2 hrs)Sprint Retrospective (A)(2 hrs)
Total Hours : 10 * 8 = 80 Hours.Sprint Planning = 4 hours (5%) I&A (Demo & Retro) = 4 hours (5%)
Sprint 1
Total Hours : 80 * 4 = 320 Hours.Release Kickoff meeting = 8-16 hours (5%) I&A (Demo & Retro) = 4*4 (5%)
Sprint 2 Sprint 3 Sprint 4
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
SoS Smells• Driven by the management than team representatives. This hurts
the team co-ordination and communication between groups
• SoS meetings are attended by Scrum Masters blocking self-managing teams which work independently of Scrum Masters.Rotational team representation to attend SoS is a good practice
• Absence of real cross-component/cross functional feature teamswhich results in too much time spent in co-ordination. Ideally co-ordination should occur at code level through continuousintegration
• Lack of horizontal communication (team-to-team)
22
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Potential Candidates for
Scaling Agile
23
Large Scale Scrum(LeSS)
Disciplined AgileDelivery (DAD)
Toward beingSAFe™
…Scrum ofScrums
…Scaling with
Kanban
Rational UnifiedProcess
Rational UnifiedProcess
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Large Scale Scrum (LeSS)• Published by Craig Larman and Bas Vodde in their book “Scaling Large &
Agile Development”
• Leverages regular Scrum framework,• Advocates Scale iteration by iteration, team by team (Continuous
Improvement)
• Suggests Two alternate frameworks to Scale– LeSS FW-1 for Upto Ten Teams– LeSS FW-2 for “MANY” Teams
• Transition path is to– Start with regular Scrum.– As the team grows transition towards LeSS-FW1.– Beyond 10 teams, replace LeSS-FW1 with Less FW2
24
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
LeSS FW-1 for Upto 10 Teams
25
• Assumed that 1 PO can handleupto 10 teams, based on teamcontext
• If PO is no longer able to handle10 teams, assist PO with otherteam members before moving onto LeSS FW-2
• Advocates teams to directlyinteract with customers to reducehandoffs and overload PO’s
• PO’s should not get involved inlow-level details. They shouldfocus on True ProductManagement
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Less FW-1 RolesProduct Owner• Similar to regular Scrum• Assisted by team, SME’s• Busy role as has to cater to multiple
teams• Responsible for Features, ROI,
prioritization, changes, acceptance
26
Scrum Masters• Regular Scrum Master roles• Act as coach for team & PO. Help
team focus on the Goals• Handle conflict & impediments• Assist Product Owner• Responsible for Continuous
Improvement
3 defined Roles• Product Owner• Scrum Feature Teams• Scrum Masters
Scrum Feature Teams• Normal Scrum teams – self
managing, Cross functional• Feature teams to minimize
dependency with other teams• Interact with other teams at code
level – using Continuous integration• Assist Product Owner in his activities
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Less FW1 - Artifacts• 3 Defined Artifacts
– Product Backlog– Sprint Backlog– Potentially Shippable Product Increment
• Product Backlog– Regular backlog– Uses User Story format. Larger User stories (e.g. 300my) are split into smaller
User stories (2pw)
• Sprint Backlog– Each team has its own Sprint backlog
• Potentially Shippable Product Increment– Product increments are output from across teams– Team integrate their output into one Potentially Shippable Product Increment– Teams Continuously integrate and co-ordinate at the code level
27
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Less FW1 – Events/Ceremonies
• Six Ceremonies/Events– Sprint Planning– Daily Scrum– Product Backlog Refinement– Sprint Review– Sprint Retrospectives– Joint Retrospectives
28
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Less FW1 – Events: Sprint Planning
• Attendees– Product Owner– Team Representative (not SM)
/Team (if teams is small)
• Goals are defined andrevisited for clarity
• Product Backlog Refinement– Backlog items are self-assigned by
the teams– Initial events will take longer time.
But, will be faster in future meetings– Teams update their Team backlog
• At the end of Part one, theteam representatives/teamsreturn back to their room
• Teams now hold a normalSprint Planning meeting andcreate their own Sprintbacklog
• Team members are alsoupdated about the Goalsand vision to help them indecision making
29
Part One Part Two
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Less FW1 – Events: Other Events
Product Backlog Refinement– Usual Continuous Grooming activity– 5-10% effort in each iteration
dedicated to this activity– Done as a focused workshop (4 hrs/sprint)
– Attendees: PO, Team representatives
30
Sprint Retrospectives• Regular Retrospective at team level
Joint Retrospectives (Optional)• Done with Team representatives, PO &
SM• Joint retrospectives help at the end fo
every iteration across teams
Daily Scrum• Usual Scrum event• If required send representatives
to other teams daily scrummeetings as observers
Sprint Review• Normal Scrum event• All team representatives/teams,
PO, SM• SM alert PO of any DoD
violations
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Less FW1 – Other elements• Definition of Done
– Applies to all work items and to all teams– For large User Stories, the product level DoD’s are written
such a way that it is visible to all (wiki pages) during SprintPlanning – Part One
– DoD’s can be reviewed during the Joint Retrospectives
• Continuous Integration– Has special prominence in multi-team development– Feature teams co-ordination effort is moved from planning
to code– Having good CI in place is a foundation for Scaling
31
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
LeSS FW-2 for‘MANY’ Teams
32
• LeSS FW-2 builds on/replacesLeSS FW-1
• Beyond 10 teams, PO cannothandle any more teams
• Less FW-2 identifies majorrequirement areas and dividesthe Product Backlog into AreaBacklog
• Each Area Backlog will have itsown Area Product Owner (APO)and dedicated Scrum Featureteams
• Product Owner Teams is meant toassist the APO in defining theArea Product Backlog
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
LeSS FW-2 : Events refinedPre Sprint Planning New Event. Before Sprint planning, usually in the last week of
the prior iteration, Product Owner Team prioritizes the overallProduct Backlog.
Sprint Planning Separate Sprint Planning for each Area Backlog. Attended byrespective APO and the area team. Rest same as FW-1
Product BacklogRefinement
Separate refinement activity for each Area Backlog. Attendedby Area Product Owner and teams
Sprint Review Separate Sprint Review for each area by APO and teams. POparticipation is optional. Rest same as FW-1
Joint Review (optional) Product level joint review attended by PO and teamrepresentatives. Used to discuss issues, improvements andfeatures of interest to Product Owner teams
Joint Retrospective (optional). Happens at the area level and overall productlevel. For multi-site teams, site level Joint Retrospectives areconducted as improvement areas are generally at the physical/ cultural environment of the site.
33
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
LeSS - Critique• Not very clear about Enterprise Architecture
– Every developer is a architect and– Architects work outside of teams in voluntary
“Communities of Practices” to shape EnterpriseArchitecture
– Suggests elimination of specialization and working withoutupfront/intended architecture
• Does not talk about management @ Scale– There seems to be no role for management– Implementing Less looks like fundamentally restructuring
organization around business without any role formanagers and specialists
34
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Potential Candidates for
Scaling Agile
35
Large Scale Scrum(LeSS)
Disciplined AgileDelivery (DAD)
Toward beingSAFe™
…Scrum ofScrums
…Scaling with
Kanban
Rational UnifiedProcess
Rational UnifiedProcess
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scaling Agile with Kanban• At Scale, varied teams need to collaborate
– Development teams– Operations team– Marketing team– Manufacturing, Production, Support teams etc.
• Cannot assume it to be a– homogeneous team of Developers using Scrum only– Cannot assume it to be pure software only teams
• Team may use varied processes – Scrum, Kanban, Waterfall, PMI/ITILspecified processes etc.
• Ideal Agile @ Scale should be able to integrate all these to deliver value atScale
36
Scaling in Kanban is inherent and one cannot but just scale. It meansdoing more Kanban.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban Foundation Principle
1. Start with whatyou know
2. Agree to pursueincremental,evolutionarychange
3. Respect currentprocess, role,responsibilities andtitles
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban Core Practices
1. Visualize
2. Limit WIP
3. Manage Flow4. Make Process
policies explicit
5. Implementfeedback loop
6. ImproveCollaboratively
Shallow implementation
Deep implementation
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Implementing Kanban• Beauty of Kanban is that, one can start implementing it at any level
– Team Level– Enterprise level
• One can implement Kanban at the Enterprise level (program) without team level changes– Enterprise changes includes limiting amount of work that goes to each team– Teams are note necessarily required to do any changes unless they want to change
• Team level and/or Enterprise level implementation have Kanban boards. This helps cross-teamcommunications - a major pain in any enterprise programs
• Inputs can be maintained in a hierarchy of Epics->Features->User Stories
• Enterprise teams can define explicit policies which the individual teams have to adhere to (limits,cycle time for stories, done definitions at every level etc.)
• Focus on engineering practices like CI, Automation, pair programming to ensure quality. Defectsneed to be tracked as a separate work item on the Kanban board.
39
Kanban @ Scale is done through the culture of ContinuousImprovement.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban – Horizontal ScalingModel
40
Analyze Build
Team A Team B
Analyze Build Integrate Deploy
Team A Team B Team C Team D
Analyze Build
Analyze Build
Integrate Deploy
Team A Team BTeam C Team D
Team E Team FTeam G Team H
In Horizontal Scaling, find ways to effectively co-ordinatepeople, teams involved along the value stream
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Potential Candidates for
Scaling Agile
41
Large Scale Scrum(LeSS)
Disciplined AgileDelivery (DAD)
Toward beingSAFe™
…Scrum ofScrums
…Scaling with
Kanban
Rational UnifiedProcess
Rational UnifiedProcess
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Rational Unified Process• Defined in 1997 by Grady Booch,
Ivar Jacobson and JamesRumbaugh
• RUP Provides– Software development method :
based on UML– Software engineering practices:
roles, artifacts, communications
• Applicable for large projects withlarge teams
• RUP builds no Use-Case modeland architecture that is builtduring the early iterations(intended architecture andemergent design)
RUP covers variaous productlifecycle phases• Inception (Understanding)• Elaboration (Architecture)• Construction (Development)• Transition (Customer ownership)
RUP is iterative within each phase• Early phases focus on business
case, requirement andarchitecture baseline
• Later phases focus onimplementation, transition anddeployment
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
RUP - Principles & Practices
• Attack major risks early andcontinuously, or they will attachyou
• Ensure that you deliver value toyour customer
• Stay focused on executablesoftware
• Accommodate change early inthe project
• Baseline an executablearchitecture early on
• Build your system withcomponents
• Work together as one team• Make quality a way of life, not an
afterthought
• Develop iteratively• Manage Requirements
– Use-case focus• Use component architecture
– OO & large system focused• Model visually
– Provides guidelines on buildingarchitectural, domain, applicationprocess, use-case models
• Continuously monitor quality– Run functional & regression tests
at every iteration• Verify change
– Focus on configuration & changemanagement
Principles Practices
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
RUP IterationsInception Iterations• Business case: Operational vision
& acceptance criteria• Define critical uses Demo one
candidate architecture againstprimary scenarios
• Estimate cost & schedule, risks• Prepare environment, tools etc.Elaboration Iterations• Implement baseline architecture• Prepare throwaway prototype to
mitigate risk• Refine vision, initial iteration &
release plans for construction• Put dev environment, refine
architecture
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
RUP Phases & IterationsConstruction Iterations• Typical agile form of development• Build system in iterations and
releases• Deliver executable code which is
fully tested at the end of everyiteration
Transition Iterations• System is transferred to the
production/user• Develop deployment, migration &
support code as required• User documentation & training
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
For & Against RUP
• It is a process frameworkwhich can be tailored to anyproject – large or small
• RUP’s focus on Architecturehelps to scale unlike otherAgile methods
• Good principles of RUP are notincorporated in manymainstream Agile methodsexcept SAFe & DAD
• High ceremony• Bureaucratic : process for
everything. Slow not agile• Best applied for large
projects• Over time, RUP has got
complicated with supportfor all project types:– Technology Specific (J2EE,
.Net etc.), Maintenance,package implementation etc.
For RUP Against
However, RUP has some practices which properly used can help toscale agile appropriately.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Potential Candidates for
Scaling Agile
47
Large Scale Scrum(LeSS)
Disciplined AgileDelivery (DAD)
Toward beingSAFe™
…Scrum ofScrums
…Scaling with
Kanban
Rational UnifiedProcess
Rational UnifiedProcess
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Disciplined Agile Delivery• DAD is a framework developed by Scott
Ambler
• Leverages best practices from Scrum,XP, UP etc.
• Positioned as Beyond Scrum - as itaddresses complete product lifecycleincluding Initiation and transition
• DAD teams are Enterprise Aware :(Chicken and pigs story is prohibited )
More information @http://disciplinedagiledelivery.com/
• Like RUP, adopts “full deliverylifecycle” or end-to-end approach
• Unlike RUP, DAD has 3 phases –Inception, Construction,Transition (Phase is a dreadedword for most Agilist’s)
• Unlike Scrum, covers technicalaspect of Agile e.g. Architecture
• Advocates upfront Architecture(Intended Architecture, EmergentDesign from RUP)
Agile Practices require discipline. DAD takes this to the next level.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
DAD Phases – Inception- Used to do upfront work
at the beginning of theproject
- Initial visioning activitydone in this phase
49
Objective should be to get out of this phase ASAP
• Not just iteration 0.Inception takes longer than1 iteration (Avg. 3.9 weeks)
• Objective is to get“stakeholder consensus”
© Disciplined Agile Consortium
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
DAD Phases – Construction- A set of iterations / sprints to
build consumable increments- Uses a hybrid approach of Scrum,
XP to deliver- Every iteration will have
consumable/deployableincrement
50
Instead of RUP’s elaboration phase, DAD defines “Proven Architecture”milestone
• Uses “risk”-”value” approachto prioritize work items
• Project teams balancebetween high-value work &architectural risks
• Has explicit milestone called“Proven architecture
© Disciplined Agile Consortium
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
DAD Phases – Transition- Usually one short iteration- If the organization,
streamlines deploymentprocess, this phase shouldautomatically disappear
51
Transition phase is also called as “go-no go” decision phase.
• Transition milestone isachieved when the customer isdelighted
• Transition phase includes beingproduction ready, stabilization,tuning, training etc.
© Disciplined Agile Consortium
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
DAD – Goal Driven & NotPrescriptive
52
© Disciplined Agile Consortium
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
DAD Lifecycle Models• DAD tries not to be prescriptive. Proposes different versions
of lifecycle models to pick and choose
– Basic Life Cycle : Based on Scrum + RUP– Advanced Life Cycle : Based on Lean– Continuous Delivery Life Cycle– Exploratory Life Cycle : Based on Lean Startup
53
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Basic Life Cycle: Scrum + RUP
• Iteration based• Uses work item list not backlog• Value Risk based prioritization
54
© Disciplined Agile Consortium
• Defines Agile Governance which hasmilestones across the lifecycle –Stakeholder vision, provenarchitecture, project viability,sufficient functionality, productionready, delighted stakeholders
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Advanced Life Cycle: Lean Based
• Iteration-less, Continuous flowof work
• Some teams may migrate fromScrum to Lean based life cycle
55
© Disciplined Agile Consortium
• Work item pool (not just priority driven)– apart from value-risk driven, “date” driven
work items are part of this pool– Expedited work items also present
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Advanced Life Cycle: Lean CD Based
56
© Disciplined Agile Consortium
Product is shipped into productionon a regular basis : daily, weekly oron-demand
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Advanced Life Cycle: Lean Startup
57
• Based on Lean Startup Strategies• Ideal for Agile Marketing type of
activities which are heuristic• Helps to do a series of quick
learning experiments
Activities– Envision an idea and identify hypothesis/
tactics/technical options which is testable,– Build a little to prove/disprove hypothesis– Deploy (A/B testing), observe & measure,
Productize or cancel the hypothesis
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
RolesDefines two types of roles• Primary Roles –
– independent of scale
• Secondary Roles –– temporary, to address scale
issues
Unlike Scrum, DAD addressesarchitecture. Hencearchitecture roles areaddressed
58
© Disciplined Agile Consortium
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Enterprise Aware Teams• Unlike Scrum, DAD teams are not inward looking
• Overall all enterprise objectives override team objectives
• Enterprise Awareness through– Teams work closely with enterprise stakeholders
• Enterprise architects, sr. managers, devops/it teams– Follow enterprise guidelines & leverage enterprise assets
• Coding, UI/UX guidelines, security, data conventions, processes• leverage Common templates, infrastructure, specialists
– Adopt Governance strategy
59
Enterprise awareness means cultural change to current Agile teams
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Agile Governance
• To achieve overall enterprise goals & Strategy, some governance isrequired
• Governance helps achieve desired co-ordination between teams anddefines roles / responsibilities clearly
• DAD Governance defines– Light-weight milestone reviews– Regular co-ordination meetings (agile teams & enterprise teams)– Iteration demos, all-hands demo– Following enterprise guidelines– Aligning agile team and other teams governance (operations, marketing etc.)
60
Governance looks at the team from outside to ensure appropriate structure andprocesses are in place. Management occurs inside ensuring implementation.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scaling Agile using DAD• Traditional Agile (read Scrum) teams are inward focused and work best
when left alone• To Scale, these teams and the traditional agile mindset needs to be
transformed to work @ scale
• DAD can be a transformational framework for teams practicing Scrum tomove
• DAD works best across different lifecycle models and can help scale acrossheterogeneous projects practices Scrum, Kanban, Waterfall etc.
• DAD can help identify the scaling factors which may form the bottleneckand help overcome it
• DAD works best and complements scalable frameworks like SAFe™
61
DAD can form a foundational team framework for teams to scale
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
DAD Vs. RUP
• 3 Phases: Inception,Construction, Transition(Elaboration in RUP is seen asBRUF-non agile)
• Uses Work item list withpreference for User Stories.However, in regulatoryenvironment, it advises tohave Use Cases. Work Item listprovides flexibility to add typeof work item.
• DAD is goal driven and notartifact driven.
• 4 Phases: Inception,Elaboration, Constructionand Transition
• Use Case Driven approach(User Story DrivenApproach (Does notprescribe Use Case drivenapproach as it may lead topotential exhaustiveRequirement Spec)
62
DAD RUP
DAD strength is to allow the process to adapt to the situation and notbe prescriptive.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Potential Candidates for
Scaling Agile
63
Large Scale Scrum(LeSS)
Disciplined AgileDelivery (DAD)
Toward beingSAFe™
…Scrum ofScrums
…Scaling with
Kanban
Rational UnifiedProcess
Rational UnifiedProcess
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
About Scaled Agile Framework• Enterprises with large Programs need to standardize the planning
and execution process
• Every team within the program need to collaborate to deliveroverall value
• SAFe is a proven public facing framework
• Uses Lean & Agile product development practices at Enterprisescale
• Simplistic approach of common agile methods though work at teamlevel, at scale things become complicated. At scale, some processdesign needs to be put in place which makes people say “It’s notAgile”.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Scrum Vs. SAFe
• For Small teams• Silent on Development
practices• Release planning advocated
practice. No cadence basedplanning
• No 2 days release planningevent
• Focused on aligning atsoftware developmentteam level
• For Large Enterprise teams• Advocates leveraging XP• Release Planning part of
SAFe, which is a 2 day event• Same Roles and rituals as
Scrum @ team level• Apart from team align,
guides about how we canstrategically at portfolio /organization level
Scrum SAFe
Scrum & SAFe are aligned if we do not focus on perceived differences!!!
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
SAFe - Comments• Unlike other Scaling Solutions, SAFe defines important role for
management and does not exclude them
• Depends on Demings quotation– Only managers can change the system – because managers create
systems. Change needs to come from the middle
• Decision making is delegated to the teams. But, logic of making thedecision is controlled by the managers
• SAFe is highly influenced by Rational Unified Process (DAD is moreinfluenced by RUP).
68
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Anti-SAFe• Adds more hierarchy which goes against the concept of removing
hierarchy in daily activity
• More rituals like ART meetings & teleconferences (unlike peer-to-peer communication in large tech companies like Google, Facebooketc. which have agile type scaled processes)
• Teams being synchronized along PI cadence, slows the process.Some methodologists feel this slows down the process. They wantAgile @ Scale to be still faster
• Reverting back to old big-bang releases against Agilist’s expectationof small and frequent consumable releases
69
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Anti-SAFe
70
SAFe is by far the most popular. Hence, it isn’t short of its detractors.
A core premise of agile is thatthe people doing the workare people who can bestfigure out how to do it. Thejob of the management is todo anything to help them doso, not suffocate them withSAFe- Ken Schwaber
70
This approach fits right in withthe requirements of CMMI ML3for process tailoring. It could bestraight out of 1990’s textbookon process engineering.- David Anderson
Shitty Agile for Enterprises- Martin Fowler
I’ve just watched apresentation that’s made meso angry it’s prompted me towrite my first blog post inages! … I’m not a fan of the“Scaled Agile Framework” tosay the least …. Yuk Yuk Yuk
-Neil Killick
Someone just shot the Agilebrand in the back of the head- Chris Matts
L.A.F.A.B.L.E – Large AgileFramework Appropriate forBig Lumbering Enterprises- Mike Cohn
Put brutally SAFe seemed tobe PRINCE camouflaged inAgile language. SAFe is notonly a betrayal of the promiseoffered by AGILE but is amassive retrograde step givingthe managerial class an excuseto avoid any significant change- Dave Snowden
... Contains a lot of “processvoodoo” that will not be requiredin most case…. confusinglycomplicated framework … SAFeheightens the risk of just applying“lipstick to the pig” and notdealing with the fundamentalchanges that are required in everyorganization
- Peter Hundermark
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Flow Cracker#7, 3rd Floor, Srishti Building,8th Main, Basaveshwar Nagar,Bangalore - 560079
Email :
prasadbr@flowcracker.com Orcontactus@flowcracker.com
Cell: +91 984 555 8474
ThankYou
71
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
• EBGmt– http://www.ebmgt.org– Ken Schwaber and Gunther Verheyen
• ScALeD– Scaled Agile for Lean Development– Peter Beck, Markus Gartner, Christoph Mathis, Stefen
Roock, Andreas Schliep– http://scaledprinciples.org
• PDFbyR– Don Reinertsen– http://reinertsenassociates.com
72