Adopting Scaled Agile Framework (SAFe) The Good , the...

of 45 /45
Adopting Scaled Agile Framework (SAFe) The Good, the Bad, and the Ugly James Janisse VP Connected Navigation System Navigation Product Unit

Embed Size (px)

Transcript of Adopting Scaled Agile Framework (SAFe) The Good , the...

  • Adopting Scaled Agile Framework (SAFe)The Good, the Bad, and the Ugly

    James JanisseVP Connected Navigation System

    Navigation Product Unit

  • TomTom @ a Glance

    Founded in Amsterdam in 1991

    1 billion euros annual revenue

    3,600 employees in 35 countries worldwide

    75 million PNDs sold since 2004

    3 million in dash navigation systems sold since 2009

    Our maps cover 116 countries reaching more than 4 billion people

    Real-time traffic service in 36 countries

  • Agenda


    Context setting

    The situation in 2012

    The resulting strategy

    Actions Taken 2012-Present

    The Good

    The Bad

    The Ugly


  • Navigation Product Unit


    Consumer devices

    Smartphones & tablets

    In-Dash systems

    Internal Supplier

    250 people in 40 scrum teams

    10 locations & 8 countries

    100% of the turn-by-turn navigation code

    80% of the total solution code

    Navigation Engines

    User Interface

  • Situation in Early 2012






  • Strategy

    Observation Impact

    Project orientation Run and optimise the department as a professional services team

    Stage-gate milestones process for governance

    Did not actually manage or mitigate risk as projects can fail a milestone or pass with concessions and keep going

    Does not enable portfolio planning or prioritisation between projects

    Poor visibility and facts based decision making

    Actuals based on earned task hours Forecast based on estimated hours remaining to complete






  • ProductStrategy





    Observation Impact

    Each product and product extension is a branch of the mainline code

    10+ branches of the mainline code Create a catch-up project for every

    branch to try to re-integrate (15-25% extra effort)

    downstream teams spend 3,4,5 months accepting the code and often changing it

    Many projects working in all parts of the code with minimal module or component ownership

    Enormous effort, risk, delays, stress to integrate project changes back into mainline

    Most projects break each others code

  • PeopleStrategy





    Observation Impact

    Resource managers and a matrixorganisation

    Who is accountable for what? Aggressive and determined project

    managers fight for their project and to get resources

    Bring people to the requirement and form a project

    Start up cost and delays Never worked together before Spend time creating a way of working Cannot estimate velocity for 2+ months No historical estimate repository

  • ProcessStrategy





    Observation Impact

    Feature complete over quality

    Downstream teams receive a lot of defects, and have to resolve these themselves

    3-5 months acceptance period required for downstream integration/ commercialisation team

    Developers do not have to maintain their code

    Guess what happens?

    KPIs are all Projectoriented: on-time, on-budget

    No continuous improvement as each project is different

  • TechnologyStrategy





    Observation Impact

    Negligible automated testing

    Mostly manual testing full regression requiring 3-4 calendar

    weeks and a team of 4-5 people

    No continuous integration

    Typically completed at the end of the project or every few months

    Integration often blocked by other projects changes

  • Conclusions from 2012

    1 August 201411

    Many products and releases are months-quarters late

    Quality is decreasing

    Costs are increasing

    Time-to-market is increasing

    Branching the code is evil

    Project orientation is wrong

    Poor Accountability

    Complexity is too high

    Significant Waste

    Insufficient information to make effective decisions

  • 4 Key Objectives for 2012

    1 August 201412

    1) Reduce End-to-End Cycle Time

    2) Reduce End-to-End Effort & Waste

    3) Improve Quality

    4) Clear accountability

  • 5 Key Changes 2012-2014

    1. Adopted Scaled Agile Framework by Leffingwell

    2. Re-organised from Scrum Teams up

    3. Adopted High Assurance S/W Requirements Model

    4. Implemented Rally for Planning & Reporting

    5. Automated testing with Continuous Integration


  • #1: Adopted Scaled Agile Framework

    1. Replace homegrown Feature Flow methodology with SAFe

    2. SVP reads book cover to cover on his vacation

    3. SVP buys book for CTO and other SVPs

    4. SAFE Training

    5. Trained

    1. 75 Certified Scrum Masters &

    2. 50 CPOs

    6. Re-organised


  • Re-organised from Scrum Teams Up

    Key assumption is value is only created by scrum teams

    Organise into Product clusters and component scrum teams

    One Agile Release Train per Product

    Every active/viable module/component is allocated to one and only one scrum team

    Adjust/supplement all scrum teams to have scrum master, developers, etc

    Everyone not in a scrum team is put in a backlog i.e. Project Managers, Resource Managers, Team leads.

    Design a thin/lean program support team to feed the scrum teams: Product Owner, Architect, Systems Team

    Design a thin/lean portfolio team


  • Agenda


    The Good

    The Bad

    The Ugly


  • You Decide

    Decide to adopt SAFe

    Stock = 3/share

  • You Decide

    Decide to adopt SAFe

    Stock = 3/share Stock is now 6.1 /share

  • 01/08/2014


    There is no doubt in my mind that without SAFe and Rally we would not have launched this in only 140 days. It is also our best new product ever

  • Information

    Observation Impact

    Single shared backlogavailable to all to view

    Improved transparency and info sharing

    Historical repository of estimates and actuals

    Improves estimating by allowing historical comparisons

    Enables estimation accuracy analysis

    Historical record of velocity and delivery reliability

    Visible to the whole business so that everyone can see the health and output of all teams

    Stops academic debating Forced consensus unless there is a smarter way

  • Product

    Observation Impact

    Simpler & consistentrelease schedule

    Makes customers lives easier to know that a new PSI is available on fixed and shared dates

    Reduced cycle time Get innovation out the door faster

    Allows testing to go upstream

    Customer/downs-stream acceptancetesting can be embedded with each story or feature to ensure it is accepted at the end of the sprint vs waiting to accept it post PSI delivery

  • People

    Observation Impact

    Bring requirements to perpetual teams

    No start-up delay or effort Lifecycle management guaranteed Track record of working together Self improving teams Stop timesheet reporting

    More sustainabledevelopment

    Teams select how many stories to bring into their release and sprints

    Enables bigger picture view

    Release planning days Release demo days Scrum of Scrums

  • Process

    Observation Impact

    Bring requirements to perpetual teams

    Known way of working More accurate planning and estimating Tailored way of working per team

    Eliminate project milestones and stage gates

    Budgeting is an annual activity to balance product/team spending

    Given budget, team size, and release dates are fixed, team just has to perpetually prioritise scope for maximum business value/PSI

    Easy to add a new scrum team

    Adopt de facto processes, schedules, tools, methods

  • Technology

    Observation Impact

    Automated testing More thorough testing More timely test results Increases customer confidence

    Continuous Integration

    Quicker feedback Detect/prevent issues with each new submission

    No bottleneck at the end Reduces cycle time as others stay up to date

    Facts based qualityanalysis

    Statistical analysis of code quality available to compare across teams, products,

    Self-organising quality improvements

  • Agenda


    The Good

    The Bad

    The Ugly


  • Information

    Observation Impact

    Normalised story points & t-Shirt sizes suck

    Seen as an invention by management with no value for the team itself

    Everyone can see everyones backlog, priority, throughput

    Everyone can second guess your prioritisation

    Everyone can second guess your estimates

  • Product

    Observation Impact

    Limited by the critical chain product/team

    Each scrum team can aim for maximum efficiency, velocity, quality but they are still part of an ART

    Teaches the business that Agile = 100% predictable

    What happened to iterative development?

    What happened to incremental development?

    Dont print features on the box at the start of the PSI

    Enables the business to change direction/ strategy/ priorities often

    Lets face it, too much Agility is just an inability to make choices and decisions i.e. chaos

  • People

    Observation Impact

    Decrease in employee and product satisfaction

    High energy and engagement BUT engineers feel early PSIs were incomplete as they were not feature parity

    Organisational design Incompatible with a matrix organisation

    Career management? Do you want a scrum master giving career guidance to everyone in their team?

    Highlights inconsistencies in roles & levels

    Historical debt of having uncontrolled job grades, titles, levels, etc

    Issues with Jr. and Sr. Titles and levels Issues with relative size of ARTs

  • People

    Observation Impact

    Shows week teams Teams that normally staid below the radar which no one new what they did are suddenly very exposed to the daylight

    Less role types and levels = less opportunities

    Less vertical career growth opportunities What happens if you are on a second tier


    Teams are not interchangeable

    People are prone to comparing velocities, cycle times without understanding non standard Story Point scale, tech debt, technology choices, dev ops issues

  • Process

    Observation Impact

    Goes on forever without a break (HIP downtime)

    Projects used to have a nice slow start up and shut down phase, so cyclical rhythm

    Now work is harder and does not let up

    Teams need to align on cadence/dates

    Teams that never had to coordinate their schedule suddenly have to adopt a common schedule for their ART

    Teams need to align on basic Way of Working

    Teams that has their own home grown way of working suddenly need to standardise how they work

  • Technology

    Observation Impact

    Not all tooling is fit for purpose

    Effective portfolio and product management across multiple teams is not always supported

    Deep hierarchical backlog is hard to model Rolling up reports above scrum teams can

    be difficult/impossible with light weight scrum tools

    Increase load on Dev Ops (testing and continuous integration)

    Continuous integration with expanding automated testing frameworks can get larger and larger and slower and slower

  • Agenda


    The Good

    The Bad

    The Ugly


  • Information

    Observation Impact

    Shared information and transparency can lead to politics

    Teams can start mis-information campaigns to distract and deflect attention for their own poor performance

  • Product

    Observation Impact

    PSI does not mean release everything, all once, every time

    Potentially shippable does not mean that the business is relieved of having to make business decisions on risk/reward of each new feature.

  • People

    Observation Impact

    Some teams will resist

    Reject the need to be part of an ART Reject the need to have common ways

    of working

    Some people loose power

    Project managers loose scope, resourcing, and budget

    Resource managers are no longer needed

    Levels and role consistency

    Can lead to a lot of unhappy employees, HR issues, administration

  • Process

    Observation Impact

    Centralised decision making shifts to decentralised

    Evolving decisions to the lowest level threatens central portfolio level experts like architects and makes guiding independent teams hard

    Fully defined transforms to barely sufficient

    Architects still love to make future proof architectural designs and plans

    UX want to make pixel perfect designs for all use cases

    Sometimes one ARTruns over anothterART

    If a product or launch requires multiple ARTs, then the speed is limited to the slowest, typically system integration

  • Technology

    Observation Impact

    Very large Monolithiccode base cannot be continuously integrated

    What happens when the number of Integration slots available within a sprint does not allow each scrum team to check in daily, let alone weekly?

    Very large Monolithiccode base cannot complete daily regression testing

    What happens when the automated regression cycle takes more than 16 hours (i.e. cannot be completed after hours)

  • Agenda


    The Good

    The Bad

    The Ugly


  • 4 Key Takeaways

    1.People: Address career management and mentoring

    2.Basic consistency within the organisation

    Agile means scrum teams decide and manage themselves 100% independently right?

    3.Bigger Picture:

    Optimise for the Portfolio or ART not for each scrum team

    01 August 201439

  • 4 Key Takeaways (contd)

    4. Tooling:

    Deeper, broader, more complicated hierarchical capability tree

    added four more levels above a user story

    Active dependency tracking


    Need to be able to roll up, drill down, lateral/diagonal slice & dicing

    01 August 201440

  • Summary

    The Good far out weighs the Bad and the Ugly

  • Questions?

    01 August 201442

  • 01 August 201443

  • 01 August 201444

  • 01 August 201445