W H I T E PA P E R

Organisation: Doing
What Matters
Guiding enterprise transformation and DevOps adoption for
enduring success in the digital economy.

1
 Contents
A paradigm shift in IT for business 3 A modern business structure 23
Responding to digital disruption 6 Who are DevOpsGroup? 26
Ecosystem 10 Reading list 28
Products 13 Appendix 30
Team 16

“ “
There is nothing quite so useless as doing with great efficiency
something that should not be done at all.
Peter Drucker

2
A paradigm shift in IT for business
Organisations like Netflix, Etsy, Facebook and Google are regularly held up as examples of ‘how to do IT right’
in the digital age. They were the forerunners of the DevOps movement, willing and able to construct their own
methodologies, building DevOps toolchains from disparate open source products.

Their success is testament to the technical and business benefits of a DevOps approach to software development.
Adaptive management of technology enables the organisation to operate with agility, dynamically aligning itself
with evolving trends, demands and technical advances.

DevOps isn’t just for digital trailblazers

As traditional methods of IT service delivery become increasingly unfit for purpose1, DevOps represents an effective
way forward. This is true for any business with online operations, not just digital trailblazers. Like cloud, it has
crossed the chasm to reach the early majority phase of adoption.

However, this new wave of uptake largely involves traditional, enterprise-level organisations that don’t have a digital
native mindset. They have a pragmatic outlook and don’t want to build everything from the ground up. They’re
looking for a structured, safer, more predictable approach to DevOps transformation.

3
 Easing the pain of transformation
The enormity and complexity of driving change in a large, established organisation cannot be underestimated.

When you encounter difficulties it’s easy to think you’ve failed. In fact, you’ve probably hit an inevitable challenge
that can be overcome if it’s approached with insight and tenacity.

To help the early majority navigate a more seamless and productive transformation, DevOpsGroup has devised The
Adaptive ITTM Framework (Fig 1). It’s geared towards the fundamental business need for agility and adaptiveness in
the digital age. It encompasses the various interconnected elements that need to be addressed to achieve this. And
it shows how common transformation barriers can be anticipated and mitigated before they escalate.

The Adaptive IT Framework comprises five pillars which impact an organisation’s ability to change. Technology is
just one part of a much longer equation which also encompasses deep-rooted factors such as culture and ways of
working. In this paper, we explore the Organisation pillar, looking at how changes to team structure, purpose and
accountability can transform business capabilities and performance.

4
 Strategy Organisation Culture Ways of Working Technology
Working backwards From project Unlock the power of Iterative Automate
from the customer to product your people value delivery to accelerate

Leadership Ecosystems Psychological Systems Cloud

Saftey Thinking

Objectives Products Learning Lean Platforms

Metrics Teams Autonomy Agile Automation

Measures
Business Lead time, MTTR,
Customer performance Employee deployment change failure
satisfaction measures satisfaction frequency rate, availability

Fig 1: The Adaptive ITTM Framework, devised by DevOpsGroup to convey the depth and breadth of factors that need to be addressed during enterprise scale transformation.
Copyright © 2019 DevOpsGroup www.DevOpsGroup.com
5
 Transforming
the enterprise
The rise of cloud computing has fundamentally
changed the corporate IT landscape. Technical
capabilities such as on-demand access to compute
resource, ease of configuration and scalability are
just one part of this. Cloud has also disrupted the
economic model upon which traditional corporate IT
was built.

In this paper we look at the repercussions for

organisational design, considering what needs to
change and why, before looking at the ‘how’.

Responding Traditional IT departments are organised by

technological specialism and optimised for efficient

to digital use of scarce computing resources. In the 1990s and

early 2000s, procurement of enterprise computing
assets consumed large amounts of capital expense
disruption (CAPEX). Work delivery models – or projects – were

6
also large and featured on the organisation’s balance
sheet. Consequently, these assets were ‘sweated’ to
deliver maximum service as their value depreciated.
Conversely, in a cloud-enabled world computing
resources are no longer scarce. In fact, they are
ubiquitous, with per-minute billing models which
represent an operational expense (OPEX) rather
than CAPEX.
Cloud and transaction costs
economics
What does this change in the underlying economic
model mean for the design of the (IT) organisation?
Transaction cost economics offers an effective lens
through which to analyse the impact of the cloud-
driven shift in IT economics. Ronald Coase2, Nobel
Prizewinning economist, proposed that the ‘nature of
the firm’ and specifically the ‘boundaries of the firm’
are based on six transaction costs. These are analysed
with respect to cloud computing in Table 1.
In line with Coase’s theory, the low transaction costs
of cloud computing mean it makes economic sense
to rely on ‘the market’ (competing external suppliers
contracted to supply goods and services) rather
than ‘the hierarchy’ (internal resources, within the
organisation). Hence the rise of Shadow IT3 which
doesn’t fall under the control of the IT function. Why
would people go via the often over-stretched, under-
resourced central IT department when they can
access anything they need direct from Amazon AWS
or Microsoft Azure, with the only barrier being the limit
on their corporate credit card? The answer of course
is that they won’t, and they aren’t. In turn, this has led
to an existential crisis in central IT departments.
DevOps is a response to this
existential crisis4
It lowers internal transaction costs, flattens hierarchies
and makes the IT function more responsive to internal
customers. They, in turn, aim to continually adapt
to the changing needs and escalating demands of
external customers in the digital economy.
7
 In Good to Great5 Jim Collins says that high-
performance organisations think ‘who’ first, ‘what’
second. Likewise, in From Project to Product6
Mik Kersten suggests that high-performance
organisations bring the work to the people, not the
people to the work. In both cases, the advice is to
organise the people, then organise the work and use
technology to accelerate momentum. And this is what
DevOps achieves.

Here we look at three facets of organisational design

for a transforming business: an ecosystem structure,
shifting from project-led to product-centric work and
building autonomous multiskilled teams. Together
they foster effectiveness and efficiency. Or to put it
another way, they help ensure the business is doing
the right things, and doing them right.

8
 Type of Cost
Search and Information
How to find the resources & the information
you need to make a buying decision
Bargaining and Decision
How to negotiate the best deal, and decide
which supplier to use
Policing and Enforcement
How do you ensure you get what you paid
for, and how difficult is it to enforce that
contract if things go wrong?
Table 1 – Transaction Costs & Cloud Computing (based on Coase's The Nature of the Firm)
Traditional IT (on-premise)
Medium
Whilst in theory being bound to one supplier
(the traditional in-house IT department)
should offer near zero search and information
costs, in many enterprise organisations
finding the right people and the right process
to meet your IT needs can be very complex.
High
Internal processes to obtain compute
resources, particularly where large capital
outlays are required, are often labyrinthine
and dysfunctional.
Medium
In most enterprise organisations, governance
for large scale IT projects can be costly
and time-consuming. It’s also ineffective
to the extent that cost-overruns in large
scale IT projects are the norm rather than
the exception.
Cloud
Low
There are a limited number of hyperscale
public Cloud providers (Amazon AWS,
Microsoft Azure, Google GCP, Alibaba
Alicloud), all with broadly similar offerings,
with clear documentation of their offerings via
web portals.
Low
While there are regional variations in per-minute
billings, the pricing is clear and transparent. It
is possible to negotiate enterprise pricing for
high-volume commitments.
Low
Most service providers offer automatic
refunds / service credits if SLAs aren’t
met. SLA information is easily available via
real-time monitoring systems. Spend on IT
consumption can be monitored and alerted
on in real-time.
9
 Adaptable and
dynamic
Traditional organisations are built around the linear
metaphor of the product line, with clear delineations
between supplier, company and customer following
a unidirectional flow of value. However, in modern
organisations these delineations are not so clear cut,
and the flow of value is not straightforward.

A more appropriate metaphor for the 21st Century

organisation is that of the ecosystem – a complex
community of internal and external individuals and
organisations with non-linear dependencies between
them. It can comprise vendors, partners, staff,
customers and other stakeholders, with different
elements both competing and cooperating to

Ecosystems create value.

The ecosystem model is more complex, but it is also

more dynamic. It lends itself to fluidity in the way

10
skills, knowledge and expertise are sourced, enabling
the organisation to rethink boundaries between
what is held in-house and outsourced. This unlocks
new possibilities in the way resources are deployed,
enabling a more adaptive approach to deliver
continually improving customer outcomes.
An article on ecosystem advantage7 by Professors
Peter Williamson and Arnoud De Meyer defines six key
facets of this approach:
1. Clarity about the creation of value added
2. Definition and structure of
It’s interesting to note the reference to transaction costs,
as discussed earlier in the context of the economics
of cloud computing. Changing transaction costs, in
Coase’s view, ipso facto change the ‘boundary of the
firm’. So, it’s our belief that the boundary between what
is held in-house versus outsourced needs to become
increasingly fluid in the transformed organisation.
The impact of large scale, functional outsourcing
and offshoring of IT Services over the last 20 years
is a contentious topic. Our conversations with
enterprise CIOs and CTOs indicate a widely held

“
partner roles
3. Stimulation of complementary
partner investments
4. Reduced transaction costs A business ecosystem is a community of organizations
5. Stimulation of co-learning in
the network
6. Effective value
capture mechanisms
and individuals, stronger together than individually, that
co-work and co-evolve to fulfil a shared purpose through
both collaboration and competition interactions.8
“
Rafael Armani

11
 view that functional outsourcing has not delivered
the ROI expected, and is not a suitable model for the
digital age.
Our conversations with enterprise CIOs
and CTOs indicate a widely held view that
to agile and ‘capacity based’ sourcing models10 to
create the flexibility needed to respond to changing
customer needs. This more nuanced approach offers
a way to inject specialist skills and services when and
where they are needed for rapid, customer-driven
IT innovation.

functional outsourcing has not delivered

the ROI expected, and is not a suitable
model for the digital age.

Sector research supports this view. The 2018 Google

State of DevOps Report compiled by DORA9 says:
“Analysis shows that low-performing teams are 3.9
times more likely to use functional outsourcing
(overall) than elite performance teams, and 3.2 times
more likely to use outsourcing of any of the following
functions: application development, IT operations
work, or testing and QA. This suggests that outsourcing
by function is rarely adopted by elite performers”.

We’ve identified a clear trend for ‘insourcing’, moving

work back in-house to be delivered by multidisciplinary
teams of permanent staff combined with expert third
party specialists. Alongside this we see a clear shift

12
 The end of the
project mindset
The move towards long-lived, product-centric
approaches for software delivery and operations is
a core tenet of DevOps. Multiskilled teams take full
responsibility for products within a defined lifecycle,
from inception to retirement. This contrasts with the
more transient, project-led approach of traditional
IT, where teams and individuals are only responsible
for a narrowly defined segment of the process, then
hand over to a separate Ops team for the operational
lifecycle of the service. The upshot of a project
mentality is a lack of overall accountability which
hinders progress and performance.

Roman Pichler, a well-known author in the product

Products management area, defines a (digital) product as

“something that creates specific value for a group
of people, the customers and users, and to the
organisation that develops and provides it.”11

13
 Working in this way focuses everyone’s attention 1. Strive for simplicity: dependencies between
and effort on the product’s target outcome, which products and handovers between product
must be measurable and geared towards delivering teams should be kept to a minimum. Handovers
customer value. Objectives and worklists are create waste and dependencies prevent the
proactively managed to ensure each product delivers independent evolution and iteration of products.
maximum value (effectiveness) and minimal total cost
2. Deconstruct the product: ensure each product
of ownership (efficiency).
(or its loosely coupled components) are of a
This fosters a dynamic and collaborative spirit where size that can be managed by a small, long-lived
the team holds collective responsibility for success. team. As teams grow, management complexity
At a micro level, a developer is more likely to ensure and coordination time go up exponentially.
their code is up to standard if they work closely with
3. Set measurable outcomes: the product must
operations colleagues who will be directly impacted
deliver tangible value. If you can’t measure
by any problems. What’s more, efficiency is improved
it, then you can’t iterate and improve it (for
through joined-up decision making and rapid
instance, by increasing the value delivered,
feedback loops.
boosting efficiency or reducing lead time).
At a macro level, product portfolios can be plotted
4. Build a product matrix: plotting the product
onto a matrix which determines each product’s relative
portfolio according to ‘business value versus
value, thereby informing decisions about where to
desired rate of change’ is very effective. If
prioritise DevOps transformation efforts. We like the
something is high value and rapid iteration of
BCG Growth Share matrix.12
features is beneficial, it makes sense to prioritise
Based on our experience, an effective product-centric it for continuous integration, continuous delivery
approach comprises five best practice elements: and other DevOps efforts.

14
 5. Map the product lifecycle: outline the product
roadmap, from inception to retirement. Plot the
investments needed to support and manage this
journey to ensure products are characterised
with maximal value (effectiveness) and minimal
total cost of ownership (efficiency).
Continually adding tangible value to customers has
never been more important. This is equally true in a
B2B or B2C context.
Product managers play a critical role here. They need
to empower teams to streamline operational tasks,
delivering seamless and stable online experiences. At
the same time, they need to foster targeted innovation
and invention.
A product-centric approach offers an effective
way to achieve both these goals and more, giving
individuals a stronger sense of ownership, while
allowing greater autonomy and space for creative
experimentation. When this happens at scale within
teams across the organisation, innovation snowballs
and operations achieve a dynamic equilibrium,
protecting system stability.
VC-style funding
Traditional annual IT budgeting can be a constraint
for organisations moving to a product-centric model.
Funds are often split 30/70 for ‘change’ (projects) and
‘run’ (support, maintenance, recurring spend) activity.
This reinforces divisions between Dev and Ops, and
budgets are set in stone for 12 months, so it’s hard to
respond to emerging factors.
Aligning the organisation with Beyond Budgeting13
principles can help here. For instance, funds might be
allocated on a product by product basis. Budgeting
becomes more dynamic, with decisions informed by
a product's viability and its likelihood of delivering a
good return as it progresses iteratively through the
build-measure-learn loop.
Releasing budget incrementally as products evolve
mirrors VC series funding. It puts the onus on teams
within established enterprises to 'think like a scale-up'
which can go a long way towards fostering an adaptive
mindset, furthering the transformation agenda.
15
 Collaboration and
autonomy
Traditional IT operating models promote the grouping
of specialists around functional capabilities such as
development, testing, operations and security. These
are often further specialised into second line, third
line and so forth to serve multiple customers through
multiple products and services. The goal of each
function is to deliver on its own ringfenced area in line
with agreed service levels or milestones.

However, organisations like Google, Amazon and

Netflix show that turning this around to align people
and teams with specific customer outcomes enables
better adaptability. Moreover, research into team
performance, notably Google’s ‘Project Aristotle’14,

Teams shows the importance of inter-team dynamics in

creating high-performance teams. These dynamics
are best established in small, long-lived teams that
have time to learn to work together effectively.

16
But how do you go about building these teams in
practice when you’re not a digital trailblazer? What
practical steps can a more traditional organisation take
to engender a product-centric approach?
Amazon’s ‘Two Pizza Teams’ concept can be applied
here: if it takes more than two pizzas to feed a team,
it’s too big. So, focus on building product teams that
are small but perfectly formed. They must have the
accountability and authority to deliver customer
outcomes and comprise all the necessary roles to
achieve their goals. Dependent services such as
people who may have great depth of expertise but
tend to lack versatility and struggle to understand how
their work impacts others.
Structuring teams and developing individuals in this
way unlocks workforce productivity and creativity,
which in turn fosters the adaptability and innovation
required to succeed in the digital economy. Table 2
shows the typical roles contained in a product team.
Ability to work outside of core area

infrastructure, automation, monitoring and data may

be provided through platform teams (organised in the
same ‘Two Pizza’ format) via self-service capabilities.

Recruiting and developing ‘T-Shaped’ people is Copyright © 2019 - DevOpsGroup Ltd

also desirable. These individuals combine a good

breadth of knowledge and skills with deep expertise Functional
in a certain field (see Figure 2). Encouraging all team area, discipline,
or speciality
members to become T-shaped, and supporting them
in the process, facilitates more effective collaboration
in small, multiskilled teams. It also enables people to
complete work outside their main field of expertise
when the team requires it. This contrasts with ‘I-shaped’ Fig 2 – T-Shaped individuals

17
 Role title Role description

Technology & Cloud Strategy

Helps senior IT leadership shape IT strategy aligned with DevOps and cloud industry best practice.
Consultant

Provides expert advice on cloud-native application architectures and modernising legacy applications to
Cloud Application Architect
leverage modern cloud and DevOps technology.

Cloud Engineer / Consultant Provides hands-on engineering and/or technical consultancy on the cloud platform.

Provides security guidance and is responsible for identifying, developing and implementing security solutions
Cloud Security Consultant
for cloud environments.

DevOps Automation Engineer Provides hands-on engineering and/or technical consultancy on DevOps automation including infrastructure-
/ Consultant as-Code, configuration-as-code and other areas of DevOps automation.

Continuous Delivery Engineer Provides hands-on engineering and/or technical consultancy on the continuous delivery of software and
/ Consultant infrastructure including building automated CI/CD pipelines to accelerate the release of tested software.

Site Reliability Engineer / Provides technical guidance and operational support for applications & teams based on the concepts of Site
Consultant Reliability Engineering (SRE).

Table 2 - Typical product team roles

18
 Role title Role description

Provides expert advice on data management and assists teams to build & manage data platforms that
Data Platform Engineer
conform to customers’ needs and governance & compliance standards.

Provides expert advice on test automation and a platform that enables test automation at all stages of the
Test Automation Engineer
software development lifecycle.

Agile Delivery Manager (CSM) Provides team leadership and work management using Agile methods.

Agile Scrum Master Supports the Agile team as per the Scrum Master role.

Agile Transformation Coach /

Helps teams and organisations adopt Agile ways of working using frameworks like Scrum, SAFe and Kanban.
Consultant

DevOps Transformation Helps teams and organisations adopt end-to-end DevOps practices aligned to the organisation’s target
Coach / Consultant operating model and technical dependency tree.

Technical Trainer Provides technical training on tooling and practices to upskill teams, increasing autonomy and mastery.

Product Manager Holds responsibility for defining product value and features as well as ROI and stakeholder engagement.

Table 2 Continued - Typical product team roles

19
 In a DevOps organisation, communication barriers
between and within teams are broken down.
Dependency on any individual person or team to
progress software delivery is also eroded. This aligns
well with Agile principles. Roles outside the product
team, such as service users, business stakeholders and
assurance teams review and provide feedback on the
value that is being delivered.
Figure 3 (Delivery Team Model) and Figure 4 (Platform
Team Model) visualise what a product team may look
like, the type of work it might do and how it could
interface with platform teams (note that this is a high-
level representation).
It takes time to adjust to product-centric organisational
design. During the transition period, teams will need
education and coaching, as well as space to practice
and patience to achieve mastery.
When rearranging the business into self-organising,
autonomous teams it’s also worth considering the
relationship between organisational design and
software design known as Conway’s Law:
20
organizations which design systems ... are
constrained to produce designs which are
copies of the communication structures of
these organizations.15 
Melvin Conway
Teams need the freedom to traverse Tuckman’s group
development model16 (Forming, Storming, Norming,
Performing). This process helps the team become
a collaborative, psychologically safe environment
where levels of trust are high. Over time, with better,
more transparent communication between members,
the team becomes a cohesive, high performance unit.
Research from Microsoft dating back to 2007 supports
the view that software quality is strongly impacted by
organisational structure – full details are available in a
paper titled The Influence Of Organizational Structure
On Software Quality: An Empirical Case Study.17
The lesson for organisations is clear. Changes in
organisational design demand changes in software
design, and vice versa.
 Copyright © 2019 DevOpsGroup

Fig 3 – Delivery Team Model

21
 Fig 4 – Delivery and Platform Team Model

22
 From projects
to products
DevOps is grounded in the belief that product
teams should be fully responsible for everything that
concerns their software product, all the way from
inception through to retirement.

As discussed above, this collective responsibility

prevents individuals from simply performing their own
work without considering its impact along the software
delivery chain. The model extends beyond developers
and operations staff. Business analysts, UX designers,
testers, quality assurers, database administrators and

A modern
security professionals all have a role to play, under the
guidance of a product owner.

business The nuances of what the shift from a project-led to a

product-centric mindset looks like are summarised in
Figure 5.
structure
23
 Project Characteristic Product

Delivering the plan Focus Delighting the customer

Solution Funding Team

Functionally aligned Teams Cross-functional

Large Batch size Small

As long as it takes Speed to market As fast as possible

Agreed in advance Scope Determined by feedback

Low Autonomy High

High (perception is low) Risk Low

Output Metrics Outcome

Fig 5 - From project-led to product-centric

24
Everything is focused on the core goal of delighting Technology underpins pipelines and platforms
the customer. Cross-functional, highly autonomous enabling rapid delivery of small changes.
teams are empowered to work fast, delivering product
Together these factors enable the business to do
improvements that are rooted in evolving customer
the right things in the right way at the right time. So,
needs. The scope of work is dynamic, determined by
evolving customer needs are addressed and tangible
customer feedback. Success is measured in terms of
value is generated. It all adds up to better business
customer outcomes, rather than business outputs.
performance in the face of digital volatility.
And because changes are small and incremental, risk
is greatly reduced. All these factors combine to power
a virtuous cycle of continual improvement, closely
aligned with the customer.

The key message here is that purposeful organisational
design facilitates the transformation agenda.
Transformation is about more than technology and
DevOps is about more than automation. Success
lies in harnessing the triumvirate of ‘people, process,
technology’ strategically and intelligently:
Call us on 0800 368 7378 or book a call
here to arrange a free 2 hour AdaptiveIT
Framework workshop to help kick start
your DevOps transformation.

People are aligned with strategic goals and focused

on customer value.

Processes are geared towards effectiveness rather

than efficiency.

25
 Who are
DevOpsGroup?
DevOpsGroup empowers you to achieve more in the
digital economy by reinventing IT. Our engineering,
training and consultancy services embed DevOps
ways of working and facilitate cloud transformation.
By enhancing the capability and capacity of internal
teams, we unlock innovation, boost efficiency and
drive competitive advantage.

At DevOpsGroup we understand that technology

is only one part of the equation. That’s why we also
focus on cultural factors to instil an adaptive mindset
across every client’s business.

We work with businesses of all sizes and sectors,

from long-established enterprises undergoing
transformation to disruptive start-ups looking to scale
with stability.

26
27
 Reading list
The Goal: A Process of Ongoing Improvement Accelerate
Eliyahu M. Goldratt and Jeff Cox Forsgren, Humble & Kim

The inspiration for The Phoenix Project, The Goal Accelerate draws on four years of research,
explores the Theory of Constraints and shows including data from the State of DevOps Report,
the importance of identifying and eliminating to explore the predictive relationship between IT
constraints within an organisation. performance and organisational performance.

The Phoenix Project Measure What Matters

Gene Kim, Kevin Behr, George Spafford John Doerr

The Phoenix Project uses the story of Bill, an IT John Doerr, venture capitalist and 45 year OKR
manager at Parts Unlimited and his struggle to advocate, provides first hand behind the scenes
save the failing Phoenix project, to introduce the case studies of how this concept helped some
Three Ways of DevOps. of the world’s most successful companies.

Turn the Ship Around Project to Product

David Marquet Mik Kersten

David Marquet describes how he drastically Mik Kersten argues that to survive the age of
altered the culture aboard the USS Santa Fe digital disruption, organisations must switch
to create leadership at every level resulting in from a product-centric view of software delivery
improved morale, performance and retention. to one focussed on delivering business value.

28
The Fearless Organization
Amy C. Edmondson
Renowned author and Harvard Business School
Professor Amy Edmondson provides practical
guidance for teams and organisations serious
about success in the modern economy.
Re:Work
Google
re:Work is a collection of practices, research,
and ideas from Google and others about the
importance of organisations putting people first.
The DevOps Handbook
Gene Kim, Jez Humble, Patrick Debois & John Willis
The DevOps Handbook shows technology
leaders how to balance speed, agility and
security by integrating Product Management,
Development, QA, IT Operations, and
Information Security.
Making Work Visible
Dominica DeGrandis
Dominica DeGrandis provides a practical guide
to help eliminate the five thieves of time that are
pushing workforces to the edge of burnout and
destroying productivity.
Continuous Delivery
Humble & Farley
Continuous Delivery sets out the principles
and technical practices that enable rapid,
incremental delivery of high quality, valuable
new functionality to users.
Ahead in the Cloud
Stephan Orban
Stephen Orban demonstrates how organisations
must re-train their people, evolve their processes,
and transform their cultures as they move to
the cloud.
29
 Appendix
1. Read more about why legacy approaches to IT are no longer 10. Delivering on the Promise – Sourcing Options for Agile
fit for purpose in our Adaptive IT Framework paper. Workloads in IT, Bob Traughber and Carol Wright
https://isg-one.com/consulting/articles/delivering-on-the-
2. The Nature of the Firm, Ronald Coase (1937)
promise-sourcing-options-for-agile-workloads-in-it
3. Is DevOps your defence against Shadow IT?, Steve Thair
11. What is a digital product?, Roman Pichler https://www.
https://www.devopsgroup.com/blog/is-devops-your-
romanpichler.com/blog/what-is-a-digital-product/
defence-against-shadow-it/
12. The BCG Growth Share Matrix https://www.bcg.com/en-gb/
4. What is the future of central ‘Group IT’ departments?, Steve
about/our-history/growth-share-matrix.aspx
Thair https://www.linkedin.com/pulse/what-future-central-
group-departments-stephen-thair/ 13. The Beyond Budgeting Principles
https://bbrt.org/the-beyond-budgeting-principles/
5. Good to Great, Jim Collins (2001)
14. Google re:Work Project Aristotle
6. From Project to Product, Mik Kersten (2018)
https://rework.withgoogle.com/guides/understanding-team-
7. Ecosystem Advantage, Peter Williamson and Arnoud De effectiveness/steps/introduction/
Meyer https://www.jbs.cam.ac.uk/fileadmin/user_upload/
15. Conway’s Law
research/workingpapers/wp1006.pdf
http://www.melconway.com/Home/Conways_Law.html
8. Why understanding your business ecosystem is the roadmap
16. Bruce Tuckman's group development model
for strategic growth, Rafael Armani https://www.linkedin.
https://www.mindtools.com/pages/article/newLDR_86.htm
com/pulse/why-understanding-your-business-ecosystem-
roadmap-strategic-armani/ 17. The Influence Of Organizational Structure On Software
Quality: An Empirical Case Study, Nachiappan Nagappan,
9. 2018 Accelerate: State of DevOps https://inthecloud.
Brendan Murphy, Victor R. Basili https://www.microsoft.com/
withgoogle.com/state-of-devops-18/dl-cd.html
en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf
30
31
 Accelerate your IT
Modernisation
We make Cloud, DevOps and Agile
adoption fast, secure and simple.

0800 368 7378 team@devopsgroup.com

@DevOpsGroup www.devopsgroup.com

32