devopsy.kinsta.cloud

Author: Jayne Groll

The DevOps Culture Cocktail

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?

October 9, 2014
DevOps and Infor’s Journey to the Cloud

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 Labs Journey to the Cloud

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.

September 25, 2014
A Culture of Trust
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 could you do to increase the capacity for trusting, perception of competence and perception of intentions in your organization? Perhaps you can start with an honest dialog with and between your Dev and Ops teams. The answers may be surprising and insightful.
September 2, 2014
Me and My Kanban

There has been a growing interest in the Kanban board, a tool that helps teams visualize their workflows, limit work in progress and get more “done”.   Kanban Boards are mostly associated with Agile Scrum teams as a collaborative means of seeing the burndown of a sprint.   In fact, Scrum and Kanban are considered to be so interdependent that a new framework called Scrumban is starting to emerge. However, Kanban is not limited to Agile. A Kanban board can be very useful for any project or scope of work that would benefit from visualization.

The premise behind the Kanban is almost deceptively simple. A board is built with three columns: “To Do”, “In Progress” and “Done”.   At the start of each sprint, all of the work that needs to be completed is captured on individual sticky notes and placed in the “To Do” column. When the task or work is actually being undertaken, the note moves into the “In Progress” column. Upon completion, it is moved to the “Done” column.   If the team has successfully completed the work that was planned for a sprint, all of the cards that began in the “To Do” column will end in the “Done” column. Any other result opens the opportunity for questions about impediments, team velocity (the ability to absorb work) and sprint planning.

You will often see team kanban boards built on whiteboards and peppered with multi-colored sticky notes. There is also a great online tool (www.leankit.com) that offers a virtual team Kanban board with many of the same characteristics. If the three columns are too basic, you are able to add more columns because of the nature of the project.   My only caution is that it is easy to inadvertently make deceptively simple into overly complex.

I have recently started to use a personal Kanban board to manage my own workload. While not perfect, I have seen a significant improvement in my ability to get things done.   It keeps me organized and focused.   I like moving the sticky notes around.

To begin, I created a backlog column with a colored note for each of my outstanding tasks. The list is never-ending so notes are added to the backlog just about every day. At the start of each week, I re-prioritize the backlog to ensure that deadlines and other considerations are addressed. I then take a reasonable chunk of tasks off the top and add each note to the “To Do” column. These are my goals for the week. When I start to work on a particular task, I move its note into the “In Progress” column. Upon completion, the note is moved to “Done”.   At the end of the week, I celebrate what I have accomplished and analyze what was left behind.

If a note stays in the “In Progress” column for too long or moves back to “To Do”, I have to question why. Did I overestimate my velocity or time it would take to complete a task? Have I been faced with extensive interruptions or unplanned work? Was I waiting on someone else?   The visualization of the Kanban board helps me understand my own patterns of work and recognize how I contribute to or impact the results of my team.

I highly recommend that everyone set up a personal Kanban, whether for work or personal tasks. It is a good opportunity to practice while enjoying the pleasure of getting more stuff done.   You can use the whiteboard in your office or set up a free basic online board (like me) through LeanKit (www.leankit.com).   I assure you – the results will be very interesting.

August 18, 2014
Culture Debt

There has been a lot of talk lately about IT’s accumulation of “technical debt’. Technical debt describes necessary work from a prior deployment that was deferred in favor of other tasks. As technical debt grows, the ability to make future changes is hindered because of a backlog that was not addressed.

I have recently come to recognize that IT suffers from another type of debt – culture debt. IT is a young industry that grew rapidly while facing constant pressure to bring technical innovation to the market. Culture considerations were deferred in favor of building and deploying products and services. IT’s silo culture grew organically out of the need for diversifed sets of specialized experience and expertise.

While cultural debt was accumulating, IT’s complexities were increasing. The single platform mainframe vanished in favor of multi-platform servers. Production applications grew exponentially. The IT supply chain went from a single location department to a network that spans multiple geographies and organizations. Although IT’s silos were also acknowledged to be IT’s constraints, converging different processes, frameworks, vocabularies and customs was not going to be easy. And so the cultural debt grew.

Like all debts, payment is eventually due. For IT, the due date is today. Cultural debt is having a tangible impact on the bottom line by hindering IT’s ability to meet the pace of deployment that the business now requires. Every bottleneck in the workflow between Dev and Ops affects the entire system of supply and demand. The business has zero tolerance for missed deadlines, poor quality code or fragile applications. A paradigm shift is required in order to improve IT’s consistency and speed.

The good news is that an increasing number of individuals and organizations are looking to pay down cultural debt by embracing a DevOps approach. Case studies are emerging that demonstrate proof of concept – silos are breaking down and people are talking to each other. Tools are enabling automated tasks and deployments are happening faster with fewer defects. Dev and Ops are starting to embrace a common set of practices and accountabilities. Best of all, DevOps is stemming the rate of future technical and cultural debt – and that’s a win for everyone.

August 13, 2014
The DevOps Diet (Getting Lean)
IT has gotten fat – fat silos, fat processes, fat procedures. Adopting DevOps is a great opportunity to look at some of our unhealthy habits and identify where we can eliminate unproductive waste from our process diets. DevOps will ultimately teach IT how to exercise more with less effort, trim the fat and get lean.

According to lean principles, the seven main areas of waste are:
- Defects – variations from requirements that result in interruptions and re-work
- Overproduction – delivering something more or before it is required
- Inventory – carrying excess raw materials, work in progress (WIP) or finished goods
- Over-processing – doing more work than is required
- Motion – moving people or equipment more than is required
- Transportation – moving products from one location to another
- Waiting – doing nothing or moving slowly while waiting on a previous step
What are the greatest sources of waste in your IT organization? Are defects being regularly passed downstream? Are ITSM processes overproducing through complexity and bureaucracy? Are Agile teams dealing with excessive work in progress and less finished product? Are unresolved bottlenecks resulting in frequent delays while waiting for something to get done or someone to be available? Could automation reduce “motion sickness” and make transportation nonstop? These questions will hopefully facilitate dialog between Dev and Ops about analyzing and streamlining existing workflows.

While waste is fattening, it is not necessarily ineffective. Projects and other tasks are still getting done and therefore some areas of waste may be difficult to recognize. To become leaner, start simple by identifying and eliminating one unhealthy habit from your IT diet. Engage stakeholders from Dev, Ops, customers and suppliers (if appropriate). Discuss ways to improve the work with healthier habits. Agree on what to do next or what not to do anymore.

Every diet should be supported by recipes for success. The upcoming DevOps Cookbook by Gene Kim, et al. will provide more tangible guidance and recipes for healthy IT habits. More on that in future blogs.

Most of all, identifying and eliminating waste through Lean DevOps is a great opportunity for collaboration. After all, it’s always better to diet with a friend.
August 11, 2014