Tag Archives: Culture

Leading experts bare all about the DevOps movement

The DevOps movement is rising, and an increasing number of IT professionals are keen to adopt this new way of working in order to achieve optimum collaboration between their Development and Operations departments. The ability to react quickly to customer demands is of top priority to businesses all over the world, and the benefits of DevOps is rapidly becoming widely known as offering fantastic business value.

Rackspace has released an Ebook and infographic, highlighting The DevOps Mindset: Real-World Insights from Tech Leaders to help you realise and implement your own DevOps practices within your organisation.

The Ebook shares valuable insights from practicing DevOps leaders with a key focus on outlining the need for enhanced collaboration, measurement and sharing through all aspects of any business. The DevOps Mindset showcases unique perspectives, challenges and achievements, as well as the catalysts which led them to adopt a DevOps mindset.

By successfully balancing the technical and social side of your development and operational processes you can actively learn and advance much quicker to help achieve your company goals. An unequal development of both sides will result in automation without collaboration and a lack of thought into exactly how your ideas and services will effectively be available to your customers.

DevOps advocate Jim Kimball, Chief Technology Officer at HedgeServ says: “I think the fundamental shift toward DevOps started when we got away from focusing on individual team goals and elevated our conversation to organizational goals and let the teams drive toward them.”

“To achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only. By pushing communication from the start, everyone gets a better feel for others’ needs and how they do their jobs.” Said James Kenigsberg, Chief Technology Officer at 2U, Inc.

This awesome Ebook shapes a Q&A format and delves deeper into how this new form of agile collaboration is sweeping its way through the software and IT industries.

You will also be able to take away useful tips for business leaders considering transforming their company culture towards a DevOps methodology.

We think this Ebook from Rackspace is a grade A piece, and an asset to anyone contemplating DevOps or thinking about adopting this innovative way of reaching new levels of productivity.

Recent Rackspace study shows businesses adopting DevOps practices at a remarkable rate

What do you think – is Devops just a fad or is it here to stay? Well, Rackspace recently commissioned independent technology market research specialist Vanson Bourne to conduct this piece of research and answer that very question. 700 global technology decision-makers were surveyed and the study discovered that businesses are now recognising DevOps as an established industry with adoption figures soaring at an extraordinary rate. Companies are now seeing significant business value in implementing DevOps as part of their own everyday practices.

So let’s look at the facts according to the Rackspace DevOps Adoption Study

What was previously recognised as a niche domain and implemented by only a select few, is now seeing widespread adoption and considerably transforming the way IT is viewed across a huge range of industries.

61% of those surveyed, highlighted customer satisfaction as the key incentive for DevOps adoption, enabling businesses to deliver better value to their customers through technology, and improve inefficiency to reduce delivery time to the customer.

While utilising DevOps practices and setting clear business goals at the beginning of every project, 57% saw an increased customer conversion or satisfaction rate.

The official Adoption Study infographic highlights 66% of respondents have already implemented DevOps practices, and 79% of those who have not, plan to do so by the end of 2015.

It is clear DevOps is increasingly being recognised as delivering real business value. A massive 93% reported setting clear end goals for their DevOps initiatives, showing a definite focus on significantly improving customer satisfaction for a long-term positive impact on the business as a whole.

In a nutshell – DevOps allows businesses to consider the ways in which they organise and structure their company to initiate better ways of working. It creates opportunities for businesses to deliver better experiences to their customers faster, broaden the range of services they offer and better serve their business by using data more proactively.

A big thank you to the Rackspace Adoption Study for these incredible figures. It’s fantastic to see this industry expanding so rapidly, and we’re looking forward to seeing what the future holds in this space.

The secret of #DevOps success isn’t in the IT literature (yet)!

Can you find “DevOps Success” by reading only IT literature?

The answer is “mostly No, but a little bit Yes”, for a number of reasons.

The main reason is that many of the blogs, whitepapers and webinars around DevOps are ultimately about technology and toolchains. Whilst they might reference the DevOps C.A.L.M.S model in passing the conversation is generally focussed on the A for Automation and the M for Metrics.

CALMS Model image
Culture Automation Lean Metrics Sharing

The seminal Phoenix Project did talk about organisational culture as did Mandi Wall’s O’Reilly ebook on Building a DevOps Culture.

But what both of those books have in common is that they drew extensively from non-IT business literature.

Goldratt’s “The Goal” & TOC, Systems Thinking, Lean manufacturing, Deming and Kanban being major influences on the Phoenix project, and Mandi’s e-book drawing on business-centric cultural/organisational change literature.

“Searching on the Harvard Business Review website for “cultural change” will get you 60+ publications going back nearly 30 years” – Mandi Walls

“Lean Manufacturing”, “Strategic Alignment”, “Organisational Change”, “Culture”, “Business Transformation” and many other topics have been staples of the MBA curriculum in business schools for many years and there is a wealth of resources available online to explore. Reading beyond the IT literature and exploring the wider business context for your DevOps Transformation will, we believe, significantly increase your chances of getting business buy-in and having a successful outcome to your DevOps change programme.

In order to make this easier for you we (@DevOpsGuys) will be publishing a weekly blog post exploring an area of business literature and how it can be used in DevOps.

We’re call it the #DevOpsMBA :-)

So please subscribe to our blog (link on right), follow us on Twitter or search for the #DevOpsMBA hashtag on Twitter to keep informed!

Why companies are investing in DevOps and Continuous Delivery

A thought-provoking infographic – with some interesting data points – shows how companies are reaping real rewards from investing in agile software delivery processes. Check out the graphic – from Zend – for more on how DevOps and Continuous Delivery are bridging the speed and innovation gap between business demand and IT.

Continuous Delivery Infographic by Zend Technologies.

Continuous Delivery Infographic

DevOps and the Product Owner

In a previous post we talked a lot about the “Product-centric” approach to DevOps but what does this mean for the role of the Agile “Product Owner”?

So what is the traditional role of the Product Owner? Agile author Mike Cohn from MountainGoat Software defines it thus:

“The Scrum product owner is typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed” – Mike Cohn

The definition above is very “project-centric” – the Product Owner’s role appears to be tied to the existence and duration of the project and their focus is on the delivery of “features”.

DevOps, conversely, asks us (in the “First Way of DevOps”) to use “Systems Thinking” and focus on the bigger picture (not just “feature-itis”) and the “Product-centric” approach says we need to focus on the entire lifecycle of the product, not just the delivery of a project/feature/phase.

Whilst decomposing the “big picture” into “features” is something we completely agree with, as features should be the “unit of work” for your Scrum teams or “Agile Software Development Factory”, it needs to be within the context of the Product Lifecycle (and the “feature roadmap”).

So the key shift here then is to start talking about the “Product Lifecycle Owner”, not just the Product Owner, and ensure that Systems Thinking is a critical skill for that role.

The second big shift with DevOps is that “Non-Functional Requirements” proposed by Operations as being critical to the manageability and stability of the product across its full lifecycle “from inception to retirement” must be seen as equally important as the functional requirements proposed by the traditional Product Owner role.

In fact, we’d like to ban the term “Non-Functional Requirements” (NFR’s) completely, as the name itself seems to carry an inherent “negativity” that we feel contributes to the lack of importance placed on NFR’s in many organisations.

We propose the term “Operational Requirements” (OR’s) as we feel that this conveys the correct “product lifecycle-centric” message about why these requirements are in the specification – “This is what we need to run and operate this product in Production across the product’s lifecycle in order to maximise the product’s likelihood of meeting the business objects set for it”.

We propose the term “Operational Requirements” (OR’s) as we feel that this conveys the correct “product lifecycle-centric” message about why these requirements are in the specification.

For the slightly more pessimistic or combative amongst you the “OR” in Operational Requirements can stand for “OR this doesn’t get deployed into Production…” .

The unresolved question is do we need an “Operational Product Owner” or does the role of the traditional, business-focussed Product Owner extend to encompass the operational requirements?

You could argue that the “Operational Product Owner” already partly exists as the “Service Delivery Manager” (SDM) within the ITIL framework but SDM’s rarely get involved in the software development lifecycle as they are focussed on the “delivery” part at the end of the SDLC. Their role could be extended to include driving Operational Requirements into the SDLC as part of the continual service improvement (CSI) process however.

That said, having two Product Owners might be problematic and confusing from the Agile development team perspective so it would probably be preferable if the traditional Business product owner was also responsible for the operational requirements as well as the functional requirements. This may require the Product Owner to have a significantly deeper understanding of technology and operations than previously otherwise trying to understand why “loosely-coupled session state management” is important to “horizontal scalability” might result in some blank faces!

So in summary a “DevOps Product Owner” needs to:

  • Embrace “System Thinking” and focus on the “Product Lifecycle” not just projects or features
  • Understand the “Operational Requirements” (and just say “No to NFR’s”!)
  • Ensure that the “OR’s” are seen as important as the “Functional Requirements” in the Product roadmap and champion their implementation

In future posts we’ll examine the impact of DevOps on other key roles in the SDLC & Operations. We’ve love to get your opinions in the comments section below!

-TheOpsMgr

image source: – CC  – CannedTuna via Flickr – http://www.flickr.com/photos/cannedtuna/7348317140/sizes/m/

DevOps and the “Product-centric” approach

When doing the research for our BrightTalk Webinar on DevOps I came across this quote from Jez Humble on “products not projects”, which really struck a chord with our thinking about what we call the “product-centric” approach to DevOps.

Products not Projects quotation

Figure 1 – DevOpsGuys BrightTalk Webinar

One of the key elements of DevOps is to ensure that IT strategy is directly linked with Business strategy.

One of the critical scenes in “The Phoenix Project” is where our hero Bill gets to meet with the CFO and they work through the list of “pet IT projects” in the organisation and find that many of them can’t really be tied back to any business strategy or organisational goal.

This is, we feel, one of the major problems with the “project-centric” view of IT and why we need to push for a “product-centric” view.

The “project-centric” view, whilst important for mobilising resources and organising activities, can easily get disconnected from the original business objectives. Any “Project”, just like the “Phoenix Project” in the novel, runs the risk of becoming its own “raison d’etre” as it becomes more about getting “the Project” over the line than whatever business benefits were originally proposed.

In contrast a “Product-centric” viewpoint is focussed on the Product (or Service) that you are taking to market. By keeping the focus on “the Product” you are constantly reminded that you are building a product, for customers, as part of an organisational objective that ties back to over-arching business strategy.

For example if you were in the travel sector you might be adding a new “Online Itinerary Manager” product to your website to enable your customers to view (and possibly update) their itinerary online as part of your business strategy to both empower customers online and reduce the number of “avoidable contacts” to your call centre (and hence reduce costs).

One of the other benefits of the “product-centric” view is also highlighted in Jez’s quote above – “From Inception to Retirement”.

The “product-centric” view reminds us to think about the “Product lifecycle” and not just the “software development lifecycle”.

The “product-centric” view reminds us to think about the “Product lifecycle”
and not just the “software development lifecycle”.

You need to understand how this product is going to be deployed, managed, patched, upgraded, enhanced and ultimately retired… and that means you need close cooperation between the business, the developers and operations (= DevOps!).

So how do you introduce the “Product-centric” view into an organisation that might already have existing website that offers products/services to customers?

Well, firstly, you need to stop referring to it as “the website”.

A “website” is a platform and a channel to market, it’s not a “product”.

A product is a good or service that you offer to the market in order to meet a perceived market need in the hope that you will in return received an economic reward.

For some “websites” there might be a single product e.g. Dominos sells pizza online (food products) and for other there might be multiple products e.g. theAA.com sells membership (breakdown services), Insurance, Financial Services, Driver Services (mostly training) and Travel Services. If you’re ever in doubt on the products your website sells your top navigation menu will probably give you a pretty good indication!

What Products does the AA Sell?

Figure 2 – what products does the AA sell?

It’s worth mentioning that the AA has another product too – the “RoutePlanner”. Although the route planner is “free” is has a value to the organisation both indirectly (by drawing traffic to the site that you might then cross-sell too) and intangibly (by offering a valuable service for “free” it enhances the brand).

Secondly, you need to identify the “product owners” for each of the core products that use your website as a channel to market, so in our AA example you’d probably have separate product owners for Membership, Insurance, Finance etc.

If you’re ever in doubt about who is, or isn’t, the right product owner then there is a simple test – “Do you have a significantly financial incentive (bonus) for Product “X” to succeed in the market?”.

The “Product Owner” Test:
“Do you have a significantly financial incentive (bonus) for Product “X” to succeed in the market?”

If the answer is “no” keep going up the hierarchy until you find someone who says “yes”. A product owner who doesn’t have any “skin in the game” regarding the success of their product line is a bad idea!

Thirdly, you need to work with the product owner to map out the product lifecycle of that product, and then identify the IT dependencies and deliverables at every stage along that product lifecycle. Within your product lifecycle you might also want to map out the “feature roadmap” if your product devolves into multiple features that will be released over time. Creating the “big picture” can be vital in motivating your teams and helping them to understand what you’re trying to achieve, and this in turn helps that to make better decisions.

Fourthly, you need to “sense check” your product lifecycle and feature roadmap against your business strategy and organisational goals. If they don’t align you either need to re-work the plan or you might decide to drop the product altogether and re-deploy those resources to a product that *IS* part of your core strategy.

Lastly you need to re-organise your DevOps teams around these products and align your delivery pipeline and processes with the product lifecycle (and feature roadmap). Your DevOps teams are responsible for the “inception to retirement” management of that product (*Top Tip – just like your “product owner” it might be a great idea to incentivise your DevOps teams with some “product success” (business) metrics in their bonus, not just technical metrics like “on-time delivery” or “system availability”. It never hurts for them to have some “skin in the game” to promote a sense of ownership in what they are delivering!).

So, to summarise, the key elements in a “product-centric approach” are:

(1)    Breakdown your “website” into the key “Products” (that generate business value)

(2)    Identify “Product Owners” with “skin in the game”

(3)    Map out the product lifecycle (and ideally feature roadmap) for each product with them

(4)    Sense check this product strategy with your organisational strategy

(5)    Align your DevOps teams with the core products (and incentivise them accordingly!)

So next time you’re in a meeting and someone proposes a new “Project” see if you can challenge them to create a new “Product” instead!

 

image source: - CC  - jeremybrooks via Flickr - http://www.flickr.com/photos/jeremybrooks/5401494223/sizes/s/

Is DevOps your defence against Shadow IT?

We’ve been evangelising DevOps quite a bit lately amongst customers and partners and one of the arguments that seems to resonant the most with people about why the current paradigm of IT Development and Operations is “broken” is around the rise of “Shadow IT”.

“Shadow IT is a term often used to describe IT systems and IT solutions built and used inside organizations without organizational approval. It is also used, along with the term “Stealth IT,” to describe solutions specified and deployed by departments other than the IT department.” – Wikipedia

“Shadow IT” is nothing new – it’s been around pretty much since the invention of the PC and client/server computing – but what is new is the speed and ease at which “Shadow IT” can be deployed, and the performance, reliability and stability of that “Shadow IT” solution.

“Sally from Marketing”, armed with nothing more than a company credit card, can instantiate an arbitrary number of servers, of varying capacity and specification, from a wide variety of Cloud hosting providers. Depending on the quality of the internal IT and her choice of Cloud provider it’s quite possible that she will get better uptime and performance from her Shadow IT solution than what she might get internally.

She can then find a 3rd software house to write some bespoke software (and then someone like DevOpsGuys to deploy and manage it… Oooopps!) and her “Shadow IT solution” is up and running (not to mention the many other SaaS solutions that she could consume).

shadowit

Figure 1 – DevOpsGuys – BrightTalk Webinar

In our recent BrightTalk webinar we spoke about how Gartner predicts that “Shadow IT” is expected to grow, and that there is some evidence (the PwC survey) that there is a negative correlation between “IT control” and organisational performance.

So, in summary, the traditional silo-mentality model of IT clearly isn’t meeting the customer’s needs for flexibility, innovation and time-to-market, and Cloud Computing is enabling the growth of “Shadow IT” on a scale never seen before.

To take a military analogy this is like the invention of highly mobile, mechanised “manoeuvre warfare” during WW II. The entrenched positions of the Maginot Line (think “traditional IT departments”) were rendered irrelevant by the “blitzkrieg” tactics (think “Shadow IT”) of the Wehrmacht as they simply bypassed the fixed fortifications with their more manoeuvrable, dare I say “agile”, mechanised infantry.

What is particularly fascinating, if Wikipedia can be believed, is that “blitzkrieg”, contrary to popular belief, was never a formal warfighting “doctrine” of the German Army (emphasis mine):

“Naveh states, “The striking feature of the blitzkrieg concept is the complete absence of a coherent theory which should have served as the general cognitive basis for the actual conduct of operations”. Naveh described it as an “ad hoc solution” to operational dangers, thrown together at the last moment”  – Wikipedia

An “ad-hoc solution” to operational dangers, thrown together at the last moment” is probably a pretty good definition of “Shadow IT” too but the important fact to remember is that Blitzkrieg worked (whether it was a formal doctrine or not). It crushed the opposition and subsequently became the cornerstone of modern military “combined arms” doctrine.

So, what’s this got to do with DevOps?

Well, clearly Gartner think that “Shadow IT” is working well too, and will continue to “outflank” traditional IT Departments.

Our view is that DevOps can be seen as the perfect defence to “Shadow IT” as it co-opts many of the key “manoeuvre warfare” concepts to provide the user with the speed, flexibility and time-to-market they want, but still within the control of IT to ensure standards, security and compliance.

DevOps, by breaking down the silos between Development and Operations, seeks to create unified cross-functional teams organised around specific objectives (ideally specific products that generate value for your organisation).

Compare this to the Wikipedia definition of “combined arms” doctrine” (bold emphasis mine):

“Combined arms is an approach to warfare which seeks to integrate different combat arms of a military to achieve mutually complementary effects (for example, using infantry and armor in an urban environment, where one supports the other, or both support each other). Combined arms doctrine contrasts with segregated arms where each military unit is composed of only one type of soldier or weapon system. Segregated arms is the traditional method of unit/force organisation, employed to provide maximum unit cohesion and concentration of force in a given weapon or unit type.”

Let’s paraphrase this for DevOps…

“[DevOps] is an approach to [IT Service delivery] which seeks to integrate different [technical silos] of a [IT Department) to achieve mutually complementary effects (for example, using [Development] and [Operations] in an [e-commerce] environment, where one supports the other, or both support each other). [DevOps] doctrine contrasts with [Traditional IT] where each [IT Team] is composed of only one type of [technical specialist] or [Technology] system. [Traditional IT] the traditional method of [team/department] organisation, employed to provide maximum [team] cohesion and concentration of [technical expertise] in a given [technology] or [team] type.”

That seems to be a pretty good definition of DevOps doctrine, to me!

The only true defence to “Shadow IT” is to offer a level of service that meets the internal customer needs for speed, flexibility and time-to-market they want. If they can get it “in-house” then the impetus to build a “Shadow IT” organisation is reduced.

The best way to deliver this level of service is, in our view, to adopt the lessons of Blitzkrieg and “combined arms” doctrine as embodied within DevOps by “integrating different teams… to achieve mutually complementary effects” and leveraging new technologies (like Cloud, APM and continuous delivery) to ensure ability AND stability.

image source: - CC  - faungg's via Flickr - http://www.flickr.com/photos/44534236@N00/2461920698