Professional Documents
Culture Documents
Edited Transformation-Whitepaper-final PDF
Edited Transformation-Whitepaper-final PDF
Edited Transformation-Whitepaper-final PDF
TRANSFORMATION
MIKE COTTMEYER
INTRODUCTION
FOR YEARS, WE’VE TREATED AGILE LIKE IT’S
SIMPLY A PROCESS. Just a new way of doing what
we’ve always done. Why is it then, that when we train
people on how to use the process, they so frequently
struggle to see any benefit? Scrum can be described
in less than 20 pages. SAFe can be taught in less than
a week. Why is applying these concepts so difficult
for so many organizations seeking to get the benefits
of going Agile? Why is it so hard…what could we be
missing?
INTRODUCTION | 2
against us making the kinds of changes necessary
to benefit from a more Agile way of working.
INTRODUCTION | 3
of an Agile ecosystem, the patterns of
scale, and how you get from one place
to another when faced with competing
WHO
business needs. Reference Architecture The fourth and final section will explore
will look at the core patterns of what roles are necessary to orchestrate
enterprise Agility and offer a minimum the change as well as the skills and
subset of organizational patterns, experiences necessary to effectively lead
governance models, and metrics an Agile Transformation. This section is
necessary to establish an effective Agile also broken into two sub-sections: Roles &
ecosystem. Responsibilities and Skills & Experience.
Roles & Responsibilities will explore the
outcomes and activities necessary to lead
and implement an Agile Transformation;
while the Skills & Experience section
goes into detail about the attributes of
individuals in junior roles, senior roles,
HOW
and executive roles on a Transformation
initiative.
INTRODUCTION | 4
WHY
BUSINESS CASE
T R A N S F O R M AT I O N
HYPOTHESIS
WH AT
HOW
WHO
WHY WHAT HOW WHO
WHY
PR E D I C TA B I L I T Y
Before we get started with our Agile Transformation, it
is important that we understand why we are making Agile tends to focus on adaptability as a
these investments and what we hope to gain from our key driver, but one of the most frequent
efforts. Furthermore, we have to understand what stated goals of an Agile Transformation is
changes we intend to make, and have a well-formed predictability. Predictability means that we
point of view about how these changes are going to can reliably make and meet commitments
lead the business outcomes we seek to achieve. to our customers. Predictability builds
trust with our internal stakeholders, our
customers, and our markets.
THE BUSINESS
CASE FOR AGILE
A business case will allow us to clearly state what QUALIT Y
our objectives are for the Transformation and give us As organizations scale, it’s common for quality
a way to measure if we are successful. to suffer, and the way in which it suffers
can come in many forms. Sometimes we’re
missing features and functionality. Sometimes
It’s Never About Agile
it’s extrinsic quality problems in the form
Adopting Agile is never about adopting an Agile of defects. Other times, it’s intrinsic quality
methodology. It’s always about delivering better in the form of technical debt. Quality issues
business outcomes. Agile process is—at best—a means erode trust with our customers and make our
to an end. At worst, it can be a distraction that results software difficult to manage.
in focusing on the wrong changes for the enterprise.
Understanding your business goals will align your
organization around common outcomes, help you
explain your Transformation strategy, and identify
necessary tradeoffs. It’ll also help identify whether
C O S T S AV I N G S
or not the Transformation is headed in the right
direction. Most companies adopt Agile because they
believe that it’s more efficient and that it
Some of the common goals of going Agile are: will reduce costs. But, they are usually so
overloaded with work that the cost savings are
often difficult to achieve. What is achievable is
greater assurance that your people are focused
on the problems whose solutions have the
highest value.
BUSINESS CASE | 6
WHY WHAT HOW WHO
T R A N S F O R M AT I O N
HYPOTHESIS
PRODUCT FIT
One of the common goals of adopting Agile A Transformation Hypothesis forms our basis of
is making sure that we’re building the right understanding for how we intend to approach
product for our customers. Agile gives us the the Transformation, why we intend to take this
opportunity to deliver in smaller batches, approach, and why we think this approach will yield
get frequent customer feedback, and change the outcomes we expect.
direction when we learn new things about our
customers and their requirements.
What Are We Changing?
There’s a troubling narrative in the Agile community
that adopting Agile, or orchestrating an Agile
Transformation, begins with a cultural change. This
I N N O VA T I O N
is a tempting narrative because people often resist
We know that well-formed teams, operating change. When they do, it’s tempting to think that
in the right market and in the right we have a culture that is resistant to change. While
organizational context, can take advantage of that could be the case, oftentimes, there are real
Agile methodologies to exploit uncertainty. constraints that make change difficult. If we want
They’ll be able to test product hypotheses, people to be open to change, we have to remove the
assess customer demand, and are free to impediments that make the goal difficult to achieve.
explore what works.
T R A N S F O R M AT I O N H Y P OT H E S I S | 7
WHY WHAT HOW WHO
If we assert that culture must change first, we’re Often, Agile is implemented as a process change. This
making the assumption that changing culture will happens when you have people go through training
lead to the necessary process and system changes and then optionally give them support from coaches to
necessary to sustain Agile in the enterprise. More help sustain the new things they’ve learned. A process-
often than not, people go down the path of cultural first Transformation is predicated on the assumption
change, get excited about the possibility of Agile, and that adopting team-level practices will yield—through
come back to deep-rooted process and organizational iteration and retrospective—an understanding of
issues that make Agile nearly impossible to the impediments that are preventing true Agility.
implement in an effective manner. This often leads Furthermore, it assumes the team will be able to
to cynicism, disillusionment, and people wondering identify and resolve the root cause of those obstacles.
why their peers “just don’t get it.”
T R A N S F O R M AT I O N H Y P OT H E S I S | 8
WHY WHAT HOW WHO
SYSTEMS CHANGE
T R A N S F O R M AT I O N H Y P OT H E S I S | 9
WHY WHAT HOW WHO
product developers. If you’re leading a group of six It’s important that we understand resistance to change
to eight people, sending people to culture school or in a very human way. Quite often we have leaders that
Scrum school, along with a little coaching, might have been highly successful doing what they’ve been
be sufficient. If you’re Transforming 300 people doing for a long time. They make a lot of money. They
working across an integrated product suite…you’ll have mortgages and kids in college. Change… especially
need to approach your Transformation with a greater change that is big and scary and could possibly fail
degree of intentionality. If you’re Transforming threatens not only their jobs, but, potentially, their
12,000 people in a Fortune 100 company, the level livelihoods and the lives of their families.
of structure, planning, and coordination you’ll Being sensitive to the human beings involved in the
need can be overwhelming. Knowing these types change and making sure everyone is informed and
of Transformations are different is a key insight safe is a key component of leading change. If we
necessary for crafting your plan. don’t create this kind of safety, we are likely to create
detractors when we really need to have supporters.
Multiple Teams
Single Team
DEPENDENCIES
T R A N S F O R M AT I O N H Y P OT H E S I S | 10
WHY WHAT HOW WHO
Non-instantly
Available
Resources
Matrixed Too Much Work
Organizations in Process
Shared
Low Cohesion &
Requirements
Tight Coupling
Between Teams
Technical Debt &
Defects
T R A N S F O R M AT I O N H Y P OT H E S I S | 1 1
WHY
WH AT
THEORY & APPROACH
REFERENCE ARCHITECTURE
HOW
WHO
WHY WHAT HOW WHO
As we get started with our Agile Transformation, it is to Agile all have in common, is that they are predicated
important that we understand what’s important from on our ability to form teams, build backlogs, and
a theoretical point of view and that we are all produce a working tested increment of product at the
clear on the patterns we intend to apply getting there. end of some predetermined time period. The processes
As a change agent, you will find you may need to do of each methodology were designed to enable these
some things early, while you are managing and Three Things.
PR E D I C TA B I L I T Y V S A DA P TA B I L I T Y
The Four Quadrants
To begin, we must recognize that organizations have
The Three Things gives us a thinking tool for
competing needs. Executives need their teams to
understanding the fundamentals of what we’re
make and meet commitments. These executives made
changing within the enterprise. It’s all about forming
promises, and their organizations need to deliver.
teams, building backlogs, and producing working,
That said, these same executives live in a world of
tested product. Anything that gets in the way of this
uncertainty. They’re responding to change all the
is an impediment that must be managed or removed,
time and need their teams to respond to that change
and all of that goes into our Transformation strategy.
with them. The thing to recognize is that the need to
Sometimes, though, building trust and confidence in
be predictable competes with the need to respond to
the organization has to happen first. Sometimes we
change. If we optimize for predictability, we make it
have to meet the organization where it is and show
harder to change. If we optimize for change, we make
it how Agile is more effective before we can establish
it harder to make and meet commitments. At this
an agency to create more—and better—change.
point, there’s no value judgement one way or the other,
but recognizing where you are and what you value is
The Four Quadrants, and the LeadingAgile Compass
critical to your Transformation journey.
metaphor, grew from a need to explain, not only
why different methodologies arose to meet different PREDICT ABILI TY
ADAPT ABILI TY
organizational needs, but also how to orient the
organization from where it is today to where it
needs to get in the future. It helps us understand
the constraints that drive decision making around
process and how we can change these constraints
over time to give us more flexibility in achieving
our goals. The Four Quadrants give us a way to talk
about where you are today, where you need to be in EMERGENT VS CONVERGENT
the future, and how we’ll get there over time.
Markets have similar dynamics to companies. Some
markets are undefined and tapping into those markets
has a high degree of uncertainty. Sometimes the
AD-HOC EMERGENCE LEAN
STARTUP market doesn’t exist, and sometimes it’s so new that
the requirements aren’t defined—or even definable.
We call these markets emergent. Companies playing in
PREDICT ABILI TY
ADAPT ABILI TY
EMERGENCE PREDICTIVE-CONVERGENT
ADAPT ABILI TY
impossible to put together a plan with any degree of
PE AE
confidence. This behavior often drives us to attempt
Agile in an organization exhibiting adaptive-emergent PC AC
behavior but values predictive-convergent outcomes.
LEAN/
AGILE
CONVERGENCE
EMERGENCE
ADAPTIVE-EMERGENT
PREDICT ABILI TY
ADAPT ABILI TY
These are the kinds of teams that can go super-fast, time and cost constraints, but it’s emergent in that we
but you don’t necessarily know where they’re going deliver in such a way that we create optionality. We
to land. What you’re looking for here is disruption and break projects and requirements into smaller chunks
new markets. and deliver those chunks to market more frequently.
We create optionality in terms of how we organize our
PREDICTIVE-EMERGENT work. We create options for how we deliver. We create
options, so we can change direction when we learn
The most interesting quadrant (and the one we weren’t new things.
originally sure existed when the model was first
constructed) is the predictive-emergent quadrant. EMERGENCE
This is the quadrant of chaos and heroics. Companies
in this quadrant deliver, but they don’t often deliver
what they planned. They go on death marches and
PREDICT ABILI TY
ADAPT ABILI TY
depend on a handful of key people to make it happen
PE AE
when it really counts. Ironically, this is where most
of the market is right now, built for predictability, but PC AC
struggling with unrealistic expectations and constant
change. Many organizations in this quadrant see Agile
as the way out, but don’t realize the constraints that
AGILE
will get in their way.
CONVERGENCE
AD-HOC EMERGENCE
Applying the Four Quadrants
The Four Quadrants are an effective tool for getting
PREDICT ABILI TY
ADAPT ABILI TY
This quadrant is Agile’s home base. Adaptive- Understanding this will help you define a process you
convergent is about making and meeting can do today, a process you’d like to adopt in the future,
commitments, but in smaller batches. It’s the quadrant and a plan for creating the conditions necessary to
of weekly, monthly, or quarterly delivery. It’s make those changes a reality.
convergent in that we value delivering scope within
ADAPT ABILI TY
ADAPT ABILI TY
You can likely use Scrum or Kanban at the delivery
PE AE level, but teams are often heavily orchestrated by a
program or integration team. They’re operating under
PC AC
a heavier governance model. Ideally these governance
Gartner bodies are using a Lean/Kanban-based program and
Mode 1
portfolio system—that’s the goal—but road mapping,
LEAN/ AGILE
rolling wave planning, and progressive elaboration
AGILE
CONVERGENCE should be the rule. Teams lose some decision making
at this Basecamp for the sake of receiving highly
coordinated backlogs that are aware of system
constraints before the teams take stories into planning.
Basecamps
Extending the Compass metaphor further,
BASECAMP TWO - REDUCE
LeadingAgile introduced the concept of a Basecamp. B ATC H S I Z E
A Basecamp is simply an intermediate state along
your Transformation journey. Direction is set and Even in the presence of extreme dependencies, there
you’re guided by the Compass, while the Basecamp is often much work that can be done to lean out the
is an intermediate step along the way that allows release management process and begin improving
you to measure progress, claim an intermediate technical practices. Once we have the system of
victory, and possibly rest and refuel for the next delivery built, delivering, and stabilized, the next step
leg of your Transformation. Remember, the work of is to do the work necessary to get the product into
a Transformation is changing your organizational market faster. The hypothesis is that once
context, so the change will stick. This can be we’ve improved the organization’s ability to make
a long process. The organization needs to move in and meet commitments, we’ll earn trust with the
smaller, more quantifiable steps. product organization and begin to break the portfolio
investment increments into smaller batches, so they
Basecamps allow you to break your Transformation flow through the system faster, release to market
into smaller funding increments with measurable more frequently, and give us the opportunity for
and defined intermediate goals. earlier feedback from our marketplace. Success at
Basecamp One provides the agency to move toward
Basecamp Two.
Many organizations will find a nice, stable home base Once you have complete cross-functional teams that
at Basecamp Two. This is the world of Gartner Mode are free of dependencies and are locally funded, you
One, systems of record, things that can’t be wrong or can begin to change what you expect from these teams.
are too expensive to refactor. Basecamp Three A team that is tightly connected with the operations
demands that we start breaking things into pieces, that of the larger organization is beholden to requirements
we begin to decouple dependencies between value and schedules, because the rest of the organization
streams and teams. depends on them for critical infrastructure. A team
Decoupling can happen through our product and decoupled from the organization across all dimensions
investment decisions and how we staff teams. Often can begin to shift how it receives and delivers
decoupling happens by refactoring our technology into requirements. Rather than a specific list of features
services and components that and functions, they can begin to operate off a list of
can be supported by complete cross-functional teams. business goals and objectives, objectives that they are
Business architecture drives these decisions and free to explore and test without concern for how the
informs our strategy. This is often where it makes broader organization may—or may not—consume their
the most sense to introduce DevOps, Continuous services.
Integration, and Continuous Deployment.
A Note on Basecamps
BASECAMP FOUR - LOCALIZE
INVESTMENT DECISIONS Basecamps are dynamic and should be tailored to your
unique journey, the complexity of your environment,
Once you have completely decoupled your value and the nature of the changes you’re looking to
streams and teams, you have the option to make implement. We find organizations trekking from
changes around how you fund projects and teams. Basecamp Zero to Basecamp Two. From Basecamp
One of the biggest impediments to Agility is using Three to Basecamp Five. Or even from Basecamp
the project as a funding construct when you have Five to Basecamp Two as their organizations mature
a product-based organization. Especially in large, and evolve and as the expectations of their clients
complex systems of systems, the funding token change. These five Basecamps are offered as a starting
spans multiple teams, multiple organizations, place and the sequence is offered as an example of
and multiple spans of control. Once you’ve done how one might proceed. Feel free to leverage and
the work to decouple the organizations from apply this metaphor in what ever way works for your
each other from a staffing perspective, a business organization.
perspective, and a technology perspective, you can
entertain implementing a platform/product funding BASECAMPS ARE DYNAMIC AND SHOULD
strategy where shared components have their own BE TAILORED TO YOUR UNIQUE JOURNEY,
investment dollars to support the ongoing work of THE COMPLEXITY OF YOUR ENVIRONMENT,
the product organization. This is where you can really AND THE NATURE OF THE CHANGES YOU’RE
begin to move fast and with Agility. LOOKING TO IMPLEMENT
It’s worth noting at this point, that there is also manner, quantifiably demonstrate progress against
nothing explicit or implied within the Basecamp defined business goals.
standard definitions or examples when technical
practices or product management practices must be This is the goal of the Transformation effort.
introduced. Typically, we focus on technical practices
in Basecamps Two and Three and product practice
in Basecamps Two and Four. But, depending on
the particulars of the organization, its constraints,
REFERENCE
starting Basecamp, and destination Basecamp, it
may be advisable to start introducing these concepts ARCHITECTURE
earlier in the Trek. This is especially true if you
A reference architecture includes the base patterns
know you’re going to pass through Basecamp Three
and tools that we may want to apply within our
and need time to educate the development team on
organization as we adopt Agile. This is where we start
legacy refactoring techniques that will take time to
to explore what the organization might look like when
learn and absorb.
we are done. It also helps us understand what the
intermediate states might look like as we move toward
Remember, this is only a pattern, and metaphor…a
each of the Basecamps. The LeadingAgile reference
thinking tool for change.
architecture includes guidance around how to create a
structural model for your organization, a governance
model, and a model for the kinds of metrics and tools
Expeditions you may want to use to demonstrate value to your
Expeditions are groupings of teams that will make enterprise.
the Transformation journey together. They consist of
all the pieces of the organization necessary to fully A REFERENCE ARCHITECTURE INCLUDES THE
implement all the pieces of the model. An Expedition BASE PATTERNS AND TOOLS THAT WE MAY
should also have all the structural elements necessary WANT TO APPLY WITHIN OUR ORGANIZATION
to deliver the product, coordinate and overcome AS WE ADOPT AGILE
dependencies, and make prioritization decisions and
economic tradeoffs. The structure has to operate in a
defined governance model to coordinate and manage
Structure
the flow of value at each tier of the enterprise and
across the entire value stream. Lastly, an Expedition Your organizational structure forms the backbone
will have a metrics and tooling approach that allows for how your Agile enterprise will operate. Your
the enterprise to measure, control, and truly evaluate structure is informed by your business architecture,
if the Transformation is yielding the business results it your technology architecture, and your organizational
promised. chart. We’re looking for opportunities to encapsulate,
to decouple, and to minimize orchestration costs.
Expeditions moving through Basecamps are the Often, this mean organizing around business
primary unit of progress of an Agile Transformation. capabilities, value streams, and other major groupings
Groups of teams, operating in a reliable and predictable within your enterprise. You may find that early on
REFERENCE ARCHITECTURE | 22
WHY WHAT HOW WHO
in your Transformation, you can’t get everything other products across the enterprise. The customers of
exactly the way you want it, and you have to incur the services team are these other products and it is the
more orchestration costs than you’d like sometime job of the Services Team Manager or Product Owner to
in the future. But, this is the work of the Agile rationalize the demand across all the product areas and
Transformation. create services that best serve their market, as they
understand it.
PORTF OLIO
TEAM S
PROGRAM TEAMS
REFERENCE ARCHITECTURE | 23
WHY WHAT HOW WHO
REFERENCE ARCHITECTURE | 24
WHY WHAT HOW WHO
Epic | Kanban
PROGRAM
TEAM INTAKE
DEFINITIOFEATU
STORY MAPPING
RELEASE
IN PROGRESS
INTEGRATION FEATURE FEATURE
DELIVERY
TEAM MAKE STORY STORY
STORY READY IN PROGRESS
READY DONE ACCEPTED
Story | Scrum
F O U R-T I E R G O V E R N A N C E
REFERENCE ARCHITECTURE | 25
WHY WHAT HOW WHO
INVESTMENT
Initiative | Kanban
INVESTMENT
DECISION
INVESTMENT
TARGETING
IN PROGRESS
INITIATIVE
VALIDATION
COMPLETED
ratio of those to value received.
INITIATIVE DEFINITION INITIATIVE ROADMAP MEASUREABLE PROGRESS
PORTFOLIO
• ROI/Capitalization
EPIC EPIC SOLUTION RELEASE EPIC
TEAM ALIGNMENT PRIORITIZATION VALIDATION TARGETING
IN PROGRESS
VALIDATION
COMPLETED
PROGRAM
TEAM INTAKE
FEATURE
STORY MAPPING
RELEASE
IN PROGRESS
INTEGRATION FEATURE FEATURE
DEFINITION PLANNING VALIDATION DEPLOYMENT COMPLETED
DELIVERY
• Cycle Time
Duration from planning to completion.
N-T I E R G O V E R N A N C E
REFERENCE ARCHITECTURE | 26
WHY WHAT HOW WHO
• Escaped Defects
Escaped defects are bugs or problems with
production software that made it through QA – e.g.
it was found by end-users or customers. Sometimes
these are found in acceptance tests and sometimes
even later than that. The escaped defect rate is
measured as a ratio of pre-production defects to
post-production defects. A high escaped defect
rate is an indication that you’re moving software to
production too fast.
• Commit %
A comparison of the number of stories—or story
points—agreed to at the beginning of a sprint to the
number that was actually completed. This can be
higher than 100% if development teams are
under-committing, which can cause problems with
prioritization.
• Acceptance % Ratio
This is calculated by comparing the number of stories
released to the number of stories accepted. A higher
number is better in this case.
• Scope Change
This refers to the number of stories where scope
is changed to add or remove functionality from
features in order to ensure delivery. High scope
change indicates issues with backlog definition or
acceptance criteria.
REFERENCE ARCHITECTURE | 27
WHY
WH AT
HOW
CHANGE MODEL
R E S U LT S M A N AG E M E N T
WHO
WHY WHAT HOW WHO
Once we’ve established a clear sense of business team will approach the Transformation, what kinds
goals, we have defined a working hypothesis around of things need to change, and how the change can
the nature of the change we want to make in our happen safely and incrementally. The third set of goals
organization, and we understand the fundamental revolves around looking at the where the organization
thinking tools and the underlying reference exists today and determining a possible operating
architecture for Agile at scale. Now, it’s time to begin model within the LeadingAgile reference architecture.
doing the work. But, how do we actually make the It is important that the leaders see their organization
changes, get the organizational momentum to move, within the reference architecture. Finally, we need
overcome resistance, and make change stick? a detailed 90-day plan for what the first 90 days of
discovery will look like and a point of view for where
we might pilot to get the most value as fast as possible.
MECHANICS
Transformation Hypothesis
The meeting is run over the course of two or three
PURPOSE
days and everyone needs to be in the room the entire
The reason we build a Transformation hypothesis is time. We begin systematically walking through much
to get key organizational leaders aligned and rallied of the material covered in the Why and What sections
around a vision for what’s possible. of this paper. The session in generally broken into
eight sections, with a defined output at the end of each
The first set of goals involves getting agreement module:
around the key business drivers and a shared
understanding of the types of impediments that 1. Business Drivers
CHANGE MODEL | 29
WHY WHAT HOW WHO
CHANGE MODEL | 30
WHY WHAT HOW WHO
CHANGE MODEL | 31
WHY WHAT HOW WHO
to remove impediments. Learnings from the Pilot are Intangible outcomes of the Pilot are similar to those
captured and built into the structure and content of of the Define the End State step. Again, the intangible
the emerging Transformation Playbook. outcomes are increased trust, greater alignment, broad-
based understanding of the necessary changes that
need to be implemented, alignment around approach
MECHANICS
and timelines, as well as a revised understanding of
The mechanics of the Transformation involve issues such as: risk, dependencies, constraints, and
the mundane execution of the plan. Forming and the business case. At the end of the Pilot we’ll need
possibly co-locating teams. Getting the teams into to receive recommitted financial approval to move
training sessions and workshops. Getting tooling forward.
setup and configured, in addition to helping the
teams get started using the tools. Backlogs are built The Pilot will serve as a reference implementation that
and estimated, rolling wave planning is established, everyone can point to as a working example of what
progress is assessed, and the pilot teams are hardened this should look like at scale.
and stabilized over a period of several months as they
move to Basecamp One.
ADDITIONAL NOTES ON THE
PILOT PHASE
PA R T I C I PA N T S
The Pilot phase, articulated here, assumes you’re
Everyone in the target organization will play a part piloting a first Expedition to Basecamp One. That does
in the pilot. Everyone should be placed on a team, be not have to be the case. You could Pilot to a different
a part of training, be included in the workshops, and Basecamp and Trek in any direction through the
have a clear understanding of where they fit in the Quadrants. If this is the case, the sequence of events
new organization. may change, the tangible deliverables and outcomes
may change, but the intangible outcomes will remain
largely the same.
OUTCOMES
CHANGE MODEL | 32
WHY WHAT HOW WHO
CHANGE MODEL | 33
WHY WHAT HOW WHO
R E S U LT S M A N AG E M E N T | 3 4
WHY WHAT HOW WHO
PLAN AND COORDINATE - This set of competencies OUTCOMES - Outcomes give us assurance that we’re
represents the ability to estimate and plan work, tracking to the Basecamp goals. Activities roll up
measure velocity and throughput, assess the system into outcomes, but the outcome is the smallest unit
for bottlenecks, coordinate across teams, and evaluate of measurable progress on an Agile Transformation.
any other skills necessary to communicate, schedule, Outcomes should reflect significant progress for a
and deliver against expectations. team, or set of teams, in the Basecamp. They should be
measurable in the eyes of the business.
DELIVER THE SOLUTION - This set of competencies
represents the ability to deliver a working tested BASECAMPS - Basecamps are the highest level
increment of product to market. It could include testing of value short of business outcomes for the
practices, deployment, release management, CI/CD, Transformation. Once an Expedition moves to a
and DevOps. It can be technical and non-technical. Basecamp, its performance attributes should be
extremely clear, measurable, and economically
ORGANIZATION ENABLEMENT - This set of justifiable against the spend necessary to get it there.
competencies includes the ability to form teams and
provide the right kind of infrastructure to support and If the Transformation is on schedule, and the
sustain those teams. This capability can be evidenced capabilities that must be improved are showing
in terms of people in roles, policies, leadership, and sufficient progress and signs of sustainability, we’ll
mindset. have the right leading indicators in place to have high
confidence that we’ll realize our lagging indicators on
the business side.
R E S U LT S M A N AG E M E N T | 3 5
WHY WHAT HOW WHO
Expeditions moving to a Basecamp are the primary ultimately reduce costs. Cost savings are often difficult
unit of measure in an Agile Transformation—short of to achieve because organizations are so overloaded
measured business results. with work. Often, we see organizations achieving
greater assurance that their people are focused on the
problems whose solutions have the highest value.
R E S U LT S M A N AG E M E N T | 3 6
WHY WHAT HOW WHO
R E S U LT S M A N AG E M E N T | 3 7
WHY
WH AT
HOW
WHO
ROLES & RESPONSIBILITIES
company will need people to take on various roles and execution of the Transformation strategy and the
responsibilities within the organization. To perform communication of the required steps to reach the
these roles, the people will need to have certain skills desired end state.
ROLES & •
•
Political awareness
Highly Driven with Strong Follow-Through
RESPONSIBILITIES and a Focus on Owning the Outcome
They will drive the creation and execution of a Executive Level Experience:
Transformation strategy that aligns to the strategic • Previous experience, including profit and loss
goals of the organization and the enterprise responsibility, in a senior leadership role
Transformation strategy. In order to be successful, the • Ability to articulate where a team lies on
Transformation Lead will need to be able to articulate their organization’s Transformation roadmap
the overall vision and strategy to their executive and a Focus on Owning the Outcome
i.e. Lean, Scrum, Kanban, SAFe, etc... Transformation teams to maintain alignment
with the outcomes and plans
• Capable of demonstrating organization-
wide Agile adoption strategies and rollout • Develop Expedition Leads over time to
Change Management:
Cultural Fit:
Strategic Planning:
• High Emotional Intelligence
• Ability to maintain a view of both technical
• High Integrity needs of the team, from a software
• Team Building Skills development standpoint, as well as the
• Adaptability higher- level, strategic vision
• Ability to focus on the most important • Ability to articulate where a team lies on
• Coach teams and management towards other Agile practices, i.e. Scrum, Kanban,
improving Agile processes and metrics SAFe, etc…
DESIRED TRAITS
RESPONSIBILITIES
Leadership Presence:
• Form and coach the program team to ensure
• High Integrity
cohesive flow and dependency management
• High Emotional Intelligence
• Understand and communicate architectural
• Strong Communication Skills
needs and requirements across teams
• Cross-Functional Across Teams
• Maintain the integrity of the end state vision
• Ability to Maintain an Autonomous across a diverse group of teams
Viewpoint
• Provide guidance, validation, and context to
• Adaptable to Quickly Changing Demands teams and assist with alignment to the end
• Strong Prioritization Skills state goals
The Agile Process Coach educates the Expedition • Highly efficient in forming a well-refined
coaching for implementing the process in their own • Ability to guide the formation of cohesive
work. They conduct workshops and training sessions teams
that teach Agile practices and ceremonies that lead • Coach teams and management towards
toward the organization-wide adoption of Agile improving Agile processes and metrics
methodologies.
• Ability to articulate where a team lies on
their Transformation roadmap
DESIRED TRAITS
• Relevant programming experience a plus
Leadership Presence:
A Technical Coach will be a seasoned software and technologies. Able to identify useful, new
developer with a breadth of experience in multiple approaches and technologies as they emerge
• Teach and mentor Expedition team members • Highly driven with strong follow-through
on Lean/Agile approaches for flowing work and a focus on owning the outcome
• Teach and mentor Expedition team members • Ability to focus on the most important
on XP engineering practices, including objective at the current moment
TDD, CI and pairing. Facilitate code reviews, • Driven by Continuous Learning
provide leadership perspective on design and • Adaptable
code quality
CORE COMPETENCIES
SKILLS &
Experience: EXPERIENCE
• Exposure to Agile methodologies
Now that we have the roles and responsibilities
• Project management exposure, as well as
understood, it’s time to consider the skills and
an understanding of software delivery and
experience necessary to lead the change. As we
technology operations processes and
mentioned, simply having knowledge of Agile
terminology
is insufficient to lead the changes required for
• Experience with Agile Project Management sustainable Transformation. Different levels of team
tools is a plus, e.g. Rally, Jira, VersionOne, members will require different types of skills and
LeanKit, etc… have a different strengths profile.
• Strong communication skills, both verbal and
written
EXPERIENCE
Positive behavior profiles are another attribute you’d Senior team members need to have an expert-level
like to build your team around. People that are high understanding of Agile and Agile methodologies.
energy, goal oriented, outcome focused, don’t get their They need a broad set of tools and techniques at their
feelings hurt easily, and are resilient make the best disposal.
change agents. You need a team of people that are able Senior-level people need to be able to apply these ideas
to maintain a strong point of view, but are flexible, in situationally specific ways, tailoring them to the
open, and coachable. Junior team members need to needs of their organizations. They must be
have a higher respect for authority, higher attention to knowledgeable at all levels of scale and know how to
detail, and follow-through.
FINAL NOTE | 51
WHO IS
LEADINGAGILE?
LeadingAgile is a company dedicated to
helping larger, more complex organizations
achieve better business outcomes through
the systematic application of Agile delivery
methods across the entire enterprise.
WHO IS MIKE
COTTMEYER?
LeadingAgile founder and CEO, Mike Cottmeyer is
passionate about solving the challenges associated
with Agile in larger, more complex enterprises. He
and his team are dedicated to providing large-scale
Agile Transformation services to help pragmatically,
incrementally, and safely introduce Agile methods.
He spends most of his time leading and growing
LeadingAgile, doing sales and business development,
developing content, and providing strategic coaching
for key clients.
WHO ARE WE | 52