Building Scalable Organizations

Building Scalable
Organizations
Marty Abbott
Mike Fisher
Partners – AKF Partners
“We wrote the book on scalability” www.akfpartners.com

2
Our Business
 Focused on helping companies scale their architecture, organization, and processes
 11 Partners, Associates, and Consultants
 Over 350 Clients in 12 countries

The Power of Customer Misbehavior: Drive Growth and Innovation by
Learning From Your Customers
3
Published Books
Scalability Rules: 50 Principles for Scaling Web Sites
 Addison-Wesley Professional (2011)
 Translated into Japanese and simplified Chinese
The Art of Scalability: Scalable Web Architecture, Processes, and
Organizations for the Modern Enterprise
 Addison-Wesley Professional (2009)
 Translated into Korean, simplified Chinese, and English for India
 Palgrave Macmillan (2013)

Drivers of Innovation
Context for the Agile Organization

Innovation
5
Cognitive Conflict
As cognitive conflict increases (what and why), so
does innovation
+
**De Dreu and Weingart 2003
Cognitive
Conflict

As affective conflict increases (who and how),
innovation decreases
Innovation
Affective
Conflict
Cognitive
Conflict
-
+
**Amason and Mooney, 1999; De Dreu and Weingart 2003
6
Affective Conflict

Innovation
7
Empowerment
Feelings of empowerment increase innovation
Sense of
Empowerment
Affective
Conflict
Cognitive
Conflict
+
-
+
**Spreitzer, De Janasz, 1999

Innovation
8
Org Boundaries
Organizational boundaries across which collaboration
must happen increase affective conflict
Sense of
Empowerment +
Affective
Conflict
Cognitive
Conflict
-
+
Organizational
Boundaries
+
** Tajfel 1974; Hogg and Terry 2000; Cummings and Kiesler 2005

Both cognitive and affective conflict driven by diversity in
experiences
Innovation
Sense of
Empowerment +
Affective
Conflict
-
+
+
** Burt 2001; Bassett Jones 2005; Abbott, Lyytinen et al. 2010
9
Diverse Experience
Cognitive
Conflict
+
Organizational
Boundaries
Experiential
Diversity

Best when high number of non-overlapping
network links (loose acquaintances) outside of the
organization
Agile Team
** Burt 2001; Bassett Jones 2005; Abbott, Lyytinen et al. 2010
10
Network Diversity
Network
Diversity

The greater the network diversity, the higher the
innovation
Network
Diversity
Innovation
11
Network Diversity
Sense of
Empowerment +
Affective
Conflict
Cognitive
Conflict
-
+
+
+
** Burt 2001
Organizational
Boundaries
Experiential
Diversity
+

Barriers to Success
Context for the Agile Organization

13
Monolithic Applications
Product:
Foo.com
Agile Tm 1
Agile Tm 2
…
Agile Tm N
Conflict!
Network
Diversity
Innovation
Empowerment
Affective
Conflict
Cognitive
Conflict
Organizational
Boundaries
Experiential
Diversity

14
Functional Organizations
Conflict!
Conflict!
Biz PM Eng QA INF Ops
Conflict!
Network
Diversity
Innovation
Conflict!
Empowerment
Affective
Conflict
Cognitive
Conflict
Agile Team 1
Agile Team N
Conflict!
Organizational
Boundaries
Experiential
Diversity

Innovation Decreases:
1) No Empowerment/Ownership
2) Does not leverage network
3) Does not leverage experience
15
Top Down Innovation
Network
Diversity
Innovation
Empowerment
Affective
Conflict
Cognitive
Conflict
Boss
Organizational
Boundaries
Experiential
Diversity
Product Teams

Moving Forward
Steps to Create a Truly Agile
Organization

 Agile Product Teams
aligned with Services
 Multi-Disciplinary Agile
17
To Succeed We Must Move
From This:
 Monolithic Products
To This:
 Service or Resource
Oriented Systems
 Silo’d Organizations with
Agile Overlays
 Agile within only software
development
Teams

 Learning Organizations
18
To Succeed We Must Move
From This:
 Moving from Fire to
Fire
To This:
 Hubris and “Wicked
Smart People”
 Humility and Great
Performing Teams
 Top – Down, Sparse
Innovation
 Organization Wide
Innovation and
Ownership

Agile Processes, Agile Orgs, and
Innovation
The Future

20
Yesterday
 Monolithic
Application
 Waterfall
Process
 Functional
Organizations
Product:
Foo.com
Product Engineering QA Operations

21
Today
 Agile teams don’t perform well with monolithic apps
(conflicts).
 Teams still engage in affective conflict (bad) about who
and how.
 Innovation increases due to experiential diversity but is
still sub-optimized.
Product Engineering QA Operations
Product:
Foo.com

22
The Fix
 Services or
Resource Based
Architectures
 Multidisciplinary
Development and
Deployment
Teams
Search
Search Team
Registration
Registration Team
…

23
The Reasons
 Teams that “own” a product (or service) perform better.
 Functional roles and managers add little value in Agile.
The managers don’t see enough of the individual
performance to be worthwhile.
 Conflict across organizations about conflicting goals
and ownership do NOT increase value added cognitive
conflict.
 Innovation works best when there is a single team
identity – not identity conflict.

“NoOps” Organization Model:
• The “NoOps” model is most often associated with Netflix and their near 100% use of the AWS Cloud.
• High scalability and fast Time to Market are primary goals of this model. Cost management is secondary.
• Budget and responsibility of figuring out how to use public cloud IaaS was given directly to the Development organization after failed
• Relies heavily on near 100% automation for all critical development and releases processes.
• The concept of ITOps and private data centers exist at Netflix however they support the physical Netflix service of delivering DVDs.
• Netflix has a developer-oriented culture starting with the CEO Reed Hastings who was a developer.
24
“NoOps” Netflix Model
Services
Teams
CORE Team (Cloud
Operations Reliability
Engineering)
Responsible for:
- Monitoring
- Application
Performance
Management
attempts to quickly scale out data centers during periods of extreme growth.
“A handful of DevOps engineers …are coding and running the
build tools and bakery, and updating the base AMI from time to
time. Several hundred development engineers use these tools to
build code, run it in a test account in AWS, then deploy it to
production themselves. They never have to have a meeting
with ITops, or file a ticket asking someone from ITops to
make a change to a production system, or request extra
capacity in advance... This is part of what we call NoOps. The
developers used to spend hours a week in meetings with Ops
discussing what they needed, figuring out capacity forecasts and
writing tickets to request changes for the datacenter. Now they
spend seconds doing it themselves in the cloud…
There is no central control, the teams are responsible for figuring
out their own dependencies and managing AWS security groups
that restrict who can talk to who.”
– Adrian Cockcroft
- http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.
html

“Full Stack” Organization Model:
• Minimizing risk and moving fast are primary goals of this model.
• Teams responsible for services have all of the necessary skill to be innovative and release frequently. They have knowledge of UI/UX, Mid-
• Facebook emphasizes ”Full Stack” development teams that work together to deliver services.
• Facebook also has a sizeable Release Engineering team that assists with releases multiple times daily and weekly.
• Facebook Infrastructure Engineering is a separate organization that is responsible for data centers, capacity planning, etc.
• Facebook has a developer-oriented culture starting with the CEO who was a developer.
Release Engineering
Responsible for:
- Controlling releases
- Daily pushes
- Weekly pushes
25
“Full Stack” Facebook Model
Full Stack
Dev Team
Infrastructure Engineering
- Data Centers
- Server build out
- Capacity
- Performance
- Incident Management
Tier services, Databases, Hosting environments, Networks, etc.
“None of the previous principles work without operations and
engineering teams that work together seamlessly, and can
handle problems together as a team. The person responsible for
something must have control over it. At Facebook we push code
to the site every day, and the person who wrote that code is there
to take responsibility for it.
.. We have three people working on photos. Each of those three
people knows photos inside and out, and can make decisions
about it. So when something needs to change in photos they get it
done quickly and correctly.“ – Peter Deng
- https://www.facebook.com/note.php?note_id=409881258919

Hybrid Infrastructure Core & Services:
• The comparable SaaS company transitioned from a 3-tiered Engineering/Services Delivery (similar to Prod Ops at Citrix)/Infrastructure to a
model that combined Engineering and Services Delivery into a single team while dividing Infrastructure into two team dedicated to core
services and delivery services.
• This model allows for flexibility based on product line. Mature, slow-growth product lines can leverage shared Infrastructure teams and do
not need dedicated Infrastructure team members in the agile teams. High-change/High-Growth services need dedicated Infrastructure
service team members embedded within the Agile team for fast time-to-market and innovation.
26
Intuit Model
Motivation For Change

Spotify Model
A real‐world example of a service oriented, cross‐functional team can be found at Spotify. Their
organizational structure is not functionally aligned but rather is organized into small Agile teams, which they
refer to as Squads. These are self‐contained teams organized around a deliverable or service which the
business provides. The following image and descriptions are taken from Henrik Kniberg and Anders
Ivarsson’s October 2012 paper “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”
27

Spotify Model Cont’d
A squad is similar to a Scrum team, and is designed to feel like a mini‐startup. They sit together, and
they have all the skills and tools needed to design, develop, test, and release to production. They are a
self-organizing team and decide their own way of working – some use Scrum sprints, some use
Kanban, some use a mix of these approaches. Each squad has a long‐term mission based on a
service, which that team supports. Squads have a dedicated product owner that prioritizes the work and
takes both business value and tech aspects into consideration.
A tribe is a collection of squads that work in related areas. The tribe can be seen as the “incubator” for
the squad mini-startups. They have a fair degree of freedom and autonomy. Each tribe has a tribe lead
who is responsible for providing the best possible habitat for the squads within that tribe. The squads in
a tribe are all physically in the same office, normally right next to each other, and the lounge areas
nearby promote collaboration between the squads. Tribes are less than 100 people in total.
The chapter is a small group of people having similar skills and working within the same general
competency area, within the same tribe. Each chapter meets regularly to discuss their area of expertise
and their specific challenges. The chapter lead is line manager for her chapter members, with all the
traditional responsibilities such as developing people, setting salaries, etc. However, the chapter lead is
also part of a squad and is involved in the day-to-day work, which helps her stay in touch with reality.
A guild is a more organic and wide-reaching “community of interest”, a group of people that want to
share knowledge, tools, code, and practices. Chapters are always local to a tribe, while a guild usually
cuts across the whole organization. Some examples are: the web technology guild, the tester guild, the
agile coach guild, etc.
28

Building Scalable
Organizations
Thanks for Having Us!

Building Scalable Organizations

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie Building Scalable Organizations

Ähnlich wie Building Scalable Organizations (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Building Scalable Organizations