The 13th Principle: DevOps Takes an Extra Injection to the Agile Manifesto

Take a look at the 12 Principles Behind the Agile Manifesto and you may or may not notice a glaring Principle that is missing.  That Principle is this:

You MUST bring your awkward and distant cousin (a.k.a. IT Ops & Architecture) into the mix.

Let's be honest ... you see your distant cousin only as needed - maybe only a few times a year - so that means each time you have to spend the first 3 hours with uncomfortable "getting to know you again" chit-chat before you can get to the real meat of the family reunion.  That is, unless you keep them involved from the beginning, and throughout all stages of the SDLC, starting with business requirements gathering, you will always go through an uncomfortably awkward dance.

The question is "How do you propose we do that"?  

"I mean, they don't understand what we're trying to accomplish (and many times I question whether they even care), and they speak with a strong brogue of Klingon that makes it very challenging to communicate."

Some talk about creation of a Tiger Team made up of ... everyone.  Yes, everyone:  Dev, the LOB, IT Ops, Security and so on.  This "special forces" squad will challenge the way each group does what they do.  They will - through friction and osmosis - create empathy and understanding of the bigger picture, starting and ending with what the business is trying to accomplish, and filled in with agility, supportability, risk reduction, and consistency.  

SIDE NOTE:  If you haven't read The Phoenix Project, get on it.  Everyone in the org from top to bottom needs to have this perspective.  Hold a book review to ensure everyone gets it before endeavoring on any transformation.  My 2 cents.

Here's the main ingredient:  Executive backing and involvement.  Assuming your edict to "create DevOps" is going to result in a magical transformation is a fairy tail.  It will fail without your constant involvement and servant leadership.

And here's the main thing:  If you don't have a business reason to do DevOps, don't do it.  Doing DevOps because everyone else is, or because you just "think you should" is no way to begin.  So, think long and hard about what business (not just IT) outcome you are looking to accomplish before starting any effort.  For more on this, read the short book, Leading the Transformation.  It's chuck full of great guidance around establishing a strong and purposeful DevOps practice within your ranks.  

---

Greg Robert Dean is a Transformation Advisor in VMware's Software Defined Enterprise Business Unit.

The Tech Behind DevOps

There was a great article this week on IT World Canada called, "Why over 40% of IT departments are a DevOps nightmare" that discusses what I've been evangelizing to our customers:

"Automation is a key part of any DevOps project, and that must extend down to the infrastructure level, he warned."  

"He" being Ashish Kuthiala, senior director, marketing and strategy for DevOps at Hewlett Packard Enterprise.  Ashish continues:

“Set up automatic testing triggers upon code check-in, automate handoffs between teams, and carefully explore how to leverage automation to consistently deploy and configure your infrastructure,” he said. “Once something works well, codify it. Make it automated and repeatable so you can reduce errors, accelerate routine tasks, and ensure repeatability.”

As I've mentioned in previous posts - the tougher challenges come with people and processes, but technology to seamlessly automate your every repeatable task from Dev to Stage to UAT to Perf to Prod, etc, is equally critical.  Having common tooling for Automation that spans across the "wall" from Dev/Test to Day 2 Ops and back will make things oooohhhh so much easier.  Dealing with the same data, processes, and tools will facilitate process continuity as well as the new communication paradigm needed for DevOps to be a success.

Just like Electric Company.

To that point, the term "DevOps" itself comes with an obvious connotation - Dev is in IT's business and vice versa.  This has substantial benefits AS WELL AS many bumps and bruises to egos and communication constructs along the way.

Companies will have to decide, for example, how much development teams are to be involved in the provisioning process, now that all of the infrastructure suddenly speaks their language. And whoever pays the bills will have to negotiate policies on provisioning and usage of quickly-accessible resources. That’s a whole other layer of politics to contend with, before you even get to the fun stuff.

Here's the cool thing:  VMware has it figured out, having gone through the internal pains ourselves.  Once we topped off the transformation that was the "Journey to IaaS and PaaS", what was next?  Well, once you paint all the walls in the house, the floor boards now look dingy and scuffed.  The logical next phase was continuing upstream into the SDLC with pipeline release management via offerings like vRealize Code Stream.  Stay tuned for more on that.

---

Greg Robert Dean is a Transformation Advisor in VMware's Software Defined Enterprise Business Unit.

Only 1% of Automation Projects Succeed (a.k.a. 99% Fail)

To clarify, 99% of Automation projects fail, where automation software was purchased without some thought leadership services expertise from someone who has REALLY done it.

Sounds like a pitch for services (and to an extent, it is), but the point is not services revenue for your selected Automation software vendor.  The point is ...

it's about PEOPLE and PROCESS primarily

Working with VMware, for instance, you've been able to buy virtualization software and - for the most part - it's just worked without services and without much training.  But Automation is a whole other animal.  It touches every part of IT Ops, plus dev teams, plus IT finance, plus the business.  It touches all ITSM processes and Dev processes, and every person involved in those processes.  So, a plan that takes into consideration process recalibration and rationalization, plus regrouping and training of people, is critical. Then (and only then) should you apply technology to facilitate.

Don't get me wrong ... there is absolute benefit in creating an "Art of the Possible" stack in a lab that shows to all who will be involved what you are aiming for, but expecting that software will magically do it all in the medium and long term - getting you past broken or outdated processes and organizational behavior issues - is just crazy.

Here is a very high level depiction of what must be fleshed out, ideally with the help of experts in Application Delivery Automation:

ABOVE:  All of what must be considered when venturing toward an SDDC Transformation.

While this is a significant transformation to undertake, it is very well worth the effort.  According to a recent Forrester study on the Total Economic Impact of VMware Automated Application Deployment, for instance, 

• Application delivery was sped from 3-4 weeks on average to <1 day.
• Consistency and quality improved by a notable margin (not mentioned).
• HW cost avoidance was appr 15%.
• Reduced capacity was appr 10%.
• IT Ops time savings of appr 22 hours per application environment delivered.

What's more important, though, is the business impact:

• Improvements in developer productivity (20%+ for VMware internal)
• Significant market share and revenue increases (depends upon industry)
• Margin (Net Income) thickening
• Innovation through more IT time spent shoulder-to-shoulder with the business, trying out (and failing fast) edgy ideas to uncover potential advantages in the market.  This benefit can not be measured specifically, but it's the most substantial byproduct of this transformation by a wide margin.

In summary, before endeavoring to "change the IT world" - which is a noble and highly impactful venture - you will want to (a) get commitment to the change from Exec Management and heads of Dev and IT Ops, (b) begin considering the process and people aspects of the transformation that must transform (a la The Phoenix Project) and (c) partner with a company that has done this successfully many times over.  Of course, VMware is considered the best and most experienced, but there are many with specific practices in this arena who will do great things for you, too.

---

Greg Robert Dean is a Transformation Advisor in VMware's Software Defined Enterprise Business Unit.