flowcracker agile @ scale

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: [email protected]. Cell: 9845558474


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/


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


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


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


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.


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


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


Potential Candidates for

Scaling Agile

10

Large Scale Scrum(LeSS)

Disciplined AgileDelivery (DAD)

Toward beingSAFe™

…Scrum ofScrums

…Scaling with

Kanban

Rational UnifiedProcess



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


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


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.


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


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


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


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


Co-ordination between teams

• Scrum of Scrum meetings• Synchronization sprints

18


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.


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


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


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



Scaling Agile

23



Toward beingSAFe™

…Scrum ofScrums

…Scaling with

Kanban




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


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


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


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


Less FW1 – Events/Ceremonies

• Six Ceremonies/Events– Sprint Planning– Daily Scrum– Product Backlog Refinement– Sprint Review– Sprint Retrospectives– Joint Retrospectives

28


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


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


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


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


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


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



Scaling Agile

35



Toward beingSAFe™

…Scrum ofScrums

…Scaling with

Kanban




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.


Kanban Foundation Principle

1. Start with whatyou know

2. Agree to pursueincremental,evolutionarychange

3. Respect currentprocess, role,responsibilities andtitles


Kanban Core Practices

1. Visualize

2. Limit WIP

3. Manage Flow4. Make Process

policies explicit

5. Implementfeedback loop

6. ImproveCollaboratively

Shallow implementation

Deep implementation


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.


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



Scaling Agile

41



Toward beingSAFe™

…Scrum ofScrums

…Scaling with

Kanban




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


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


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


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


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.



Scaling Agile

47



Toward beingSAFe™

…Scrum ofScrums

…Scaling with

Kanban




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.


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


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



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.



DAD – Goal Driven & NotPrescriptive

52



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


Basic Life Cycle: Scrum + RUP

• Iteration based• Uses work item list not backlog• Value Risk based prioritization

54


• Defines Agile Governance which hasmilestones across the lifecycle –Stakeholder vision, provenarchitecture, project viability,sufficient functionality, productionready, delighted stakeholders


Advanced Life Cycle: Lean Based

• Iteration-less, Continuous flowof work

• Some teams may migrate fromScrum to Lean based life cycle

55


• 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


Advanced Life Cycle: Lean CD Based

56


Product is shipped into productionon a regular basis : daily, weekly oron-demand


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


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



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


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.


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


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.



Scaling Agile

63



Toward beingSAFe™

…Scrum ofScrums

…Scaling with

Kanban




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


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!!!


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


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


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 :

[email protected] [email protected]

Cell: +91 984 555 8474

ThankYou

71


• 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

flowcracker agile @ scale

Technology

copyright flow cracker

respective owners

agile academy durgaprasad

agile coach industries

agile academy developer

continental technologies

web technologies

agile different frameworks