Applied tactics for your transformation

© Copyright 2017 Dell Inc.1
Applied Tactics, Technology,
and Economics
for your Transformation

Applied Tactics, Technology,
and Economics
for your Transformation
Stuart Charlton / @svrc

Our mission is to transform
how the world builds software

Fear of
Disruption
The drivers of
transformation are fear and
hope
Hope of
Growth

Pivotal — Confidential
Silicon Valley is not a place.
It’s a state of mind.

Economics, Tactics, Technology
1.Tactic: Map your Situation and Roles
2.Economics: The Cost of Delay
3.Small, Radical Tactic: Unified Change Management
4.Big Tactic: The Balanced Product Team
5.Tactic: Products, not Projects
6.Big Tactic: The Independent Digital Lab
7.Technology: Cloud Native Microservices

Tactic: Map your Situation and Roles

Different processes/cultures for the stages of evolution in an organization
The Strategic Planning Game Board
Wardley Maps
(Value Chain
Maps)
assist in improving
economic
situational
awareness:
mapping your value
chain against the
evolution of a
component or a
competitor
Source:
Simon Wardley

The emerging cloud native (“settlers”)
organization shape
Innovation: Plan, design, develop
and test business capabilities as
deployable artifacts
Services: develop, test, QA, and
evolve operational services
Platform: upgrade platform,
capacity planning, service mgmt.,
scale platform
Infrastructure: Cloud compute,
networking, data storage, security,
etc.
ROLES
Product Teams
(Prod. Owner & Mgr, UX,
Dev, QA)
Service Operators
Platform Operators
Engineering
(Storage, Security, Network, etc.)
& Shared Support
(Finance, GRC, InfoSec)
AREAS OF FOCUS
Source: Pivotal Cloud Foundry Solution team, "Crafting the Cloud Native Organization," Coté, March 2016. discussions with GSA-cum-
Pivotal’s Diego Lapiduz. More: "Who Does What? Mapping Cloud Foundry Activities and Entitlements to IT Roles," Cornelia Davis, Aug 2016.

Economics: The Cost of Delay

11© Copyright 2016 EMC Corporation. All rights reserved.
•Digital transformation is fundamentally focused on
minimizing or mitigating the cost of delay for
employees, customers, partners
•Queues (waiting, hand-offs) are the #1 enemy of
sustainably low cycle times, value and quality
• We are usually blind to queues
• We underestimate the cost of delay
How to think about costs and benefits?
Don’t look at them in isolation!

4 4 8 6
Requirements Architecture
Team
Server
Team
Network
Team
Random Network
Troubleshooting
Middleware
Team
Develop! User
Acceptance
Testing
QA/Production
Release
Break/Fix Cycle
Scale
Up/Down
Cycle time:
6 months
14
11 40 14 60 2
DAYS
Phase-Gates: “Do it right the first time!”
Maximizes Utilization, Queues & Inventory Invisible
90%
Utilized
95%
Utilized
97%
Utilized
98%
Utilized

0.1 0.1 0.1 0
Automated
Servers
Software-Defined
Network
Auto-Installed
Tools
Database as
a Service
Automated LB,
Firewall, DNS
Middleware
On Demand
Design
Develop
Test Driven
Minimal
Viable
Product
UAT
Co-executed
with
Development
QA
Co-executed
with
Development
Auto
Scale
Cycle time:
< 6 weeks
0.1
0.1 30 0 0 0
DAYS
Flow-Based: “Learn & do what is essential”
Minimize Waits, Queues, Inventory (Work-in-Process)
No
Human
No
Human
No
Human
No
Human

Quantifying the Cost of Delay
• Reducing Costs
– Automation removes waiting/handoffs
– Save $50k/week in waiting, delaying that costs… $50k/week
• Avoiding Costs
– Quality built-in reduces rework levels (probability of cost)
• Delivering Value Faster
– Earlier cash flows
– If you could make the company $100k/week,
delaying that costs… $100k
• Capitalizing on New Opportunities
– Greater cash flow sooner

•This is what we assume most
IT projects are
– True for internal projects,
but not business-driven
projects
– And still has a cost of
delay!
Long life-cycle, peak unaffected by delay
Typical IT Projects
Source: Black Swan Farming

Typical unbudgeted
windowed
opportunities
“Panhandling for
capital” across units
causes delays
Short life-cycle; Peak affected by delay
Tactical opportunities with a small window

Consider the cloud race:
•AWS (2006)
•Azure IaaS (2009)
•Google Compute (2012)
Limited peak due to delay?
Need to change the game
Long life-cycle; Peak affected by delay
Strategic opportunities with first mover advantage

Small, Radical Tactic:
Unified Demand & Change Management

•Goal: Build an Engine of Value Delivery
•Unify demand queues for each
project, product, service (Kanban)
• Features / Requirements / Defects / Requests
– All in one visible queue per business capability
• Limit work in progress
– No requirements tomes, only what can get done this week
– People are only working on the next highest priority thing
– What’s the priority? (hint: The Cost of delay)
Unifying Demand & Change Management
Products, not Projects

• Cancel all your projects
(or carve out a bunch to a digital lab)
• Divide your project and service teams
into capability teams
• Have each team visualize their backlog of work into a
Kanban-like board
•Visualize the work across teams
A Radical Idea for the Transformational CIO

•Limit work in progress (eliminate waste)
– No more large requirements docs, building then waiting,
Lining up for QA resources, lining up for deployment, etc.
•Let your teams collaborate to figure this out
•Track flow and progress weekly,
continually removing impediments
•Deadlines are not a motivator, they’re a demand
like any other
A Radical Idea for the Transformational CIO

Example: Unified Demand Management
Features, Requirements, Enhancement, Problems, Defects, Chores

Big Tactic: The Balanced Product Team

As product teams, we want to...
Deliver value fast, forever
business outcomes
and user benefits
through working
features
quickly and often an ongoing basis without
burning out the team
24

To do this we have to work differently
Small teams that…
● consist of people with knowledge across business,
design, engineering
● have autonomy to make and act on product decisions
● are highly collaborative and communicative
● sit together
● are committed to an outcome, not a specific solution
● constantly test their ideas
● talk to the people they’re designing for often
● ship features often
● celebrate learning
● embrace change with new information
2
5

How do we deliver value fast, forever?
2
6

Our approach at Pivotal blends three methodologies
Lean StartupAgile/XP
User-centered design
2
7

This is what it looks like in practice
Define product vision, strategy
and roadmap
Define business model
Define Minimum Viable Product
Identify and test assumptions
Release real product often
Understand customers
Adjust direction based on data
Constrain resources and time
Agile/XP Lean Startup
User-centered design
2
8

and roadmap
Agile/XP Lean Startup
User-centered design User interviews
Ethnography
Define personas
Usability testing
Service design
UI/UX
Visual design
2
9

and roadmap
Agile/XP
Test-driven development
Pair programming
Evolutionary design
Collective code ownership
Retros
Short iterations
CI/CD
Lean Startup
User-centered design User interviews
Ethnography
Define personas
Usability testing
Service design
UI/UX
Visual design
3
0

The product team composition can vary
DESIGNER
ENGINEERS
Compliance
Risk
Security
QA
PM
PO
DevOps
Marketing
Data Science
Domain experts
31
Support Center

Why Lean Startup?
The greatest risk today is pace of change
All predictions about the future are
assumptions.
Testing quickly whether our assumptions are
right or wrong through experiments allows
us to course correct before spending too much
time or money.
32

Lean Startup Is….
• Test your assumptions
• Understand your customers
• Get real product into the world fast
• Adjust direction based on evidence
A management approach that mitigates the risk of change,
by creating small products that test the creator’s
assumptions, and using customer feedback to evolve the
product, thereby reducing waste.
33

Why Agile?
Agility is the ability to react to change.
Agile teams are quick, flexible, and respond to
change without sacrificing on quality.
There are many implementations but most
assume collaborative, cross-functional and self-
organizing teams that deliver software in an
incremental and iterative way
34

Why Extreme Programming?
Ensures a team builds working software at a consistent speed and quality in
the face of changing requirements
communication
courage
feedback
simplicity
Pair Programming
Test-Driven Development
Short iterations
Incremental planning
CI/CD
Self-documentation
Evolutionary design
Small teams
Collective ownership of code
Retros
35

Always be delivering (and testing) value
36

Why User Centered Design?
A product design philosophy that emphasizes
designing the product around how the user
can, wants or needs to use it, rather than
seeking to change the user's behaviors around
how the product works.
It prioritizes contact with end users, and not
proxies, in order to determine value.
37

We seek to build empathy
38

We do this by spending time with the people we design for
● Ask questions
● Observe them in action
● Put prototypes of our ideas
in front of them
● Watch them use our
product
A scientist’s mindset - we
ask the right questions and
interpret the data
39

Through empathy….
Users
Needs
Uses
Features
Deliver
LEARN
We discover people’s
implicit and explicit needs
so that we can address
them through solutions
40

Balanced teams collectively own the responsibility to deliver
value fast, forever
DESIGNER ASKS:
“How is the user affected? Is this a
problem for users? Can the user
accomplish what he or she needs to?”
PRODUCT MANAGER
ASKS:
“By solving these specific
user problems with these
specific solutions, are we
creating valuable business
outcomes?”
ENGINEER ASKS:
“What are the technical
complexities necessary to
satisfy the project and
product goals best?”
41

Balanced team composition can vary depending on the
organization and product
42
DESIGNER
ENGINEERS
Compliance
Risk
Security
QA
PM
PO
DevOps
Marketing
Data Science
Domain experts
Support Center

Tactic: Products, not Projects

A Day & Week in the Life of a Product Organization
44

What is a Product Manager?
Core team member responsible for defining what and
why (not the how), prioritizing work for the team, and
leading the collaborative process of product
development
Is responsible for answering: “Is what we are doing
valuable for the business?”
45

What does a Product Manager do?
● Defines a product vision and strategy
● Establishes an outcome-based product roadmap
● Establishes and tracks against measurable objectives
● Continually de-risks product direction
● Prioritizes features
● Manages the backlog
● Ships software early and often
● Helps the team maintain sustainable pace
46

Two views of product org: Functional business/IT split
Product Owner (definition focused)
● Defines a product vision and strategy
● Establishes an outcome-based product roadmap
● Establishes and tracks against measurable objectives
● Continually de-risks product direction
Product Manager (delivery focused- sits with team)
● Prioritizes features
● Manages the backlog
● Ships software early and often
● Helps the team maintain sustainable pace
47

Two views of a product org: Integrated org with vertical
goal cascade
PM PM PM PM PM PM
Group PM Group PM
Product Owner
A PM works on a feature
A group PM oversees a
related set of features
A product owner oversees
a complete product
48

What about Project Managers?
Project management is about organizing, coordinating, and delegating work
Defining product
direction
Articulating
product strategy
Translating
product strategy
into tactical work
Managing release
timelines and
dependencies
Coordinating with other
teams around releases
Coordinating with other
teams around product
priorities
Project managers
focus here
Product roles
focus here
Managing budgets
and resources
Setting business
outcomes
Prioritizing work

Ultimately, you want to ensure...
● There is a product vision, strategy, roadmap, metrics,
tracking of product performance
● Someone is dedicated to and co-located with engineers
and designers to unblock, provide product direction,
manage backlog
● Minimal communication overhead
● Accountability
50

Tactic: Scaling out an Independent Digital Lab

CUSTOMER-DRIVEN PRODUCT
DEVELOPMENT
MODERN SOFTWARE
DEVELOPMENT PRACTICES MODERN TECHNOLOGY
THEINTEGRATED DIGITAL LAB
BUSINESS& CUSTOMERVALUE
TRUST
(e.g., Shared Goals, Portfolio
Planning) CAPITAL
(e.g., Strategic Planning and
Funding)
PEOPLE
(e.g., Recruiting)
The existing organization

The Integrated Lab: Reference Model (100 people)
4 Directors
12 Product Managers (1:6 engineers)
12 Product Designers (1:6 engineers)
72 Engineers
AN ORGANIZATIONAL REFERENCEMODEL FORAN INTEGRATED LAB

Balanced Leadership Team:
The core of any Lab organization is a balanced
leadership team, made up of an Office
Director, and three Associate Directors who
represent each practice (Engineering, Design,
and Product Management).
The OD focuses 80% externally, m aintaining
strategic alignm ent with the parent
organization and supporting team s.
The AD’s focus 80% internally, organizing
team s, driving practice developm ent, and
fostering culture.
AN ORGANIZATIONAL REFERENCE MODEL FOR AN INTEGRATED LAB

The Head of Labs: 80% External Facing
The head of the Lab is responsible for creating
and maintaining an open exchange of trust,
capital, and people between labs, and
between the lab and it’s parent organization.
This role facilitates communication and
collaboration between the lab, executive
leadership, and supporting teams (HR,
recruiting, finance, legal, and marketing to
name a few).
The head of the lab will work with the parent
organization to determine lab success metrics,
drive these, and report out on a regular
cadence.

Associate Leadership: 80% Internal Facing
Product Team Management: Associates meet
weekly to align people and skills to products.
Sales & Marketing: Associates promote lab
capabilities across the parent organization,
and create a pipeline of new product work.
Culture and Practice Development: Through
example, mentorship, and direction,
Associates establish lab culture, and evolve its
capabilities.
People Management & Hiring: Associates
manage labs practitioners, and recruit and
assess new candidates.

Seed Team:
The seed team establishes balance and
practice leadership from day one. These
people should represent the strongest values,
skills, and actions that the Labs is measured
on. They will establish the culture that enables
the lab to scale.
(Often, only one AD exists early on in the Lab.
But since it’s important that all practices have
strong representation, a senior practitioner or
manager should balance out the team.)

* 3-6
months
* 6-12
months
* 12-18
months
* 18-24
months
Scaling Product Development:
As teams are working, they are learning,
teaching, and solving problems in every area
of a product, or process. In this way, everyone
is teaching each other, all the time, on how to
build.
Through disciplined pairing, it could take as
short as *3-6 m onths for som eone on this
team to becom e expert enough to assim ilate a
new person.
In this ideal m odel, every *3-6 m onths, it’s
possible to double the size of your team .
*every team/organization is different. This represents best-cases.

Balanced Product Team:
The function of a balanced team is to define,
build, and ship software products that deliver
customer and business value. Optimized for
tight learning loops, teams work in iterations
of weeks versus quarters or years. Balanced
teams take various sizes based on the stage,
scope, or complexity of work, but always
represent these same core values.
Grow the Lab one team at a time, based on
the incoming, projected product demands.
Ratio, 1:6 (a skilled PM/PD can keep up to 3
pairs of engineers busy)

People Managers:
People Managers work 1:1 with practitioners
to develop practice expertise, and help with
professional development. Managers are also
hands-on practitioners.
● AD’s m anage Managers.
● Managers m anage practitioners.
● Managers contribute to product
developm ent ~35h/week.
● Managers m eet casually 1:1 with their
reports bi-weekly for 15-30min.
● 1:1’s focus on personal, project, and
team health and happiness.
Ratio, 5:1 (average; m entors to m anagers)

Practice Groups:
Maintaining practice growth is an important
investment in the sustainability of the lab; in
each location, and across labs. Teams meet bi-
weekly to learn best-practices, share, and
level-up.
In addition to these weekly practice group
meetings, each practitioner has at least 1 day
per year, and a $2000 budget set aside for
professional development.
A practice counsel is useful in synthesizing and
sharing local practices globally, and bringing in
outside expertise.

Balanced Teams: Outcome Driven, Autonomous, & Transparent
The function of a balanced team is to define, build, and ship software products that deliver customer and
business value. Optimized for tight learning loops, teams work in iterations of weeks versus quarters or years.
Balanced teams take various sizes based on the stage, scope, or complexity of work, but always represent these
same core values.
Discovery Small
Product
Team
Large
Product
Team
Integration BA
Solution Architect
Application Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

Discovery teams validate market value,
feasibility, and customer needs before
a product/feature is com m itted to.
Discovery Sm all
Product
Team
Large
Product
Team
Integration BA
Solution Architect
Etc.
Exam ples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

Small product teams are great for
smaller scope applications and
products, or for MVP’s, and pre-scale
products.
Discovery Small
Product
Team
Large
Product
Team
Integration BA
Solution Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

Large product teams are useful when there are
multiple, well defined tracks of development work in
the backlog. Typically, one PM/Designer can team up
with up to (not exceeding) 3 pairs of Engineers.
Discovery Small
Product
Team
Large
Product
Team
Integration BA
Solution Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

Scaled product teams collaborate on a portfolio (i.e. a very large product or
set of products), where each balanced team is focused on a product which can
be released independently from other-products of the portfolio.
Discovery Small
Product
Team
Large
Product
Team
Integration BA
Solution Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

Support roles work as pairs and/or consultants to the Product Teams. Teams will call in subject matter
experts as needed, but work to keep transparency and awareness high. Support roles often pair directly,
and are invited to weekly planning meetings and demos to raise their comments/concerns.
Discovery Small
Product
Team
Large
Product
Team
Integration BA
Solution Architect
Examples of
Supporting
Roles (SME’s)
Etc.
Program
(or Product Area)
Team

Discovery Small
Product
Team
Large
Product
Team
Integration BA
Solution Architect
Examples of
Supporting
Roles (SME’s)
Etc.
Program
(or Product Area)
Team
Anchors are subject matter experts on their product/feature/component,
and maintain consistency and continuity for longer durations.

While a scaled product team may be geographically distributed, the balanced
team contained within it is co-located. Ideally each product team is located as
close to their primary customer as possible.
Integration BA
Solution Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

On massive scaled products, where multiple balanced teams are working to deliver
outcomes across many customer touch-points, the addition of Sr/Dir roles provide
product, design, and technical leadership and vision.
Integration BA
Solution Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

Chief Facilitators (or program mngrs) grease the wheels
between teams focusing on enabling and increasing
communication and collaboration between teams.
Integration BA
Solution Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team

Integration BA
Solution Architect
Etc.
Examples of
Supporting
Roles (SME’s)
Program
(or Product Area)
Team
Leadership meetings happen weekly (or as frequently as daily
standups) to make sure high-level initiatives are unblocked and on-
track, and to discuss system level decisions and strategy. Pivotal
uses tracker (or simple spreadsheets) to manage this view.

Balanced Teams: Cadence
The iteration cadence and rituals of a balanced product development team help ensure efficiency, transparency,
and alignment within, and around the team. Iterations are typically one week.
Stand Up: Each morning, the team meets for 15 minutes to
share what they did the day before, what they’re planning for
that day, and announces any blockers/risks. The team literally
“stands up” to keep the meeting short and focused.
IPM (Iteration Planning): Once a week, the team,
key stakeholders, and support roles meet for 60
minutes to align on current priorities and
estimate the complexity of upcoming stories.
Project Status: Once a week,
Design/PM/Eng product leads meet with
key stakeholders and support roles for
30 minutes to share progress.
Retro: Once a week, the team
meets for 60 minutes in an
open, safe forum to talk about
things to Keep/Stop/Change.
Lunch & Learn: Once a week, the Lab
gets together for lunch to share/learn
something new. Can be an internal or
external presenter.
Practice Groups: Designers, PM’s,
Engineers meet once a week to
share and learn from peers on
other product teams.
MM T W Th F
Demo: Weekly/Bi-
Weekly demos
showing work in
progress.

Technology: Cloud Native Microservices

75
A Cloud Native Platform Architecture

Example Microservice Architecture

Hybrid Scenario: Bi-Directional Data Replication

Hybrid Scenario: Peer Replication with Service Registry

Hybrid Scenario: Client-Side Load Balancing with Ribbon

Economics, Tactics, Technology
1.Tactic: Map your Situation and Roles
2.Economics: The Cost of Delay
3.Small, Radical Tactic: Unified Change Management
4.Big Tactic: The Balanced Product Team
5.Tactic: Products, not Projects
6.Big Tactic: The Independent Digital Lab
7.Technology: Cloud Native Microservices

Special Thanks to
• Pivotal
– Teresa Leighty
(Pivotal Transformation)
– Jateen Bulsara, Lyle Murphy
and Adib Saikali (Pivotal Toronto)
– Countless other Pivots who
contributed to the content
•Black Swan Farming
– Cost of Delay Urgency
Profiles
http://blackswanfarming.com/urge
ncy-profiles/
• Simon Wardley
– How we used to organize stuff
(Multi-Speed IT)
http://blog.gardeviance.org/2014/
11/how-we-used-to-organise-
stuff.html
• Charles Betz
– How to Unlock Enterprise IT
Gridlock
http://www.bmc.com/blogs/how-
to-unlock-enterprise-it-gridlock/

Applied tactics for your transformation

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Applied tactics for your transformation

Similaire à Applied tactics for your transformation (20)

Plus de Stuart Charlton

Plus de Stuart Charlton (15)

Dernier

Dernier (20)

Applied tactics for your transformation