Multi-project management with dispersed agile teams - Agile Austria 2018

Public
Safety
Public
Transport
Air Traffic
Management
Maritime
Defence Multi-project management with
dispersed agile teams
Five years of agile transition – an agile journey
Maximilian Hantsch-Köller, Frequentis AG

| © 2016 Frequentis AGPublicMulti-project management with dispersed agile teams3 |
Agenda
The company – safety first
Safety environment and challenges
Possible approaches
Frequentis‘ choice
Daily routine
Observed results and lessons learned
Where to go from here?

The company

| © 2018 Frequentis AGPublicMulti-project management with dispersed agile teams|5
More than 65 years of innovation in safety-critical applications
We set standards
Public
Safety
Public
Transport
Air Traffic
Management
Maritime
Defence
Control centres
worldwide

Global market leader
Headquarters Vienna
1,309 Employees
80% STEM*
Solutions partners and regional
offices in over 50 countries
228 M EUR
turnover 2015
12%
95%
Export
R&D
*) Science, Technology, Engineering, Math
Established
+
1947

Frequentis regional offices
Sales representatives
Status: E01/2016
90%
of all passengers worldwide are
served by Frequentis customers
25,000
working positions using
Frequentis solutions
more than
300 120+
customers countries
33%
of the world safer with Frequentis
networks
#1
in GSM-R dispatcher terminals
200,000km
protecting the largest maritime
coastline
COMSOFT Solutions (complementary only)

Largest maritime coastline
safer - 200,000km
#1 GSM-R dispatcher terminal
market share
More than 300 customers
#1 VCS ATM market share
Largest public safety control centre
in Europe

We understand and embrace the safety critical environment of our customers
Safety critical
environment
Culture
We live it
We de-risk it
We sustain it
Success
Understanding
Know How

Agility Largest CCC* in Europe
• ˃500 working positions
• 55,000 CCTV cameras
• Partnership contract extension for ESN
(Emergency Services Network)
Core competencies
Technology
leadership
We set
standards
Projects are
our business
User centric
development
Integrated
quality &
safety mgmt.
Thinking
ahead
20+ years
lifecycle
mgmt.
Shaping
the future
European sky
*) Command and control centre
+
Joint undertaking
partner
OneSKY
Key technology
provider for first fully
harmonised
civil-military ATM
system in Australia

Safety environment and
challenges

Control centre across industries
Public
Safety
Public
Transport MaritimeDefence
Air Traffic
Management

Control centre across industries
Public
Safety
Public
Air Traffic
Management

Public
Safety
Public
Air Traffic
Management

 presenting all relevant data from
an airport
 data are display in different
formats graphical / numerical
oriented (including animations)
 customization to local situation /
specific airfield layouts
 highlighting of critical information
– RWY Block
– Wind Thresholds – RVR Values
– critical value changes
 indication of outdated values

Technique
Team Organisation Environment
Individual
Lowering of:
• Costs
• Modifications
Improvement of:
• Workflow
• Teamwork
• Organisation
• Communication
Enhancement of:
• Safety
• Dependability
• Productivity
• Job satisfaction

 Airplanes cannot stop in mid-air
 There are human lives involved
 Aeronautical services must be provided
at all times
 Data must be accurate

 There are Human Lives involved
 Aeronautical Services must be provided
at all times

 There are human lives involved
 Aeronautical services must be provided
at all times

 Failover and redundancy:
- In case of a single server failure, the failover to the other standby server shall be done in less than
ten seconds for 95% of the failovers.
- During recovery from any failure mode the system performance shall stay within the acceptable
limits indicated in Appendix A.
- During failure of all servers, the clients shall remain functional in a standalone mode.
- When changing a position due to a working position failure, the activation of the role, elsewhere,
shall take effect within 2 seconds at an already running position for 95% of all changes and not
longer than 4 seconds.
 User interface
- The response time on user actions shall conform to targets in Appendix A Table A-1 'Performance
Target Response Times', during operation within the defined system capacity.
 Other
- No single points of failure
- 24x7 operation – no „maintenance downtime“

 DO-278/ED-109 Software Standard for Non-Airborne Systems
 ED-153 - Guidelines for ANS1 Software Safety Assurance
- both provide guidelines for the assurance of software contained in non-airborne CNS/ATM2 systems
- depending on the impact of a software failure, different levels of assurance
- tracing from high level requirements to low level requirements to code coverage / statement
coverage / decision coverage (depending on assurance level) and test cases (system / software /
component / unit)
 massive control structure around the software development process
- documentation & reviews at every stage
- yields towards waterfall process with requirements engineering -> system design -> software
design -> code implementation -> tests
- auditable proof that sound engineering practices have been followed
1 ANS: air navigation services
2 CNS/ATM: communication, navigation and

 Software assurance is demanded by regulatives, and as a result, by our customers
Waterfall timeline of a typical project
 Multiple deliveries / parallel projects (out of product core)
 Growing teams in several locations
PO
CDR
DDR
SQT
FAT
SATContract
Award
Go
Live

time
the teams
Vienna Romania

software is made by people
software architecture follows people organisation
software branches, de-couple everything
time
PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
project teams

 De-coupled projects from each other
- Separate Timelines
- Separate Project Teams
- Separate Software Branches
 Optimal team size? Move people around when priorities change?
 Different skill sets in different locations?
 Lifetime of these teams? Re-shuffling for next project?
 Moving know-how from all these projects to your product base?
=> How to keep de-coupled stuff together?

Possible approaches

 Teams: 7 ± 2
 Co-locate teams in one location
 Build functional teams, not component teams
 Ensure teams have all skills needed to deliver end-to-end
 Invest in story writing, build and prioritise a product backlog
 Deliver often and early
 If it is hard, do it more often
 Learn frequently and iteratively
 People and communication over processes and toolsIndividuals and interactions

 Co-located: everyone is in one location
 Distributed: teams are in different locations, but within one team everyone is in one
location
 Dispersed: people within the team are in different locations

location
ViennaVienna Vienna

location
Vienna Vienna Romania

location
Vienna Romania

Design / Development / Testing / System Engineering
Scrum Teams
A
B
P
B
C Iterative Work
smartTools smartStrips
Product
Owner
Product
Owner
backlog
backlog
B
C
A
P
A
B
B
P
Project ConfigCustomer
Solution
smTools
smStrips
PdM
PdM
Project CProject BProject A
Req Req Req
Timeline
v1.2
B
C
A
P
v1.1
2.9. 30.9.
Default Config
Docs

PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
PO
CDR
DDR
SQT
FAT
SAT
time
Vienna RomaniaViennaRomania
A
B
P
B
C
sprint 1 sprint 2 sprint 3 sprint 4 sprint 5 sprint 6 sprint 7 sprint 8

Frequentis’ choice

 Organise around products: Product Owners, Product Backlog
- interface projects to the development teams through product backlog
- learn to write stories
- product owner acts as gatekeeper
 prioritise by reordering backlog items instead of reordering people
 transparent resource planning based on velocity and story point estimations
 drive active participation of projects
- invest in communication

 Use Scrum to deliver out of Dispersed Teams
- some skills only available in one location (testing, lead architects)
 Implications we knew we had to take care of:
- online collaboration tools, video conferencing
- scrum trainings, intercultural trainings
- invest in communication
 Project Know-how
- some team members to be assigned as project experts
 Helpful advice from the community:
http://www.infoq.com/presentations/The-Kiev-Experiment

Daily routine

 Video and audio conferencing everywhere
 Online backlog and task boards in Jira / Jira Agile
 Collaboration rules
- e.g. Backlog refinement with at least 3 team members, at least 1 from each location, and 1 with
testing background (if possible)
 Definition of done
- e.g. Jenkins builds blue, deployment on test system ok, all traces from requirements to test cases
complete and reviewed, all test cases for backlog item successful, documentation updated, all
automated system tests green, all code reviewed in Crucible etc.
 Definition of ready
- e.g. Story traced to causing requirements, requirements approved, acceptance criteria agreed,
estimation completed
 Simplified process
- toolchain to provide auditable assurance proof
- Jama for requirements and test management

 Management
- 4-weeks, then 3-weeks sprints (some teams now also down to 2 weeks)
- regular backlog refinement sessions to pre-estimate stories
- stories include acceptance criteria in Gerkhin language
- mid-sprint review, bi-weekly project briefing, cross-team stand-ups (as needed)
 Practices
- test driven development
- pair programming
- collective code ownership
 Tooling
- continuous integration / unit tests / junit
- automated component testing / jbehave
- continuous deployment
- automated system tests / jbehave + Frequentis distributed system testing framework

Sprint demo

Observed results and
Lessons learned

 Observations
- Teams felt relieved from project priority clashes, they felt more appreciation, more self-control, and
more motivation
- Teams learned the value of communication – started to talk to each other much more across
borders
- Teams were able to increasingly clean up debt in the product
- Productisation of features increased
- Project timelines became more stable and achievable
• after initial hick-up ;-)
 Lessons Learned
- Believe in it and keep going forward. It does get better!
- Crucial to have full support by management. We had it.
- You can deviate from the book. But know why there is a recommendation.
- Stories are not Requirements.
=> Long-term management of product feature documentation?

0
200
400
600
800
1000
1200
StoryPoints Burnup - Total
Target
estim.
done
trend (Target)
trend (done)
Total Backlog Size
Estimated Forecast
Actually Done

 Scrum introduction in ATM Automation
- two products, three Scrum teams
- dispersed in two locations (Vienna, Cluj-Napoca)
- experienced Scrum masters to start the teams, then handover after a few months
 Agile trainings for the company
- external trainers held Scrum trainings a few times
- management support to promote the trainings and get employees to join
 A limited number of “Scrum islands” (also some starting in other departments)
- learning process for the teams
- learning process for the organisations working with these teams
 First successes
- stabilized roadmap and releases of smartTOOLS and smartSTRIPS
- successful launches at customer sites
- rate of bug reports decreasing, product cleanup, team spirit improved

Where to go from here?

Public
Safety
Public
Air Traffic
Management

 Automated System Acceptance Tests
- Continuous Acceptance Test Scheme (CATS)
 In-house training programme
- Combination of external trainers and in-house education
- Several tracks geared to scrum masters, product owners, project managers, …
- In-house Agile Coach
 Community of Practice: „FRQ Agile Community“
- Regular Community Events: „Agile Breakfast“, „Agile Open Space“, …
 Functions and career levels
- Scrum Master, Kanban Facilitator, Agile Coach....
 Agile Facilitator
- Product Owner, Product Manager, Project Manager....
 Strategic Product Manager and Operational Product Manager

 Scaling: the FRQ Agile Framework Model
- Interworking between strategy, customer projects, and product development
- Company-wide Metrics
- Scaling to subsidiaries and other companies within the FRQ corporation
 Agile PM Guidelines
- Guidelines and „good practices“ for project managers
 Apply agile practices with customers
- Offer calculation from story estimates
- Enrich classic requirements engineering with agile practices (Story Mapping, Impact Mapping…)
 Kanban flight level 2+
 Agile Assessment
- Self-assessment questionnaire for teams and product programs
- For teams to figure out where they stand in their path and what they may want to focus on next
- Determine an overall "Agility" metric for Frequentis

Public
Safety
Public
Air Traffic
Management

Public
Safety
Public
Transport
Air Traffic
Management
Maritime
Defence

Multi-project management with dispersed agile teams - Agile Austria 2018

Recomendados

Recomendados

Más contenido relacionado

Similar a Multi-project management with dispersed agile teams - Agile Austria 2018

Similar a Multi-project management with dispersed agile teams - Agile Austria 2018 (20)

Último

Último (14)

Multi-project management with dispersed agile teams - Agile Austria 2018