Category Archives: Culture

B.F Skinner on #DevOps (circa 1985)

I came across this interview with one of the founding father’s of behavioural psychology, B. F Skinner, the other day and was immediately struck by the phrase below:

What’s needed is to give satisfaction back to people. It’s the difference, he said, between a craftsman who makes a complete chair and a person on an assembly line who makes only the legs. The craftsman’s work, Skinner said, is constantly reinforced by the process of seeing the chair take form, and finally of producing the finished chair. But the assembly-line worker sees only chair leg after chair leg — never the completed product.

Skinner is not advocating elimination of important modern advances, such as the assembly line. But he would like to see industrial engineers and psychologists continue to team up and produce better workplaces and better ways of working that will offer modern employees the psychological lift that the craftsman once felt.” B.F. Skinner interview

To me, this neatly encapsulates one of the central tenets of the DevOps movement – we want to “team up and produce better workplaces and better ways of working” that deliver simultaneously better value (faster) for our organisations AND  improve the morale and job satisfaction of Developers & Operations staff. 

We need to CARE about the “completed product” because we’re following the “First Way” of Devops and using systems thinking models to look beyond our silos and relentlessly focus on the big picture. 

 

CALMS MOdel

Is the S (Sharing) in CALMS Redundant?

@MLCarey321 asked a interesting question on Twitter the other day – is the S for Sharing in the CALMS model not redundant? If you have the right culture that emphasises collaboration & “no silos” surely “sharing” flows out of that? 

TwitterQuote

My view is that from a cultural perspective he’s probably right, a DevOps Culture definitely should encompass “sharing” as a core value so why do we need the extra S? 

CALMS Model of DevOps

I think that the extra S is there to emphasise that just having “sharing” as a core value isn’t enough – you need to actively put in place mechanisms to promote, facilitate and reward sharing at multiple levels

For example here at DevOpsGuys we:

  1. Heavily use Atlassian Confluence as a wiki for documentation and documentation is seen as a “living thing” that must be kept up to date because it has value to the team every day.
  2. Use HipChat for informal communication, “What am I doing now”, “Does anyone know something about topic xyz” etc. HipChat is also integrated with JIRA, PagerDuty, CI/CD. 
  3. JIRA Kanban boards for sharing “this is what the team / individual is working on how”, plus time-tracking and work status. 
  4. All of the 3 above are also accessible by the clients – so sharing means “sharing with the customer” too, not creating an “us&them” silo. 
  5. Blogging and presenting to share with the community is strongly encouraged and we’ve started a meetup group DevOps Cardiff (in addition to London Web Performance that I’ve run for 3 years)
  6. Our GitHub repo is a bit sparse at the moment but we hope to open-source some stuff in the future, particularly some samples around Powershell DSC

As we grow and we bring on more grads & apprentices everyone will be paired with a senior mentor to ensure that skills & experience are shared across team, and we’ll start doing weekly “brown-bag” session to further share knowledge.

One area we haven’t looked at yet is explicitly promoting sharing via an incentive/bonus scheme based on “# blog posts” or “# open source commits” or “StackOverflow Reputation“, mostly because I’ve never seen it work successfully in previous organisations in which I’ve worked.

That’s not to say it can’t work… but you have to think about it very carefully or otherwise you risk incentivising the wrong behaviour. My feeling at the moment is that this will remain “ad-hoc” when someone shares “something cool” or gets accepted to speak at a conference or something.

How do you promote, facilitate and reward sharing in your organisations? 

What does DevOps look like in UK job ads

#DevOps – Organic versus Transformational DevOps

Despite what some people seem to think there is more to DevOps than just Continuous Delivery and Infrastructure Automation with Puppet, Chef or Ansible.

To me, DevOps is “an alternative model for the creation of business value from the software development life-cycle that encompasses a product-centric view across the entire product life-cycle (from inception to retirement) and recognises the value in close collaboration, experimentation and rapid feedback”.

Moving from one model of value creation can either be an organic process or a transformational one – you can “grow into” the new model or you can plan a strategy of change to transform your organisation from one to the other.

It’s in this “Organic DevOps” versus “Transformational DevOps” that I see a growing disconnect between different sectors of the DevOps community, particularly between “DevOps for Start-ups” and “DevOps for Enterprise”.

IMHO, “Start-Ups DevOps” normally follows the “organic DevOps” path – you’re often starting from a relatively “greenfields” approach based on a cloud infrastructure. You probably already have a very close, collaborative culture because there’s only 20 of you anyway and you all work in the same office and you spend 18hrs a day there. Automation is part of your DNA because you’ve never had the staffing levels to do it manually.

“Enterprise DevOps” is normally “Transformational DevOps” – you have large, distributed IT teams that cross geographic locations, time-zones and probably organisational boundaries (due to outsourcing). You have extensive legacy applications and infrastructure estates (JVM 1.4 on Tomcat 5 anyone?) and you’re likely to have well developed Prince2/ITIL/SixSigma delivery models rigidly enforced by a centralised command&control mindset, backed by an army of highly-paid consultant from the Big 5 telling your CEO, CIO and CTO the best way to manage their IT budget.

Moving an enterprise to DevOps via a transformation programme is a very different challenge to introducing DevOps concepts into a receptive start-up and watching them grow organically, and the DevOps community needs to make sure that when it’s evangelising DevOps to the world that it’s aware of the differences and challenges inherent in each approach.

If you want to debate this idea of “Start-up Organic versus Enterprise Transformational DevOps” we’re taking part in a Webinar tonight with the great folks over at ScriptRock that’s focussing on Enterprise DevOps. It’s at 1900 BST,  11:00am PT / 2:00pm ET (60 minutes).

We’d really like to get your thoughts on this by asking a question on the webinar or by leaving a comment below as these concepts are still experimental and, just like DevOps itself, the faster we get feedback and the more we iterate around the concept the stronger it will be!

http://info.scriptrock.com/devops_webinar-2

Enterprise DevOps Webinar
Enterprise DevOps Webinar

 

 

A scientific basis for #DevOps success?

A fascinating TED talk from “Predictably Irrational” author Dan Ariely has some interesting pointers to some of the underlying psychological mechanisms that make the DevOps model a better way to structure work within IT departments.

“we care much more about a product if we’ve participated from start to finish rather than producing a single part over and over.”

The accompanying article lists 7 insights into our motivations when performing tasks (and the research that supports those insights).

  1. Seeing the fruits of our labour may make us more productive
  2. The less appreciated we feel our work is, the more money we want to do it
  3. The harder a project is, the prouder we feel of it
  4. Knowing that our work helps others may increase our unconscious motivation
  5. The promise of helping others makes us more likely to follow rules
  6. Positive reinforcement about our abilities may increase performance
  7. Images that trigger positive emotions may actually help us focus

Many of these tie directly back to key DevOps principles.

For example the “First Way of DevOps” encourages “systems thinking” which relates directly to #1 above – if we are looking at the entire system (not just our small part) we will inherently be looking at the “fruits of our labour”.

Similarly fostering a team-based DevOps culture where we can see “how our work impacts on others” is closely aligned with #4.

For me, #2 and #6 tie directly back to “leadership” (as opposed to “management”). Good leaders know that praise (either private 1:1 praise with individuals or public praise in front of the team) can have a huge impact on morale, with a subsequent impact on productivity and quality.

It’s fascinating to see how behavioural science is increasing our understanding of human motivation. The challenge for us in the DevOps movement is to take these science-based insights and see how we can apply them with our teams to create a better way of working.

DevOps 101 for Recruiters

We put together this “DevOps Intro” to the recruitment team at a London recruitment consultancy to help them understand the DevOps Market place.

The goal was to help them understand both the WHY and the WHAT of DevOps and what that might mean for recruiters.

Hopefully you will find this interesting as well!

7348317140_e30eeda034

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/

5401494223_e339c6425a

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/