How Dealogic Scaled Agile &; Delivers Effectively

Agile Meetup
Dealogic - Agile
Revolution
Presented by Irfan Ikram & Hemant Patel

Dealogic Limited 2017 Page 2
About Dealogic
Founded: 1983 in the United Kingdom
Ownership: The Carlyle Group (majority) and co-investors
CEO: Thomas Fleming
Offices London, New York, Hong Kong, Tokyo, Sydney, Mumbai,
Budapest, Sao Paulo, Beijing
Staff: >800

Overview

How is our software is used?
Find Client:
Analytics
Software
Pitch to
clients:
Ranking
tables
Find
Investors:
Conference
s/w
Research
Investors/Co
mpanies:
Mobile App
Execute Deal:
Transaction
S/w
Track Orders:
Pulse App
Bonus: Based
on DL
rankings
IPO Example

Delivering once a
quarter to…..
…30 global
teams each
delivering every
two weeks
Well how do we
do it?

Dev & that Ops thing
What does DevOps mean to you ?

Dev & That Ops Thing
Dev Ops

The Ops team

 Ops learnt late of change
 No Feedback loop
 It works on Dev so it will work on Prod ?
 Dev teams knew nothing of Ops
 Ops knew nothing of Dev
 No one was over the software from Dev to Production.
The problem we needed to solve

The Delivery aligned Ops team

 Aligned Cadence
 Common Tooling
 Kanban
 Area matter experts
 Ops team empowered to say No
 Team lead between Dev & Ops

The Good Part
 Ops Alignment
 The Ops Ambassadors
 Changed known early
 Dev reached out
 Happier & more Innovative
 Little but often approach
 Boring Deployments

Something was still missing
 Roadblocks
 Post Sign-Off Disconnect
 Regular Feedback but late

The Dev with Ops Team

An embedded Dev & Ops team was Created
 Dev team with added members from Ops
 Team followed You Build It, You Run It…
 Ops members were empowered to be T shaped & Dev to look at Prod
The Dev with Ops Team

The Current Workflow

 Diagnostics & Usage Logs
 Event Log, Databases, Google Analytics
 OMS
 Dev
 MTM
 Visual Studio
 Deployments
 PowerShell automated Deployment mechanism
 MS Orchestrator Runbooks with PowerShell to deploy to production
 Infrastructure
 System Center Operations Manager
 Microsoft Azure
 Source control management
 TFS
 GitHub
Finally the Tooling to Support this

Deploy Regularly & Safely
No matter how good the code, if no one can see it then it doesn’t exist ?
We deploy to production every 2 weeks
A typical Pipeline at Dealogic
The technology stack
 PowerShell based installer framework
 MTM to run automated tests
 MS Orchestrator to build production stages
This differentiates successful companies from everyone else
Integration Test
Platform
Integration
Staging Production
Perf Test Pen Test

Integration Test
 Deployed once an hour
 Runs all automated installation and mock based integration tests
 Health Check tests
 Deployment takes 30 minutes
 We are breaking this stage up into many smaller ones now
Platform Integration
 Deployed twice a day
 Used for Manual testing by QA team
 Aim to have a staging deployment candidate each day. Full sign off.
Spotlight on Dev
Integration Test
Platform
Integration
Staging Production
Perf Test Pen Test

 Deployed Every 2 weeks with QA passed Build
 Staging deploy is part of the iteration
Blue/Green Deployment
 Staging & Production a full likeness of each other with all the relevant Infra setup
 This is production * 2
 Once Staging is signed off we switch Staging & Production
 Now staging is Live (Production)
 Rollback means switching the other way in the worst case
 Downtime is around 30 minutes between switches at the moment.
Spotlight on Staging & Production
Integration Test
Platform
Integration
Staging Production
Perf Test Pen Test

Perf Test
This is run every few weeks, usually on request
 Indications given of performance on production
 Requests made for this when larger changes are made that could impact performance
 Microsoft Load Test framework used
Pen Test
This is run every quarter
 Experience Pen Tester brought in
 Helps understand where any security holes may exist
Spotlight on Perf & Pen Test
Integration Test
Platform
Integration
Staging Production
Perf Test Pen Test

We are currently evolving our deployment practices for Rapid Releases.
Micro pipelines around a very small code base.
 Code is managed by a single team
 Testing is quicker as less to sign off and more targeted
 Each package is independent
 Others parts can go to production even if one part fails.
Rapid Release Pipelines

Deployable
Unit
CI Versioning
Nuget
Dependencies
Regression
tests
Deployment
Pipeline &
Installer Tech
A typical Deployable Unit setup

Rapid Release Pipeline
Component 1
Auto Test
Platform Integration Staging Production
Component 2
Auto Test
Component 3
Auto Test
 Platform Integration/Staging/Production are shared environments
 Each component has vigorous automated regression tests
 Sign off now is at component level not product level
 Dev – Prod is very rapid, team controls how often they go to prod
Run to prod every day
Run to prod every 3 days
Run to prod every week

DevOps and Pipeline
Thoughts?

Teams empowered to Deliver
A Good team is one that knows WHAT IT CANNOT DO
Understanding what you can’t deliver is the most important question to ask…
 Teams empowered to push back
 Components are Open Source
 The teams believe in the process we follow
 Expert Domain Knowledge in their component.
 Little but often philosophy
What the Team Cannot Do

Our Typical Team Structure
Snr
Developer
Developer Developer QA
Snr QA
Dev
Manager
BA TA Guide, Protect & Drive
Steer Continuous Improvement
Drive Delivery

Tech Debt
Teams at Dealogic are encouraged to track Tech Debt and manage it.
 SonarQube used to track Debt metrics
Effective Leadership
 Bi-Weekly grooming meetings are key for each team
 Teams motivated to look ahead
Fail Fast
 All teams are encouraged to not be afraid of failing
 A big philosophy is to try new things and improve our tech/processes continuously
Self Improvement

Minimizing Collaboration ?
Some Collaboration is cool…

Some Collaboration is required…

Maximizing the time teams are not blocked makes them Happier & More Productive
The Past
 Multiple teams working across same code base
 Teams building the same thing twice in different ways
 No ownership -> Tech Debt build up
 In case of an issue everyone pointed to each other
 Code Overwriting became an issue
 Matter experts were hard to identify
 UX teams was pulled every which way and spread very thin. They were a blocker.
History

Some collaboration is still very important

Does this look familiar

We firstly broke down our product

Topology we are following now
Deal Alerts
Company List
Market Activity
Graphs
Framework
Deal Lookup
Report Selector
Team 1 Team 3
Team 2
Team 4

We Called it Componentization
 Each team was given its own specific area
 Ownership -> Pride and responsibility -> Expertise -> Innovation
 Re-usable & separately deployable widgets
 UX member aligned with teams to provide more personal attention
 Separate Deployment pipelines & Cadences based on teams comfortability
 All teams aligned to a common deliverable or set of deliverables
Giving Agile Teams Ownership of their own destiny

We set some basic ground rules
 Every team has its own backlog and priority list for their component
 A suite of automated regression tests need to be well defined on your component
 Nuget is used for any code dependency outside of the team’s codebase
 Being done now each team has to have its own pipeline to production for their component
 LESS alignment between teams working together
 Trust
A few things that make this all work

How it all comes together. Rapid Releases
Hey can you make
some style changes
in that company list
Company List
Auto Test
15 Minutes
Make style change
15 Minutes 15 Minutes
Dev Test Deploy
10 Minutes
All the dev/deployment is targeted around the company list and only that.
• Targeted Testing
• Targeted Deployment
Test style change Get to production
Deal Alerts
Company List
Market
Activity
Graphs
Framework
Deal Lookup
Report Selector

When Introducing Tech Debt is ok ?
How is this ok ?

Why introduce Debt at all…
Sometimes we want fast feedback on items which requires introducing Debt
 Very Fast Feedback
 Large Business Opportunity
 Strategic
 WHEN it will not cause a bug in the system
 NOT to squeeze more work in

The art of managing tech debt…
The reason we aren’t afraid of introducing Tech Debt is because we Manage It
 Any debt that is introduced is acknowledged as what it is, Debt.
 Items are created in the backlog to clean-up this debt with estimates
 All Tech Debt is understood by BA and prioritized accordingly before new debt is introduced
 Once new Debt is tackled existing Tech Debt prior to this is tackled and items created around that
 Tech Debt isn’t always in code, it can be deployment, testing, operations etc..
 Introducing Tech Debt shouldn’t feel good or natural but is a last resort to achieve something

Quality
At Dealogic our Quality goals don’t stop at just confirming functionality
 To maintain a great product we look at quality at all angles
 Security
 Performance
 Automation
 Installation
Security
Our clients expect us to secure our systems and by extension any data they supply us.
 We run automated scans each iteration via a third party
 We have a Pen Tester who manually checks security vulnerabilities every quarter
 We align our security rules sets with our clients
Going beyond just logic testing…

Quality
Performance
If no one can use your system because its un-responsive then no one will…
 Performance Test team
 Visual Studio Load Test
 Load tests mimic usage
 Server side applications put under stress
 Agreed KPI’s maintained

Quality
Automation
Why do the same thing 1000’s of time when a machine can do it…
UI
 Java script tests using Jest & Junit
 UX automated tests using Specflow & Selenium
 Wiremock used to mock service returns
Back End
 Unit Tests written in Visual Studio
 SQL Tests written using MS Test
 Integration Tests written using MS Test

Quality
Installation
We like to be confident that we think we have installed we actually have
 Automated health check tests pings each installed component
 MTM used to run test post deployment
 Health Checks are made to be detailed enough to give clear indication to state of
component

Quality
We work hard to automate our UI tests around regression
These save our QA team a lot of time every time we run a deployment.
 Automated smokes tests run every deployment to Platform environment
 Automated regression tests run in Auto Test environment
 Tests only confirm UX not data consistency
 KeyNote used to test product on mobile & tablet platforms
A little about our UX Testing…

MVP
Give your users what
they want based on
feedback; not what
you think they want

MVP

• Roadmap alignment across teams
• revised each quarter (flexibility to respond to
new opportunities)Yearly
• 3 month forward feature forecast to
manage inter-team dependencies
and review milestones
6
Weekly
• Post planning walkthrough
• Mid-Iteration progress demo
• Next iteration Backlog review
2
Weekly
Scrum and Kanban are great at an individual team level, but what about multiple teams?

Show & Tells - Videos

Our teams do so well due in part to the continued support we provide them
Dealogic's Agile Center of Excellence
 Each team member is put through Internal agile training to create team alignment
 Agile Center helps any teams struggling with any aspect of Agile delivery
 Regular Presentations given around agile delivery trends
 Built from enthusiasts within company
Talent Management
 A group that runs workshops to allow staff to better themselves
 Leaderships courses
 Company Domain Knowledge courses
 Presentation classes
 And much more…
Help & Support

How we support all we do…our values

How we support all we do…our Environment
Before Now

How we support all we do…Yammer

How we support all we do…Recognize

Thanks to the below for source material
- DevOpsTopologies.com
- Henry Kniberg
- Alamy

That's it…
Questions ?

How Dealogic Scaled Agile &; Delivers Effectively

More Related Content

What's hot (19)

Similar to How Dealogic Scaled Agile &; Delivers Effectively (20)

Recently uploaded (20)

How Dealogic Scaled Agile &; Delivers Effectively

Editor's Notes