It's a New and Exciting 2015!

Happy New Year!  And an exciting new year it is going to be. 2015 promises to be a transformative year where the next generation of IT capabilities become reality in order to meet the rising needs of a rapidly changing business landscape.

First step - a new, intuitive and interactive website!  If you haven't been there lately, come visit us at www.itsmacademy.com.  It's beautiful!

Along with an updated website, we will be updating our service portfolio with emerging and relevant topics such as Agile, DevOps and Cyber.  Each of these practices enhances some aspect of  IT's ability to deliver ongoing and sustainable customer value    None are perfect, none are complete and none supercede or obsolete the other.   Together, they form a holistic matrix for managing services in a modern world.  And of course ITIL and ITSM play a key role in all.

Available now:

• ITIL Foundation, Intermediate and MALC 
• DevOps Foundation 
• Certified ScrumMaster 
• Certified Agile Service Manager (CASM)
• Certified Process Design Engineer (CPDE)
• Overviews and non-certification workshops

Coming in 2015

• Cybersecurity
• Prince2 Project Management
• Lean IT
• Knowledge centered support
• Much more

Axelos will also be introducing a Continuing Professional Development (CPD) scheme to help ITSM professionals keep their knowledge current and establish a career path based on their current or desired role.  We are thrilled that we will be one of the first organizations to work with them on this important program.

So stay tuned!  There is a lot of news coming down the pipeline and we will make sure to get that information to you as quickly as possible.   

Wishing you all a happy, healthy, innovative, successful and fulfilling 2015.

The DevOps Culture Cocktail

(also posted on www.devops.com)

As I have written in previous posts, I believe that IT has accumulated decades of cultural debt that is now due.  We are a young  industry that grew up in silo neighborhoods, each with it’s proprietary practices, language and population of like-skilled specialists.  Left unchecked, the resulting “framework culture” contributed to IT’s cultural debt and is partially the motivation behind DevOps.

The goal of DevOps is not to undervalue or replace the frameworks that are in place.  On it’s own, DevOps is not a framework – in fact,  successful DevOps relies on combined effect of best practices such as Agile, Lean and ITSM.   By recognizing and adapting the best of each, IT can formulate a potent recipe for enhancing performance and increasing customer satisfaction.

So let’s belly up to the bar and mix ourselves a DevOps Culture Cocktail by taking the best guidance from the top shelf of each of the frameworks and practices.  

Ingredient 1:  'Git R Done' Scrum

Scrum is the most prominent of the Agile frameworks and with good reason:  it focuses on getting work “done” in manageable increments while reducing work in progress. 

Pair it with a Kanban Board

While deceptively simple, Kanban is a powerful method for visualizing workflow, identifying constraints and keeping a team focused.

Ingredient 2: Automation

There is a lot of debate around the balance of automation use in DevOps, but there is no dispute that automation and metrics play a key role in successful DevOps. 

Ingredient 3: IT Service Management

ITSM is the deployment's "ever after".  Agile and repeatable service management processes lead the way to stable continuous delivery and increased flow.

 Ingredient 4: Lean

Let’s make it a skinny by creating more value for customers with fewer resources and less waste.

Ingredient 5: People

The most important ingredient.   DevOps relies on the way people think, behave, interact and trust their colleagues.   According to Lloyd Taylor,  "You can’t directly change culture. But you can change behavior, and behavior becomes culture.” 

Finally, add a splash of common vocabulary and a shot of the alcohol of your choice and you now have a DevOps Culture Cocktail!  Serve it daily, share it with your neighbors or sip it while reading a good book like The Phoenix Project.   It does get more potent with age.

I recently had the opportunity to present the DevOps Culture Cocktail Party at Fruition Partner’s FruDevCon Conference.  One of the attendees, a hobby mixologist,  formulated her vision for a signature DevOps Culture Cocktail during my presentation.  We asked the hotel bartender to mix it up, passed it around and a new cocktail was born. Here goes:

The DevOps Culture Cocktail
1 part pear vodka
1 part St. Germain
1 part Chardonnay
2 parts simple syrup or 7 up

Top with a spear of pineapple and a cherry.

Improvement recommendations are of course welcome.  Could this become a staple at all future DevOps events?

Crossing the DevOps Cultural Divide

Someday, I would like to be a world traveler – to visit other countries, experience other cultures, sample other foods and see other sights.  And while the thought of that journey is very exciting, it is also a little intimidating.   In many places, I won’t speak the language, fully understand the customs or know what to do and when.  

There are similarities between travelling the globe and travelling the road between Dev and Ops.  The potential outcome of the DevOps journey is exciting, but also a little intimidating.  In some cases, we won’t understand the vocabulary, customs or know what to do and when.  Both trips will require us to be open to new learning and new experiences.

Before I embark on a world journey, I must build an appreciation for the unique aspects of each national culture and it’s contributions to the global community.  The DevOps journey is no different - it begins with the recognition of and mutual respect for the unique skills and practices at each stop on the itinerary. It is vital that Dev and Ops are viewed as peers with each function adding its own special value to the provision of IT services. Neither is subordinate or superior to each other.    

To prepare for my world trip, I will need to learn a little about the places I will visit.  To prepare for a DevOps journey, we must also learn a little about the function areas that we will work with.   Each team should strive to understand just enough about each other so as to “talk the talk”, but not necessarily “walk the walk”.  Fluency is not required to navigate the basics.

Understanding is great, but experience is better.    I may read about different countries but until I actually walk the streets, the experience will not be complete.  The same is true for DevOps. It is important for Dev teams and Ops teams to actually cross each other’s border and witness the daily workings of the develop-deploy-release-operate production line.  Engagement can range from passive “shadowing” to active participation.  Consider putting an Ops person on a Scrum Team for a sprint,  ask a developer to work in tandem with an operator for a shift or have developers and operators take calls or observe the service desk in action.     Whether in travel or in DevOps, immersion is the best way to learn to function in a different environment.

Your packing list wouldn’t be complete without some useful technologies.  Automation can be a great travel companion as both an expediter and a universal translator.  In DevOps, automated configuration, testing and deployment can make the transport of software  from Dev to Ops consistent and faster. Similarly, monitoring tools, metrics, reports and dashboards can translate and interpret data that provides a common basis for discussing what’s happening in the environment and why. 

While my world journey will eventually end, the DevOps journey will not.    By crossing the borders into each other’s territories, we will be better equipped to engineer realistic DevOps systems that are lean, with common vocabularies, integrated processes, greater efficiencies and greater success. 

A  DevOps without borders.

DevOps and Infor’s Journey to the Cloud

 (also posted on devops.com)

Infor, a leading provider of micro-vertical application suites, has introduced DevOps as part of an initiative to migrate its enterprise application suites to a cloud platform. The significance of this should not be lost.  Infor is not a young, Web 2.0 unicorn that was born with DevOps DNA.   Infor is a 14 year old privately held software supplier with over 70,000 customers across multiple micro-vertical markets.  Infor’s industry-specific applications are mostly deployed and managed on-premise.  The move to a cloud based AWS platform is as much of a paradigm shift for Infor as it is for its diverse customer base.

Infor’s leadership team launched the company’s annual user conference last week with keynote details about Infor XI’s cloud strategy and partnership with Amazon Web Services.   CEO Charles Phillips explained the reasoning behind the move while COO Pam Murphy recounted the technical efforts behind the scenes.   Both acknowledged the necessity of creating a function that would be dedicated to cloud operations. Standing in front of thousands of customers, Ms. Murphy described Infor Labs and how its DevOps practices would ensure that the right operating procedures were inserted into the development lifecycle.  According to Ms. Murphy, DevOps would bring “fully automated hands-free cloud operations that improves efficiency, effectiveness, consistency and security while reducing manpower requirements. “

Infor’s recognition of DevOps as a critical business success factor for its next generation of industry suites is impressive.  Brian Rose, Senior Vice President of Infor Labs and a key member of Infor’s management team for the past nine years provided some insight.  “The motivation behind developing and growing the DevOps team was driven by our ‘Cloud First’ strategy.  Over the last 18 months, Infor underwent a significant transformation to deliver industry solutions in the cloud.   This required development teams to gain a new understanding of the technical operations so that our products operate optimally and cost effectively in the cloud.”

“Our DevOps team worked closely with the development and cloud operations teams to develop standards for the cloud.  Further, they were responsible for setting and maintaining the cloud standards including the development of architectural components  that allowed for the automation of provisioning, patch processing, upgrades, backups, restores, monitoring and the development of a portal to provide a self-service option for these functions,” Rose explains.

Infor Labs has already seen results from DevOps. “The benefits that we have experienced include the reduction of the provisioning of an industry suite from weeks to minutes, decreased implementation time and costs for our customers, and solutions that are optimized from a technical ops perspective that allow our cloud infrastructure to scale so that we can support the thousands of customers that we have today in the cloud and the ability to scale to support the thousands more that we see moving to the cloud in the future, ” says Rose.

While DevOps is not intended solely for applications in the cloud, software providers such as Infor that publicly promote the value of their own DevOps culture increase proof of concept while serving as role models for their enterprise customers.    If the primary objective of DevOps is to improve speed to market and time to value, who better than a trusted commercial software provider to demonstrate real world insight and results.  

DevOps and the Theory of Constraints

The Theory of Constraints was first introduced in the business novel The Goal by Eliyahu Goldratt.   The main character of The Goal is Alex, a plant manager who is challenged to increase the output of his factory in a short period of time or face shutdown.  Alex embarks on a journey to understand systems thinking and relies on a mentoring relationship with an elusive Jonah to help him understand how to improve his production processes.

One of Alex’s key realizations occurs during a hike with his son’s scout troop.   Herbie, a less than athletic scout, is having a difficult time keeping up with the other boys.  Alex observes that it is actually not Herbie who has to keep pace with the troop, but rather the troop that has to keep pace with Herbie.   Poor Herbie is a constraint that affects the rest of the system. 

This example illustrates the basis of the Theory of Constraints – a well-respected model for systems management.  Every process is an end-to-end system that has one or more constraints affecting its outcome.  The process will therefore only meet the capacity of its weakest link.  If the constraint is improved or removed, the flow of the entire end to end system will also be improved.   The key is being able to analyze, identify and improve the constraints. 

Gene Kim’s best-selling novel, The Phoenix Project, builds on the same premise in an IT context.  Constraints are interwoven throughout the story and form the basis for improving flow in the First Way.  As more bottlenecks are overcome, the entire end to end flow between Dev and Ops is improved.

Bottlenecks may not always be apparent since work slows down but does not necessarily stop.   Good practices for process analysis and identification of constraints are starting to emerge.   The soon-to-be-published DevOps Cookbook by Gene Kim and colleagues will provide better guidance.

I believe that understanding and applying the Theory of Constraints will be a key practice to help transform a DevOps culture.  Analyzing the bottlenecks and constraints that exist in and through Dev, Ops and ITSM will help to eliminate waste, identify collaborative and opportunities and streamline the flow of work downstream and upstream.

A Culture of Trust

(also posted on devops.com)

Trust is by far the most critical element of a DevOps culture.  It is also the most difficult to achieve.  IT was not built for trust.  The silo structure that is common in most IT organizations was built for specialization and territorial ownership.  The silo walls are thick.

While DevOps may not be able to break down the silos, but it can encourage and groom a culture of trust.

Trust is difficult to define.  We know when we feel it, we know when we don't.   In 1993, Dr. Duane C. Tway, Jr. published a dissertation called "A Construct of Trust".  In it, Dr. Tway defines trust as

“The state of readiness for unguarded interaction with someone or something.”

Dr. Tway believes that trust is actually "constructed" from three basic elements:

• The capacity for trusting
• The perception of competence
• The perception of intentions

The capacity for trusting is how your total life experiences have developed your current capacity and willingness to risk trusting others.

The perception of competence is your perception of your ability and the ability of others with whom you work to perform competently at whatever is needed in the current situation.

The perception of intentions is your perception that the actions, words, direction, mission and decisions are motivated by mutually-serving rather than self-serving motives.

While trust is individual, a culture of trust is organizational.   Both are earned.  DevOps is a great opportunity to look at Dr. Tway's construct of trust and identify small but meaningful opportunities to steadily increase the trust between Dev and Ops including

• Improved and honest communications
• Increased personal interaction
• Honored commitments
• More listening than talking
• Frequent knowledge sharing
• Welcomed input and feedback
• Admitted mistakes
• Intolerance of blame
• Mutual respect
• A celebration of mutual achievements

What else can you do to create a “state of readiness for unguarded interaction with someone or something” in your organization?  How can you increase a mutual capacity for trusting, perception of competence and perception of intentions?   Perhaps you can start with an honest dialog with and between your Dev and Ops teams.  The answers may be surprising and insightful.

Service Management Fusion Conference 2014

As we ring in September, we also ring in the start of the fall conference season.

It's hard to believe but the itSMF/HDI Fusion 2014 conference is next month!   

As always, members of the ITSM crew will be among the many experienced service management professionals sharing insight, knowledge and experiences at the event.

Donna Knapp will be co-presenting with Anthony Orr at a Breakfast Briefing: How to Pass Your MALC Exam on Monday, October 20th at 7:30 am

I will be leading Session 606: Practical Problem Management: The Courage to Ask Why on Tuesday, October 21 at 2:45 PM.

I will also be participating in Session 704: Expert Focus on Practical DevOps with Brandon Gillis of Bank of NY Mellon on Wednesday, October 22 at 9:00 am.

You can register for Fusion14 at https://www.servicemanagementfusion.com/purchase.

Hope to see you there.