Exploring Agile Transformation and Scaling Patterns
-
Upload
mike-cottmeyer -
Category
Business
-
view
3.781 -
download
2
Transcript of Exploring Agile Transformation and Scaling Patterns
Exploring Enterprise Agile Transformation StrategiesMike Cottmeyer, Agile CoachLeadingAgile, LLCDennis Stevens, Agile CoachSynaptus
Mike CottmeyerLeadingAgile
www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer
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)
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
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
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
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
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
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: 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
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
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: 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
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
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
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
www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer
Dennis StevensSynaptus
www.synaptus.comtwitter.com/dennisstevens