144
Exploring Enterprise Agile Transformation Strategies Mike Cottmeyer, Agile Coach LeadingAgile, LLC Dennis Stevens, Agile Coach Synaptus

Exploring Agile Transformation and Scaling Patterns

Embed Size (px)

Citation preview

Exploring Enterprise Agile Transformation StrategiesMike Cottmeyer, Agile CoachLeadingAgile, LLCDennis Stevens, Agile CoachSynaptus

Mike CottmeyerLeadingAgile

[email protected]

www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer

Dennis StevensSynaptus

[email protected]

www.synaptus.comtwitter.com/dennisstevens

Agenda

Agenda

• The difference between Agile Adoption and Agile Transformation

Agenda

• The difference between Agile Adoption and Agile Transformation

• The real goal of Agile change initiatives

Agenda

• The difference between Agile Adoption and Agile Transformation

• The real goal of Agile change initiatives• Competency models, our competency

model, and how to choose practices specific practices against the model

Agenda

• The difference between Agile Adoption and Agile Transformation

• The real goal of Agile change initiatives• Competency models, our competency model,

and how to choose practices specific practices against the model

• Adapting practices for different frequency intervals in your organization

Agenda

• The difference between Agile Adoption and Agile Transformation

• The real goal of Agile change initiatives• Competency models, our competency model,

and how to choose practices specific practices against the model

• Adapting practices for different frequency intervals in your organization

• Adapting practices for different levels of scale within your organization

Agenda

• The difference between Agile Adoption and Agile Transformation

• The real goal of Agile change initiatives• Competency models, our competency model,

and how to choose practices specific practices against the model

• Adapting practices for different frequency intervals in your organization

• Adapting practices for different levels of scale within your organization

• Case studies (4 in total)

Agile Adoption vs. Agile Transformation

Adoption vs. Transformation

• Agile Adoption is more about what you do… practices, tools, techniques, and habits

• Agile Transformation is more about who you are… reflected in both the structure of the organization and who you are as people

Adoption/Transformation Cycle

Organizational Transformation

Adopt Practices

Personal Transformation

Introducing Agile is Iterative and Incremental

• Changing some of the physical structures in our organization

• Teaching people new ways of working together

• Helping people internalize how and why agile really works… living the value system

Adoption/Transformation Cycle

Organizational Transformation

Adopt Practices

Personal Transformation

OrganizationalTransformation

• Establish a top-down organizational design pattern and roadmap

• Make incremental changes to the structure of the organization, build Agile teams

• Establish policies and working agreements

Adoption/Transformation Cycle

Organizational Transformation

Adopt Practices

Personal Transformation

Adopt Practices

• Instantiate sprint planning, daily standups, reviews & retrospectives

• Identify a ScrumMaster and Product Owner

• Start doing TDD and Continuous Integration

• Story Mapping and Agile Requirements decomposition

Adoption/Transformation Cycle

Organizational Transformation

Adopt Practices

Personal Transformation

Personal Transformation

• Develop a greater ability to deal with ambiguity and inspect and adapt

• Help people to work together toward common goals

• Demonstrate greater understanding and empathy amongst individuals

• Teamwork

You have to address all three aspects to achieve sustainable organizational change…

Common Anti-Patterns

• Establishing teams without breaking down the strict functional silos and rigid role definitions

• Running daily standup meetings that devolve into status updates for the project manager

• Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices

Common Anti-Patterns

• Establishing teams without breaking down the strict functional silos and rigid role definitions

• Running daily standup meetings that devolve into status updates for the project manager

• Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices

Common Anti-Patterns

• Establishing teams without breaking down the strict functional silos and rigid role definitions

• Running daily standup meetings that devolve into status updates for the project manager

• Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices

Common Anti-Patterns

• Establishing teams without breaking down the strict functional silos and rigid role definitions

• Running daily standup meetings that devolve into status updates for the project manager

• Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices

The problem with Agile Transformation is that the goal is never to adopt agile…

…Scrum and XP provide specific frameworks to help us deliver better software…

…The goal is to improve business outcomes!

25

Prod

uct D

efini

tion

Plan

ning

& C

oord

inati

on

Conti

nuou

s Im

prov

emen

t

Del

iver

y Pr

actic

es

Organizational Enablement

Value Delivery

Delivery Goals

• Faster Time to Market… frequent, smaller releases

• High quality products… low number of escaped defects

• Efficient delivery… minimize waste

• Predictability… deliver what we say we are going to deliver

• Happy Customers

26

Prod

uct D

efini

tion

Plan

ning

& C

oord

inati

on

Conti

nuou

s Im

prov

emen

t

Del

iver

y Pr

actic

es

Organizational Enablement

Value Delivery

Product Definition

• Extremely clear product vision

• Well articulated product roadmap

• Decompose product themes into fine grained product features

• Define detailed acceptance criteria and make trade-offs

• Accurately estimate effort and duration

27

Prod

uct D

efini

tion

Plan

ning

& C

oord

inati

on

Conti

nuou

s Im

prov

emen

t

Del

iver

y Pr

actic

es

Organizational Enablement

Value Delivery

Planning & Coordination

• Establish a regular planning cadence

• Break down features into tasks and define acceptance tests

• Establish a cadence of delivering working tested features

• Limit the amount of work in process

• Regularly make and meet commitments

• Continually adapt the plan

28

Prod

uct D

efini

tion

Plan

ning

& C

oord

inati

on

Conti

nuou

s Im

prov

emen

t

Del

iver

y Pr

actic

es

Organizational Enablement

Value Delivery

Delivery Practices

• Emergent Architecture and Design

• Rapid delivery of small features into the product

• Continuous testing of the product

• Clean code and fixing defects as we go

• Deploy the solution either internally or externally on demand

29

Prod

uct D

efini

tion

Plan

ning

& C

oord

inati

on

Conti

nuou

s Im

prov

emen

t

Del

iver

y Pr

actic

es

Organizational Enablement

Value Delivery

Continuous Improvement

• Metrics and Reporting

• Teams that have a stable velocity

• Retrospectives at all levels of the organization

• Manage stakeholder expectations

• Enable process improvement

• Lead and manage change

30

Prod

uct D

efini

tion

Plan

ning

& C

oord

inati

on

Conti

nuou

s Im

prov

emen

t

Del

iver

y Pr

actic

es

Organizational Enablement

Value Delivery

Organizational Enablement

• Team based delivery

• Regular checkpoints to make sure everyone is on the same page

• People work together to solve problems

• People are empowered to make decisions

• High levels of trust between coworkers

Focus less on implementing specific agile practices…

…and more on developing situationally specific strategies to solve business problems.

Competency Models… and our Competency Model

Product Definition

• Establish the Product Vision– The ability to determine and clearly communicate the product’s primary customer base, it’s

competitive differentiators, and competitive alternatives. At the release level, it’s the ability to determine why we are building this product, whom it is for, and why the release is important.

• Define the Product Roadmap– The product roadmap is the strategic plan for how the Product Vision will be executed. In an agile

organization, this roadmap should be at the Epic level and show when various Epics need to be in market. The Product Roadmap should be supported with either Epic size or budget, and be validated against proven capacity to deliver. Epics are generally 1-3 months in size.

• Decompose Features– The ability to decompose features means to break Epics into high-level feature functions that can be

communicated and/or committed to customers. Features follow the same format as user stories, but are at a higher level of abstraction, much like use cases, or use case scenarios. Features are generally take 2-4 weeks to deliver

• Estimate Size and Effort– Does the organization have the ability to accurately estimate the size and effort of a given Epic, Feature, or User

Story? Are these estimates generated using team based, collaborative techniques? Are these estimates validated with empirical evidence gathered from actual delivery of working software?

• Define Acceptance Criteria– Does the team have clear guidance on what is the definition of done? Do they know what it will take to

meet the business requirements defined by the product owner?

34

Planning & Coordination

• Establish a Planning Cadence – Is there a release train in place? Is there a regular release-planning cadence? Do the teams meet

regularly with their Product Owner to plan sprints? Does the organization do strategic planning and roadmap planning?

• Perform Activity Breakdown– Do the teams break user stories into sufficiently small increments that they can be incrementally

delivered and tracked through the sprint? If not, do the teams break larger user stories down into tasks and tests that can be tackled by more than one team member at a time

• Establish Delivery Cadence– Does the team have a pattern of delivering working, tested software every sprint? Do multi-team

projects show a pattern of coming together to deliver an integrated increment of software on a regular, periodic basis? Does the organization show a pattern of early delivery of whole Epics in a release cycle?

• Limit Work in Process– Does the organization, release architecture, or team have the ability to limit the number of Epics,

Features, or User Stories they are working on concurrently? Does the organization value completing work rather than getting new work started? Are teams allowed to focus on one thing until delivery, or are they constantly pulled onto other, higher priority initiatives. Do priorities change often?

• Make and Meet Commitments– Does the organization, release, or team regularly do what it says it will do? Do they have the ability to

make and meet commitments on short time-boxed intervals?

35

Delivery Practices

• Define the Solution – Does the team have the capability to allow architectures and designs to change as we learn more

about the emerging product? Do the team use agile modeling techniques? Is there a desire to plan everything before we start building any working product? Does the team use a value and risk driven approach to working out the systems architecture and design.

• Build the Solution– Do the developers have the tools necessary to build an increment of working software? Can software

be checked in and validated on a continuous basis. Are the teams doing unit testing? Are the tests run in a test harness at check in? Are the developers confident working in the code base? Is the code safe to change?

• Test the Solution– Is there a mechanism in place to incrementally test and validate the software as it is being built? Is all

software tested before it is accepted? Is all software tested before it is put into production? Are the number of ‘hardening sprints’ equal to or greater than the number of sprints it took to build the product? Are the teams using continuous integration and TDD?

• Technical Debt and Defects– Are defects routinely carried over from sprint to sprint and handled toward the end of the release? Do

teams have difficulty estimating work due to unexpected defects and code that is difficult to understand and maintain?

• Deploy the Solution– Is there an ability to incrementally deliver the solution, either to an internal customer for review, or to

an external customer that will actually use the product?

36

Continuous Improvement

• Metrics and Reporting– Does the organization have a package of agile metrics that support team level up to executive level

decision-making? Are there processes in place for gathering these metrics and reporting them to the appropriate stakeholders?

• Establish Stable Velocity– Can the organization, at the enterprise, release, or team levels; reliably and predictably deliver a

known quantity of working software at every iteration or release boundary?

• Conduct Retrospectives– Does the organization regularly conduct reviews and retrospectives at the end of every iteration or

release boundary? Is there a mechanism for acting on lessons learned and new opportunities discovered in these sessions?

• Update the Release Backlog– Is there a mechanism in place for quickly updating the release backlog when new information is

learned about the emerging product or when business priorities change?

• Enable Process Improvement– Is there a mechanism in place for quickly updating organizational processes in the face of impediments

that might impact product delivery?

37

Organizational Enablement

• Team Based Delivery – Is the organization formed around agile teams? Do the teams have everything they need to

successfully deliver an increment of working tested software? Are members constantly pulled away from teams and assigned to other initiatives. Is there team level accountability for sprint outcomes? Is there team level accountability for release level outcomes?

• Communication– How well do people talk to each other and communicate the right level of information? Do teams

openly an honestly share information that could help the organization be more successful?

• Collaboration– Do cross-functional teams regularly work together to define requirements, architectures, designs, test

plans, etc.? Do team members often work in silos with limited communication amongst team members?

• Empowerment– Are people and teams authorized to make decisions within their established constraints or within pre-

defined guidelines? Are decisions routinely overturned? Are the right stakeholders present when decisions are made?

• Trust– Is there open and honest communication between team members? Is it safe to share bad news? Does

management ‘shoot the messenger’ when bad news in delivered? Do people feel they can openly and honestly give negative feedback?

38

Applying the Competency Model at Different Frequencies

Strategic

Release

Iteration

Daily

Continuous

Continuous

Strategic

Release

Iteration

Daily

Continuous

Daily

Strategic

Release

Iteration

Daily

Continuous

Iteration

Strategic

Release

Iteration

Daily

Continuous

Release

Strategic

Release

Iteration

Daily

Continuous

Strategic

Applying the Competency Model at Different Levels of Scale

Team

Multi-Team

Multi-Team

Multi-Team

Program Management

Portfolio Management

Enterprise Agility

How do the three dimensions Fit Together?

Frequency

Scale

Com

pete

ncie

s

Create Situationally Specific Strategies for Each Competency, Frequency & Scale Combination

125 Possible Combinations

• Competency: Continuous Integration• Frequency: Daily Build• Scale: Across Multiple Teams

125 Possible Combinations

• Competency: Continuous Integration• Frequency: Daily• Scale: Across Multiple Teams

• Competency: Continuous Integration• Frequency: Release• Scale: At the Portfolio Level

125 Possible Combinations

• Competency: Define the Product• Frequency: Iteration Planning• Scale: Single Team

125 Possible Combinations

• Competency: Define the Product• Frequency: Iteration Planning• Scale: Single Team

• Competency: Define the Product• Frequency: Strategic Planning• Scale: Entire Enterprise

125 Possible Combinations

• Competency: Explore Improvement Options

• Frequency: Iteration Planning• Scale: Single Team

125 Possible Combinations

• Competency: Explore Improvement Options

• Frequency: Daily Planning• Scale: Single Team

• Competency: Explore Improvement Options

• Frequency: Release Planning• Scale: Portfolio Management

Assessing the Organization and Getting Better Over Time

63

Assessment Results – at Start

64

Assessment Results – at Month One

65

Assessment Results – at Month Two

Leading Change by Incrementing and Iterating Through the Organization

Incremental and Iterative Delivery

Courtesy of Jeff Patton

Incremental

Iterative

Various parts of the system are developed at different times or rates, and integrated as they are completed. You can do this in a waterfall project or an iterative project.

Go back over parts of the system to revise and improve the system. In iterative development testing and/or user feedback is used to revise the targets of the successive deliverables. The practice of iterations arises from a desire to coordinate feedback from increments to revise a future deliverable.

68

Organizational Transformation

Adopt PracticesPersonal Transformation

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Cultural Factors

Value Delivery

Organizational Enablement

Phase I

Organizational Enablement

69

Organizational Transformation

Adopt PracticesPersonal Transformation

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Phase I

70

Organizational Transformation

Adopt PracticesPersonal Transformation

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Organizational Enablement

Value Delivery

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Phase I

71

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Organizational Transformation

Adopt PracticesPersonal Transformation

Organizational Enablement

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Phase I

72

Organizational Transformation

Adopt PracticesPersonal Transformation

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Organizational Enablement

Phase II

73

Organizational Transformation

Adopt PracticesPersonal Transformation

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Organizational Enablement

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Phase II

74

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Organizational Transformation

Adopt PracticesPersonal Transformation

Organizational Enablement

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Phase II

75

Organizational Transformation

Adopt PracticesPersonal Transformation

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Organizational Enablement

Phase III

76

Organizational Transformation

Adopt PracticesPersonal Transformation

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Organizational Enablement

Phase III

77

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Organizational Transformation

Adopt PracticesPersonal Transformation

Organizational Enablement

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Phase III

78

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Value Delivery

Organizational Transformation

Adopt PracticesPersonal Transformation

Organizational Enablement

Product Definition

Planning Coordination

Continuous Improvement

Delivery Practices

Sustainability

Case Study #1 – Large Federal Lending Institution

Case Study: Situation

Financial services firm350 employees-70 in IT Software Development

Support customer facing, internal systems and integrations to third-party applications

Track record of late unpredictable delivery and high demand for production support – recent two year project took four years to partially complete

Case Study: Assessment

Planning and coordination• Low transparency• Significant WIP and individual multi-tasking• Granular detail required up-front

Organizational Enablement• Low trust and collaboration

Delivery Practices• Significant rework

Case Study: Plan

Organizational Design Patterns• 5 stable delivery teams w/ a support team• Convert Configuration Management to DevOps• Establish consolidated Value Management• Convert PMO from day to day tasking to operate at the audit and

governance level

Road-map• January: Stand up a delivery team• January: Stand up a DevOps team• February: Stand up the product support team• March: Stand up remaining teams• March: Migrate CRM-BA model to consolidated Value Management• May: Integrate with the PMO

January: Pilot a delivery team

• Established Team and Co-located everyone• Got an exception from the existing governance process• Conducted Agile Team Training and TDD Training• Co-located with the team and coached them daily (planned 3 sprints)

January: Expand to Multiple Teams

Delivery Teams

• Stood up all the teams from the original design• Conducted training for all developers• Prepared all the remaining backlogs• Pushed production support through the support team

Support

January: Expand to Multiple TeamsDelivery Leadership

Delivery Leadership

TeamDelivery Teams

• Established internal mentoring and coaching • Focus on establishing new policies and working agreements• Protect team capacity• Established and aligned Communities of Excellence

Support

January: Expand to Multiple TeamsDev Ops

Delivery Leadership

Team

Dev Ops

Delivery Teams

Rapid environment management• Stood up DevOps / CM Team• Addressed internal policy constraints on automation • Moved to automation to rapidly provision environments• Coached the DevOps Team and Production Support

Support

March: Begin Competency Improvement Team

Backlog Plan Prepare Implement Follow up

Delivery Leadership

Team

Dev Ops

Delivery Teams

Competency Improvement

Team

Support

• Jumped to the Enterprise level – Engaging the enterprise and driving efforts from the strategic plan

• Support cross functional and cross organizational change• Run transformation as an enterprise project• Updating control objectives - coaching audit and compliance• Change management is critical

April: Align with Strategy

Backlog Plan Prepare Implement Follow up

Delivery Leadership

Dev OpsDelivery Teams

Capability Improvement

Support

Explore Evaluate Deliver Verify

Portfolio Management

Portfolio Level• Updated steering

committee approach and governance model

• Balance demand against capacity

April: Align with Strategy

Initiate Produce UAT Make Ready

Backlog Plan Prepare Implement Follow up

Delivery Leadership

Dev OpsDelivery Teams

Capability Improvement

Value Management

Support

Explore Evaluate Deliver Verify

Portfolio Management

Program level• CRM / PO role

transitions to the PMO

Lessons Learned

• Get started on the automation earlier• Change management must be intentional

– managing resistance and organizational inertia

• Gained momentum when we involved the overall organization in the transformation – business management drove the value proposition

Cast Study #2 – Network Security Appliance Company

Company Profile

• Based in the United States• 125 employees located across 4 major

cities in the US and Canada• Growing through acquisition

Problem Statement

• Functional separation between Development and QA

• Ad-hoc waterfall based processes not able to scale

• Too many projects in queue • Teams are not predictable• Have not been able to realize their most

strategic goal to integrate all the products into a single suite

Engagement Approach

• Conducted a competency assessment on the entire organization

• Collaborated on a top-down plan led by the VP of Engineering with full support from the CTO and CEO

• Started with the products in Atlanta and systematically moved through other geographies

Engagement Approach – Phase I

• Team Level and Multi-Team Adoption• Focused on Product Definition, Planning &

Coordination, and Organizational Enablement Competencies first

• Mostly at the Daily, Iteration, and Release levels

Engagement Approach – Phase 2

• Skipped the Program Management layer and went straight to Portfolio & Strategy

• Focusing on Product Definition, Planning & Coordination, and Organizational Enablement Competencies

• Began addressing Delivery Practices and Continuous Improvement

• Mostly at the Daily, Iteration, and Release levels

• Trained Marketing, Sales, and Senior Leadership

Engagement Approach – Phase 3

• Filled in the Portfolio Level• Still focusing on Product Definition,

Planning & Coordination, and Organizational Enablement Competencies

• Began addressing Delivery Practices and Continuous Improvement

• Started addressing some of the strategic planning issues

Team

Multi-Team

Multi-Team

Multi-Team

Portfolio Management

Enterprise Agility

Program Management

Story Backlog Task Backlog In Process Task Done Story Backlog

Tier 1 - Scrum

Story Backlog Task Backlog In Process Task Done Story Backlog

Inception Elaboration Construction Transition

Tier 1 - Scrum

Tier 3 - Kanban

Story Backlog Task Backlog In Process Task Done Story Backlog

Analysis Design Build Test Deploy

Inception Elaboration Construction Transition

Tier 1 - Scrum

Tier 2 - Kanban

Tier 3 - Kanban

Lessons Learned

• Having buy-in and support up to the CEO makes things a lot easier

• The sequence of events is not always intuitive

• Sometimes it is better to rough in something and come back to it later than try to get it perfect the first time

• Speed can be limited by individual resistance and the rate of organizational learning

Case Study #3 – Financial Service Company

Case Study: Situation

Financial Software Services Provider19,000 employees-1,000 in target division

Provider of technology solutions to the financial world

Very successful but long release cycles and low release predictability impact future strategy

Case Study: Assessment

Product Definition• Challenges decomposing road-map into clearly defined features and stories• Acceptance criteria evolve after development

Delivery Practices• Quality was not a foundational practice• Code was developed in large chunks with long feedback cycles

Planning and coordination• Predictability is difficult due to support demand on teams• Challenges making and keeping commitments• Too much WIP – the entire release is active simultaneously

Organizational Enablement• Development teams formed around technology layers and QA and Development are not

aligned in the same sprints• Supporting team members (architects, analysts) can be spread across multiple features and

services

Case Study: Plan

Organizational Design Patterns• Align Delivery Teams with the Product Architecture• Align QA, BA, and Architect with the Delivery Teams • Establish clear PO for each feature in Value Management and

clarify feature elaboration• Limit WIP and make work flow through the organization

Road-map• Get cross technology development teams created and working

from a single backlog• Establish Competency Improvement Team• Get BA and QA aligned with Development teams (dedicated to a

team and in the same cadence)• Get clarity around the PO’s role and establish effective elaboration• Align the product road-map with the business strategy

Structure development to match the product architecture

Delivery Teams

• Align all teams with product architecture• Conduct training for all developers• Prepare the backlogs and get teams to flow

Competency Improvement Team

Backlog Plan Prepare Implement Follow up

Delivery Teams

Competency Improvement

Team

• Establish a broad coalition around the transformation.• Identified the next most important area and enlisted change

management support for the transformation

Move from development to delivery teams

• Dedicate QA and BA to specific teams• Train on the flow of work through the teams• Work from a single backlog

Value Management Team

Backlog Plan Prepare Implement Follow up

Delivery Teams

Competency Improvement

Team

Initiate Produce UAT Make Ready

Value Management

Program level• Value Management

Team with PO per Feature

• Align PMO approach with Feature level delivery

Future: Align with Strategy, Support

Backlog Plan Prepare Implement Follow up

Delivery Teams

Capability Improvement

Explore Evaluate Deliver Verify

Portfolio Management

Portfolio Level• Use Business

Architecture to align and prioritize requirements with the services platform

Initiate Produce UAT Make Ready

Value Management

Support

Multiple Team Level• Support team (or

dedicated performers) to improve predictability

Lessons Learned

• Aligning development into stable teams with a clear backlog and then introducing QA and BA into the existing teams was organizationally easier – but we have to form all the teams twice

• The guiding coalition and a focus on change management is critical to the transformation

• The production support demands from technical debt and the historic approach makes predictability very difficult to achieve

• Moving PMO attention to the Feature Level made transitioning the governance model easier

Case Study #4 – Energy Management Company

Company Profile

• European company with offices across the United States

• Thousands of employees worldwide, several hundred in the US

• Significant amount of product development work done offshore in India

Problem Statement

• Adopted Scrum several years ago, not getting the expected business benefit

• Releases are constantly delivered with significantly less features than planned and are often behind schedule

• Hardware and firmware delivery out of sync with the management console software

• Pretty significant trust issues between senior leaders and their direct reports.

Engagement Approach

• Conducted a competency assessment on the entire division

• Collaborated on a top-down plan led by the Director of Quality & Process with full support from the CTO

• Started with the teams in Atlanta and are currently moving through other geographies

Engagement Approach – Phase I

• Agile teams were in place, but did not stay together over time. First step we formed persistent teams

• Requirements decomposition was not happening, so we build a Product Owner team to develop the backlog

• Focused on Product Definition, Planning & Coordination, and Organizational Enablement Competencies first

• Exclusively at the Release level to start

Engagement Approach – Phase 2

• Continued to ignore the teams and went for Portfolio & Strategy

• Established an Agile Release Train• Still focusing on Product Definition,

Planning & Coordination, and Organizational Enablement Competencies

• Uncovered significant trust issues between senior level managers within engineering and product management

Engagement Approach – Phase 3

• Started addressing performance of the teams• Started addressing cultural issues around trust

and transparency at all levels of the organization • Next steps address Delivery Practices and

Continuous Improvement • Started to revise the roadmap by modeling the

entire flow of value from Sales through Product Development into Support and Operations

• Tighter integration of hardware and firmware

Team

Multi-Team

Multi-Team

Multi-Team

Program Management

Program Management

Portfolio & Team

Program Management

Multi-Team

Enterprise Agility?

Analysis Design Build Test Deploy

Inception Elaboration Construction Transition

Tier 2 - Kanban

Tier 3 - Kanban

Story Backlog Task Backlog In Process Task Done Story Backlog

Tier 1 - Scrum

Story Backlog Task Backlog In Process Task Done Story Backlog

Analysis Design Build Test Deploy

Inception Elaboration Construction Transition

Tier 1 - Scrum

Tier 2 - Kanban

Tier 3 - Kanban

Lessons Learned

• Engineering only change initiatives are likely to struggle

• Effectively integrating with non-Agile work streams can make or break a transformation effort

• Understanding the flow of value across the entire organization is critical

• Starting with teams isn’t always the most strategic approach

Key Takeaways

• Introducing Agile at Scale is best done incrementally and iteratively

• To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization

• Organizational agility is not about adopting a specific set of practices but developing strategies to address competencies at different frequencies and different scales

Key Takeaways

• Introducing Agile at Scale is best done incrementally and iteratively

• To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization

• Organizational agility is not about adopting a specific set of practices but developing strategies to address competencies at different frequencies and different scales

Key Takeaways

• Introducing Agile at Scale is best done incrementally and iteratively

• To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization

• Organizational agility is not about adopting a specific set of practices but developing strategies to address competencies at different frequencies and different scales

Key Takeaways

• Introducing Agile at Scale is best done incrementally and iteratively

• To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization

• Organizational agility is not about adopting a specific set of practices but developing strategies to address competencies at different frequencies and different scales

Mike CottmeyerLeadingAgile

[email protected]

www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer

Dennis StevensSynaptus

[email protected]

www.synaptus.comtwitter.com/dennisstevens