2013 G. Philip Rogers & Dr.

Ahmed Sidky 1
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana
ITILity: Delivering Business Value via the Nexus of Lean-Agile and IT Service Management
G. Philip Rogers, Enterprise Agile Coach, Santeon Group
Dr. Ahmed Sidky, Principal Consultant, Sidky Consulting Group

Abstract
The delivery of business value is a seminal function that can and should drive decision-making associated with IT
portfolio management and service delivery. All too often, however, those working in software development find
themselves at odds with staff working in IT operations. The good news is that there have been some encouraging
trends and significant success stories in which software development and operations functions are finding ways to
collaborate more effectively, even in large and complex organizational contexts. In fact, even though it might seem
that the need to react rapidly to shifting business priorities, which are often manifested via frequent software
deployments, runs directly counter to the delivery of stable and predictable IT services, a growing number of
organizations are proving that development and operations functions can partner effectively.
This paper seeks to show how lean-agile development, which is increasingly common in the software development
community, is at its core, driven by values and principles, along with a customizable set of practices, which align
very nicely with the principles and practices of IT Service Management (ITSM) and the IT Infrastructure Library
(ITIL), which are so prevalent among operations practitioners. The authors of this paper are thus coining the term
ITILity to represent the nexus of agility and ITSM/ITIL. Finally, and most importantly, this paper provides insight
into how IT can help organizations achieve the business outcomes they wish to achieve, by leveraging the best that
lean-agile software development and ITSM have to offer.
Examining the Sources of Conflict between Software Development and IT Operations
The relationship between software development teams, which focus on creating and modifying software, and IT
operations groups, which have responsibilities that include deployment of software packages to production
environments is often contentious. For instance, to look at things from an IT operations perspective, operations
teams are evaluated largely on the extent to which the systems they manage are stable. Given this fact, it is
understandable that there is a desire to restrict deployment of software to a production environment as much as
possible, to avoid the instability that is so often associated with software releases (Humble & Molesky, 2011, p. 6).
Organizations are discovering ways to make the relationship between software development (Dev) and operations
(Ops) much less contentious, and a term that is often used to describe this evolving relationship is DevOps. This
paper seeks to provide further evidence that it is not only possible to bridge the perceived divide between the Dev
and Ops communities, but also to show how their shared interest in the delivery of business value makes Dev and
Ops natural allies.
One of the changes in the IT industry that is prompting organizations to change their perspective on the DevOps
relationship is a shift from traditional software development approaches, based on a phase-based, or waterfall
model, to agile software development. In sharp contrast to waterfall development, which for larger implementations
tends to produce working software relatively infrequently, agile software development makes it possible to deliver
working software much more rapidly, and at a predictable cadence. Although from a business perspective the rapid
delivery of software may seem like a good problem to have, from a technical perspective, frequent deployments of
software to production environments find many organizations unprepared for such a profound shift in their internal
operations.
A number of people got together and started a grass-roots movement that set out to remove the
traditional boundaries between development and operations. Some consider this picking up where
traditional agile left off. After all, software doesnt bring value unless it is deployed in production;
otherwise, its just inventory. To tackle the problem, devops encourages cross-silo collaboration
constantly, not only when things fail. (Debois, August 2011, p. 3)

2013 G. Philip Rogers & Dr. Ahmed Sidky 2
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana
An Introduction to Agile, Lean, and IT Service Management
This section introduces the mindset, values, principles, and practices associated with agile software development,
lean software development, and IT Service Management, respectively. Before introducing each of these three
approaches, it is important to first distinguish between principles and practices. Principles are underlying truths
that dont change, while practices are the application of principles to a particular situation (Poppendieck &
Poppendieck, 2007, p. 19). The Poppendiecks go on to suggest that a learn-by-doing approach is very important, in
that applying a particular set of practices helps organizations better understand the underlying principles (along with
the mindset and values) behind those principles.
To state the difference between principles and practices in more familiar terms, principles focus on why an
organization does something, whereas practices focus on how an organization takes action to realize those
principles. Far too often, organizations focus the majority of their energy on how they are doing something, and lose
sight of why they are doing what they are doing. Exhibit 1 illustrates the relationship among Agile Values,
Principles, and Practices (Smith & Sidky, 2009, p. 6).

Exhibit 1 Agile Values, Principles, and Practices
As with so many areas of human endeavor, the key is to strike a balance between the why and the how, between the
strategy (values and principles) and the execution (practices). It should not come as a surprise, therefore, that the
most successful organizations are those able to find such a balance.
Overview of Agile Software Development
One of the most common impediments that can cause an organization to not be able to realize the full potential of
agile software development is what many refer to as the difference between doing agile versus being agile. An
interesting way to look at the difference between doing agile and being agile is to see the value of a project as why
divided by how (value =why/how). Suppose that an organization has adopted a variety of agile practices, without
taking the time to articulate a vision regarding what they expect to gain by adopting those practices. Since it is hard
to argue that the numerator (the why) in such a situation is a non-zero value, no matter how many practices the
organization might adopt, they are unlikely to realize any significant gains from their adoption of those agile
practices, because zero divided by ten is no different than zero divided by fifty (Hanoulle & Linders, 2012, 3).
One might argue that representing complex organizational dynamics in terms of such a simple mathematical formula
fails to take into account the many factors that are at work in such situations. To make such an argument is to miss
the pointthat organizations focusing excessively on the how are doing agile, without being agile. In other words,
such organizations fail to manifest an agile mindset. As Steve Vaughn points out (2013, 1), the agile mindset needs
to be central to an organizations culture. The centrality of the importance (and difficulty) associated with
organizational change is borne out by the results from VersionOnes State of Agile Development Survey, which in
addition to providing data about the many agile success stories, also shows that the most significant barrier to further
agile adoption is the ability to change organizational culture (VersionOne, 2013, p. 7).
2013 G. Philip Rogers & Dr. Ahmed Sidky 3
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana
Returning to the DevOps relationship, which is so central to this paper, for organizations considering an agile
transformation consider the difference in terms of the likelihood of success between an organization that takes the
time to do a proper assessment of its culture, its values, and its principles, versus an organization that makes no such
effort. In the former case, it would be typical for a broad spectrum of stakeholders to be involved in the planning,
design, implementation, and continuous improvement of the agile transformation initiative, and those stakeholders
would most certainly include individuals representing various business functions, along with staff working in
software development and IT operations roles. By way of contrast, in the latter case, where an organization rushes
into an agile transformation, it is all too frequent an occurrence that key stakeholders, including those in IT
operations, are not adequately consulted, often with disastrous consequences. To put it in more concrete business
terms, IT organizations that fail to confront and reconcile the widening gap between their development and
operations teams stand to lose their footing in todays competitive business environment (Orr, 2012, p. 1). The fact
is, in organizations where an agile transformation not only survives but thrives, the agile mindset, values, and
principles span the entire organizational value stream, from concept to cash.
Exhibit 2 shows the nature of the cyclical relationship among business stakeholders (application owners), the
software development function, and the IT operations function.

Exhibit 2 The DevOps Cycle
This simple diagram is also a good metaphorical representation of the four agile values, as articulated in the Agile
Manifesto (Beck et al., 2001). The four values are: Individuals and interactions over processes and tools; Working
software over comprehensive documentation; Customer collaboration over contract negotiation; and Responding to
change over following a plan. Imagine how well such a cycle would work if there were insufficient interaction and
collaboration among the parties involved, or if they did not all see the delivery of working software as important.
These four values, along with twelve principles (which constitute the second part of the Agile Manifesto), must be at
the very core of every agile initiative, regardless of which set of practices an organization decides to adopt. In other
words, an agile mindset is needed for an organization to be agile, as opposed to just doing some agile practices
without the accompanying mindset, values, and principles.
Overview of Lean Principles and How They Apply to Software Development and IT Operations
J ust as with agile software development, lean software development too places great importance on the values and
principles of an organization. Principles drive behavior and behavior determines results. Most change programs
start from actions and the results begin and end there. But if you want sustainable results, the only way is to get
principles and behaviors right. Sustainable lean change has to work at the principles and behaviors level
Flinchbaugh, 2012, p. 17).
One of the lean tools that organizations sometimes use is called the five Ss. The Ss represent five J apanese
words that start with an S. Exhibit 3 shows an interesting application of the five Ss to J ava software, based on an
email exchange between Kent Schnaith and Mary and Tom Poppendieck (Poppendieck & Poppendieck, p. 192).

2013 G. Philip Rogers & Dr. Ahmed Sidky 4
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana

Action Result
Sort (Seiri) Reduce code base size by removing unnecessary items such as dead code and
unused imports, variables, methods, and classes.
Systematize (Seiton) Organize projects and packages to reduce or eliminate package dependencies.
Shine (Seiso) Clean up code to address unit test failures, improve unit test coverage and
performance, and address warnings generated by code analysis tools.
Standardize (Seiketsu) Continue to reduce complexity to make the code base easier to maintain.
Sustain (Shitsuke) Follow standard procedures with the ultimate goal of making the first four Ss
unnecessary.
Exhibit 3 The 5 Ss for Java
Shifting focus to another Lean principle, a concept that is relevant to those working in both software development
and IT operations, is the need to keep batch sizes as small as possible. To start with a reasonably simple definition,
batch size is synonymous with the size of a software module or similar work product that moves from one
environment to another. Thus, every time a developer checks in code, they are batching a certain amount of work.
Lean-agile software development employs various practices to keep batch size reasonably small, such as Continuous
Integration (CI), where relatively small sets of changes are run against a set of tests that ensure build integrity is
maintained. Some of the benefits of smaller batch size and CI include faster feedback to developers, keeping any
problems that do occur localized, and reduced code integration risk, all of which benefit parties involved with
software development and deployment (Ries, 2009, 27).
Stated slightly differently, CI is an excellent illustration of how lean and agile concepts, when used in combination,
can produce superb results. And, CI can benefit both software development and IT operations staff, in the former
case by catching defects early, along with making the build process more robust, and in the latter case by making it
easier to migrate software from one environment to another in a much more predictable fashion. In lean thinking
terminology, CI replaces big batches and long cycle times of integration (the practice of traditional configuration
management) with small batches and short cycles of integrationa repeating lean theme (Larman & Vodde, 2008,
p. 182).
To sum up this short section on lean software development, as with agile, there are many lean success stories. And,
just as it is with agile, successful lean implementations tend to follow certain patterns. Lean inherits ideas from the
world of manufacturing to drive efficiency and effectiveness, ideas that are particularly relevant in IT operations.
Lean ideas can work very nicely in tandem with agile, given its strong alignment with the thought processes and
work patterns associated with software development. What is really behind companies that succeed at sustained
lean implementation is the level of thinking driven by lean principles and rules. Thinking is powerful in changing an
organization. Thinking drives behaviors. Behaviors drive action. Action drives results. (Flinchbaugh, 2012, p. 4)
Overview of ITSM and ITIL
At its most basic level, the main purpose of ITSM is to make sure that IT services both align with and can reliably
support the business needs of an organization. As stated in the IT Service Management Forum (itSMF) introductory
guide to ITIL Version 3 (Cartlidge et al., 2007, p. 5), It is imperative that the IT services underpin the business
processes, but it is also increasingly important that IT acts as an agent for change to facilitate business
transformation. ITIL is the most common wrapper, or framework, for ITSM. ITIL seeks to make it possible to
continually measure and improve the quality of the IT services that are delivered.
ITIL Version 3 consists of five core books that are intended to represent the five major stages of the life cycle of an
IT Service, as shown in Exhibit 4. The life cycle begins with definition of the service and analysis of business
requirements (during the first two stages, service strategy and service design), continues with migration into a
production environment (the service transition stage), and then on to service operation, support, and continuous
improvement (which are the areas of focus during the service operation and continual service improvement stages).
2013 G. Philip Rogers & Dr. Ahmed Sidky 5
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana

Exhibit 4 The Five Stages in the IT Service Lifecycle (ITIL)

To close this short section on ITSM and ITIL, two primary characteristics that are associated with IT services fit
for purpose and fit for use are tremendously important in both lean-agile software development circles and
among IT operations staff.
[An IT service] should be fit for purpose in other words, it should deliver the expected value to
users in terms of functionality, and it should be fit for use, which means it should be production-ready
in terms of meeting capacity, availability, and security characteristics. Poor collaboration between
developers, testers and users results in software that is not fit for purpose. Poor collaboration
between developers, testers and operations leads to software that is not fit for use. Bureaucratic
change management processes that are put in place to reduce the risk of releases often create silos
that further inhibit collaboration. Delivering software is an inherently collaborative exercise, so it
should come as no surprise that effective release management of software that is both valuable and
production-ready requires organizational change to enable collaboration between everybody involved
in delivery. (Humble, 2010, pp. 23)
Comparing ITSM Activities with Lean-Agile Activities
To set the stage for a comparison of ITSM processes and practices with lean-agile practices, here is a brief review of
lean, agile, and ITSM values and principles: (1) Agile begins with a mindset, reinforced by a core set of values and
principles, along with a customizable set of practices, where a customer is actively involved with software
development teams that produce releasable, valuable software on a frequent basis; (2) Lean places emphasis on
optimizing end-to-end processes to create customer value, with particular focus on the flow of work product, along
with removing bottlenecks wherever they exist in a process, and streamlining wasteful activities, and; (3) ITSM
enables IT service providers (IT operations in particular) to align the IT services they provide with the
organizations business objectives and thereby work with their business partners to define parameters such as critical
success factors (CSFs) and key performance indicators (KPIs) associated with each IT service.
Having touched upon the key values and principles associated with lean, agile, and ITSM, a shift in focus to the
practical application of these values and principles via processes, activities, and practices is now in order. Exhibit 5
compares the key processes and activities associated with ITIL service life cycle stages with lean-agile practices and
activities. Process and activities associated with the following three ITIL service life cycle stages are included in the
table*:
Service Transition. The IT service life cycle phase that begins with the deployment of Configuration Items
(CIs), such as code, configuration files, and scripts, to one or more pre-production environment, and ends
with the deployment of those CIs into the production environment.
Service Operation. The IT service life cycle phase that focuses on ensuring that IT services conform to
Service Level Agreements (SLAs) and/or other types of agreements as agreed on with stakeholders.
2013 G. Philip Rogers & Dr. Ahmed Sidky 6
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana
Continual Service Improvement. The IT service life cycle phase that focuses on making ongoing
improvements, both for IT services as well as the processes underlying the ITSM service life cycle.
Exhibit 5 Comparison of ITSM Processes/Activities with Lean-Agile Practices/Activities
ITSM Process/Activity ITSM Process/Activity
Description
Related Lean-Agile
Practice/Activity
Service Transition
Change Management Follow standard procedures for
introducing changes to IT services
Continuous Integration; Incremental
deployment; Definition of Done;
Collaborative planning; Seeking
feedback
Service Asset and Configuration
Management
Keep track of configurations and other
information for IT assets
Continuous Integration; Single code base
Knowledge Management Improve the quality of decision making
by ensuring information is stored in and
accessible via one or more repositories
Create knowledge; Collaboration;
Communication; Informative workspace
Transition Planning and Support Identify an approach for securing
resources and managing issues and risks
associated with the release of an IT
service
Sort (Seiri); Systematize (Seiton); Shine
(Seiso); Weekly cycle
Release and Deployment Management Follow standard procedures for
introducing changes to production and
other controlled environments
Release Planning; Release Management;
Agile Release Train
Service Validation and Testing Test IT services before they are
deployed to a production environment
Coding standards; Test-Driven
Development; Test-first development;
Unit tests; Acceptance tests; Integration
tests
Evaluation ConfirmIT services are ready to be
deployed to a production environment
Hardening sprint; incremental
deployment; Test automation
Service Operation
Event Management Monitor the health of IT assets, generate
information about events, log events,
create event notifications
Optimize the whole; Andon
Incident Management Address (fix) issues with IT assets that
require immediate resolution
Frame the problem; Look for the root
cause; Propose a countermeasure;
Implement the countermeasure; Verify
the results
Request Fulfillment Satisfy authorized requests for IT
services (service requests)
Deliver fast
Access Management Grant authorized users the right to use an
IT service, and deny unauthorized users
the right to use an IT service
Make policies explicit; Chartering;
RACI matrix
ProblemManagement Triage issues with IT assets and either
defer, deploy work-around, or fix
Frame the problem; 5-why analysis
Continual Service Improvement
7-step Improvement Process Follow a consistent process to improve
an organization over time
Build quality in; Eliminate waste;
Implement feedback loops; Kaizen;
sprint retrospective
Service Measurement Establish baselines for IT services to
ensure reports provide value
Corrective action matrix; Histogram;
Pareto chart; Trend chart
Service Reporting Provide reports on operational and
strategic topics related to IT services
A3 report
* Three of the five ITIL service life cycle stages are included in the table because it is these three stages that focus
on the transition of a service to a production environment, the support of that service while it is in production, and
the continuing need for an organization to identify opportunities for improvement in these and other process areas.


2013 G. Philip Rogers & Dr. Ahmed Sidky 7
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana
DevOps Patterns and Anti-Patterns
Exhibit 6 describes things that have been proven to work (patterns) and things that experience has shown do not
work (anti-patterns) in a DevOps context. In other words, the patterns represent behaviors that contribute to a
healthy DevOps relationship.
Exhibit 6 DevOps Patterns and Anti-Patterns *
Pattern Anti-Pattern
Automatically create a catalog as part of the build
process that describes application configuration options.
Allow information about application configuration
options to be undocumented.
Apply changes that are committed to the mainline code
base to each branch at least once a day.
Merge the code infrequently or only when requested.
Commit all source files (executable code, configuration
files, data) to the version control repository.
Commit only files that can be recreated through the
build and deployment process.
Run a single command that checks out a projects
version control repository and deploys to any accessible
environment.
Require the definition and configuration of environment
variables and the installation of one or more tools as part
of the deployment process.
Fail a build upon detection of a violation of a project
rule.
Rely only on manual code reviews to catch
discrepancies from coding standards.
Initiate building and testing of software upon each
change that is committed to the version control
repository.
Execute builds on an ad hoc basis, only on developer
machines, or not at all.
Fix software delivery errors as soon as they are detected
and do no check-ins on a broken build.
Enable an environment where builds stay broken for
long periods of time.
Automate as many unit, component, functional, and
deployment tests as possible.
Rely primarily or exclusively on manual testing.
Use transactions for tests with data dependencies, roll
back the transactions when done, and use only enough
data to test the desired behavior.
Use a copy of production data or a shared database for
tests with data dependencies.
Use mocking frameworks or stubs to simulate
interactions with external systems.
Manually install and configure systems to support
testing.
Agree on a common scripting language so that any team
member can apply changes to fix problems.
Leave it to individual discretion to decide which
scripting languages to use.
Release software to production for a subset of users to
get feedback prior to a complete production deployment.
Release software to production for all users at the same
time.
Deploy software to a pre-production environment while
the production environment continues to run; then
switch non-production to production (and vice versa)
simultaneously.
Take down the production environment while software
deployment is in progress.
Set up an automated, single-command rollback of
changes in the event of an unsuccessful deployment.
Manually undo changes made during a failed
deployment, shutting down production environment(s)
while the changes are undone.
Automate the process of provisioning and configuring
the environment, including networks, external services,
and infrastructure.
Require partially manual or completely manual
provisioning and configuration of the environment.
Configure lower environments to either exactly match or
very closely match the production environment.
Configure lower environments manually and defer
making them match the production environment until
just before deployment.
* Duvall, 2010.


2013 G. Philip Rogers & Dr. Ahmed Sidky 8
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana
Conclusion
There is no better illustration of the importance of the Dev-Ops relationship to the health and well-being of an
organization than the story that is told in The Phoenix Project (Kim, Behr, & Spafford, 2013). The story begins with
an organization that is clearly in trouble, beset with financial problems and organizational dysfunction, with a high
degree of conflict among business and IT stakeholders. Given this backdrop, a mid-level IT manager suddenly finds
himself in very senior position where he is given a mandate (more of an ultimatum, really) to address many of the
organizations most dire problems. During his early days in the new position he discovers just how central a healthy
Dev-Ops relationship is to being able to make the sort of improvements he has been asked to make. Kim, Behr, and
Stafford not only tell a fascinating story, they describe realities that they have observed in many different
organizations, and even more importantly, they illustrate that it truly is possible for an organization to realize the
benefits of lean-agile software development along with ITSM, and to build a healthy, collaborative relationship
among those in software development and those in IT operations that works to the benefit of the organization as a
whole.
When it comes to realizing the benefits of lean-agile software development, some of the more obvious benefits
include faster development of features and an environment which fosters innovation. But it is important not to lose
sight of the most important benefit, which is the ability to rapidly deliver business value, in whatever form business
value might be realized for an organization. When viewed from the perspective of one of the most critical
manifestations of business value delivery competitive advantage organizations that practice lean-agile
software development and that have the ability to quickly and inexpensively evolve a product closest to the end
of the development lifecycle will have a tremendous competitive advantage. Ultimate customer value is delivered at
the point-of-sale, not the point-of-plan (Highsmith, 2010, p. 8). It is well within the grasp of any organization to
build a foundation of collaboration and trust that enables those in software development to partner with those in IT
operations to the mutual benefit of everyone in the organization.
In conclusion, although there are numerous examples of contentious DevOps relationships, there is no reason that
teams pursuing agile software development inherently have to be in conflict with IT operations. To successfully
create the significant breakthroughs in your development effectiveness that are possible with agile, it has to be
aligned with why you want to do it in the first place and what you need to achieve from it. You should be agile not
just to be agile, but to drive the business results. (Gruver, Young, & Fulghum, 2012, p. 9)

2013 G. Philip Rogers & Dr. Ahmed Sidky 9
Originally published as part of the 2013 PMI Global Congress Proceedings New Orleans, Louisiana
References
Beck, K., et al. (2001). The Manifesto for Agile Software Development [Online]. Retrieved from
http://www.agilealliance.org/the-alliance/the-agile-manifesto/.
Betz, C. (2007). Architecture and Patterns for IT Service Management, Resource Planning, and Governance:
Making Shoes for the Cobblers Children. San Francisco, CA: Morgan Kaufmann.
Cartlidge, A., et al. (2007). An Introductory Overview of ITIL V3, version 1.0 [Online]. Retrieved from
http://www.itsmfi.org/files/itSMF_ITILV3_Intro_Overview.pdf .
Debois, P. (August 2011). "Opening Statement," Cutter IT Journal, vol. 11, no. 8, pp. 35 [Online]. Retrieved from
http://nobelium.se/itj1108.pdf.
Duvall, P. (2010). Continuous Delivery: Patterns and Antipatterns in the Software Lifecycle, DZone refcard #145.
Retrieved from http://refcardz.dzone.com/refcardz/continuous-delivery-patterns.
Flinchbaugh, J ., (2012). A3 Problem Solving: Applying Lean Thinking. Vancouver, British Columbia: Leanpub.com
(Ruboss Technology Corporation). Retrieved on from https://leanpub.com/a3problemsolving.
Gruver, G., Young, M., & Fulghum, P. (2012). A Practical Approach to Large-Scale Agile Development: How HP
Transformed LaserJet FutureSmart Firmware. Upper Saddle River, NJ : Addison-Wesley.
Hanoulle, Y., & Linders, B. (Dec. 28, 2012). Interview with Yves Hanoulle on the Agile and Lean Mindset
[Online]. Retrieved from http://www.infoq.com/articles/agile-lean-mindset.
Highsmith, J . (2010). Agile Project Management: Creating Innovative Products, 2nd Edition. Upper Saddle River,
NJ : Addison-Wesley.
Humble, J . (2010, 14 J uly). Agile Release Management: Towards Frequent, Low Risk Releases [Online]. Retrieved
from http://www.kn-portal.com/fileadmin/xxx/AgileReleaseManagement-whitePaper.pdf.
Humble, J ., & Molesky, J . (August 2011). "Continous Delivery," Cutter IT Journal, vol. 11, no. 8, pp. 6-12
[Online]. Retrieved from http://nobelium.se/itj1108.pdf.
Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A Novel About IT, DevOps, and Helping Your
Business Win. Portland, Oregon: IT Revolution Press.
Larman, C., & Vodde, B. (2008). Scaling Lean & Agile Development: Thinking and Organizational Tools for
Large-scale Scrum. Upper Saddle River, NJ : Addison-Wesley.
Orr, A. (December 2012). Maximize the Synergies between IT and DevOps [Online]. Retrieved from
http://documents.bmc.com/products/documents/52/40/435240/435240.pdf.
Poppendieck, M., & Poppendieck, T. (2007). Implementing Lean Software Development: From Concept to Cash.
Upper Saddle River, NJ : Addison-Wesley.
Ries, E. (February 20, 2009). Work in small batches, Startup Lessons Learned [Online]. Retrieved from
http://www.startuplessonslearned.com/2009/02/work-in-small-batches.html.
Smith, G. & Sidky, A. (2009). Becoming Agile in an Imperfect World. Greenwich, CT: Manning.
Vaughn, S. (May 31, 2013). Putting into Practice an Agile Mindset [Online]. Retrieved from
https://www.techwell.com/2013/05/putting-practice-agile-mindset.
VersionOne (2013). The Seventh Annual State of Agile Development Survey [Online]. Retrieved from
http://www.versionone.com/state-of-agile-survey-results/.