Join the DevOps Community!

Register New Account

BASIC is always free and only requires a simple registration. Members will have access to a vast knowledge library to support continuous learning.

 

Already have an account?

Join the DevOps Community!

Register New Account

BASIC is always free and only requires a simple registration. Members will have access to a vast knowledge library to support continuous learning.

 

Already have an account?

How to Develop DevOps Employees: Focus on Habits and Skills

Culture and Human Skills

By: Soren Pedersen

While you can be trained and certified in many ways, the real benefit of adding new is when habits are changed. In this article, the focus is on how you can drive this change to establish the necessary habits in your organization, ensuring a successful DevOps implementation. And of course improved performance in and across your teams.

Why Deal with Habits?

We all rely on certain patterns of action related to stimuli in our environment. Be it whether you make your bed in the morning to making major decisions. In this article we assume the viewpoint defined in the Merriam-Websters dictionary:

“an acquired mode of behavior that has become nearly or completely involuntary”

Said differently; habits are the human mechanism for simplifying decisions and drive a lot of what we do on a daily basis. When dealing with habits, it is necessary to recognize they can be good,  bad and neutral in relation to reaching our goals short term.

But more importantly, realizing our long term achievements will be the outcome of habits as you repeat the same answer to the same problem over and over.

We often come across this problem in organizations framed like: “We talked about this two years ago as well…” and then nothing happened. This is a typical response from an organization that is responding to stimuli in the same habit over and over. Lots of intentions and knowledge, but habits prevent execution. Most likely you can point out similar scenarios in your company, but don’t feel bad; it is a common occurrence in most organizations, established as they have evolved over time.

While many habits in organizations are useful to speed up execution and deliver consistent results (we don’t want to remove good habits!), it can be a serious challenge when trying to change direction. And remember It is rarely out of bad will or ill intentions, rather it is “how we use to do stuff”.

To be successful in an organizational change, you need to change the core habits of the organization – How are you as a leader going to update the organizational habits?

First and foremost you need to identify what good and bad habits are present in your organization. Habits are of course context based, but here are some examples:

Good

  • Acceptable to challenge assumptions
  • Open and transparent communication
  • Low level of protectionism
  • Collaborative approach

Bad

  • High degree of work segmentation inside a product
  • Formal process acting as rubber stamps
  • Informal hierarchies creating bottlenecks
  • Lack of ability to make decisions based on fact, rather than feelings

While these are examples, I am certain you can recognize some of them from your organization. But first off, spend time studying behavior in your environment. What are the common responses to recurring issues? Are your team’s decisions driven by misperceptions? Are there root causes requiring resolution before changing habits?

3 Habits to start with

While it takes time to observe and gather evidence from your organizations the following section points out 3 starting habits – habits we have experienced making a difference in many organizations, serving as a good proposition as a starting point for you.

  1. Collaboration

First and foremost at the heart of performance and a good DevOps culture is the habit of collaboration. Collaboration doesn’t mean compliance, rather it means the ability to reflect on what the other is bringing to the table and create a better solution than if apart.

Unfortunately we often see a lot of wrongful assumptions challenging collaborations, such as habits of protectionism, rigidity and unwillingness to find solutions that only serve to fuel conflicts in IT organizations – often known as trenches or “over the fence” situations. Much of this stems from wrongful perceptions built over time, as the trenches have grown.

This is why the first habit you want to encourage in your organization is collaboration. As a leader you want to ensure your employees are keeping others top of mind. An approach is to consistently challenge assumptions about other teams, their behaviour and intentions.

Secondly you want to show collaboration by taking your employees or colleagues to the other part, whenever there are misconceptions, distrust or similar assumptions in play.

  1. Waste Removal

A lot of inefficiencies are driven by waste in the organization, which are often seen as hand-overs, long value chains with unnecessary steps etc.

If you want to dive into this theme, have a look at Mary and Tom Poppendieck’s ‘Lean Software Development: An Agile Tookit’.

One of the core habits you want to build in your team is to challenge the status quo. In practice this means that your employees need to build in a habit of spotting when they are defaulting to old “ways” and turn that around to new ways – per habit.

An example:

The Release Meeting

In many situations I have come across organizations, where releases must be approved. Often this is done in a Q-meeting, where core people to organization meet up and discuss if a change is ready to enter production. In many companies this has a good reason and implementation but not in all. The worst case it’s a rubber stamp, gating unnecessarily imposing first of all a delay in when things can be released, as well as introducing bureaucratic steps costing effort and schedule time.

The root of the habit is formed in: “It is too risky to release software that is not approved” – which makes terribly good sense.

However, changing the habitual way of dealing with this goal, it is answered very differently from a DevOps perspective.

Instead of imposing release gates, the habitual reaction should be:

If there were issues in the last release, how do we provide the team with instant feedback loops, reducing the risk of failed releases?

The reasoning behind, in terms of waste removal is, that anything the team can do to prevent issues before releases should be done “in-process” not as a gate. Secondly it removes a step in the value chain and leaves the decision to people who are actually committed and involved.

  1. Programming Habits

This section points its focus on some of the habits that might be useful to change in terms of programming.

At times I see people introduce “manual” parts of their programming, because it’s just going to be a one-off.

An example:

Although rarely nowadays, since the wide adoption of CI/CD, one example is manual steps in a build process. It could be copy-paste action of files, deletion of old files etc. that requires manual intervention. Doing this once or twice is fine, but if it turns into more, consideration should be put into how to automate the process fully. The habit in focus is the auto response where short term execution trumps long term maintainability.

Another habit I often see is lack of documentation.

While documentation is rarely exciting to write, it is key to high performance later down the road. In most organizations I meet the auto-response “We do not have time to write documentation”. Granted in some cases truly bad leadership is present, and documentation has no value. However this is rarely the case. The unfortunate situation is that it has become a habit to forget adding documentation steps as part of the estimation and work breakdown. Often fixing this is coupled with years of lack of proper documentation and the task of correcting the problem is monumental.

The most fruitful way to correct this problem, in my experience, is to change the habit to:

“When working in a file or code area, we always leave the area in the same or better condition than we entered it”.

This gives an incremental improvement of the code, as it is visited. As an added benefit the areas where most changes are made will rapidly be well documented.

Following the ‘Done’ principle from agile, the team’s list, if present, should be updated with a bullet for documentation, preferably assisted by a template in your planning tool, providing predefined tasks when new stories are created. Using a template forces a habit of considering whether documentation is required or not – but at least not forgotten.

Strategy for changing habits

Having dealt with what habits are and some examples, this section will discuss strategies for changing habits in your organizations.

Discovering your habits

As previously noted habits are often nearly or completely involuntarily performed. This poses a challenge when we want to change habits, as they need to be discovered.

From experience detection of bad habits is done through reflection sessions, where past activities and results are scrutinized. This is part of many process frameworks, but requires an open minded culture allowing people to put forward challenges open and honestly.

Another approach is to hire external consultants in, or engage in collaborations with people from other organizations who then shadow the work done in your organization.

They will easily be able to spot habits and ask critical questions, where the organization has developed a blind spot.

I recommend that you keep track of the habits you discover and deal with them over time.

Changing habits

Inspired by ‘Atomic Habits’ by James Clear, I have found the following strategy for implementing habits useful:

Old habits die hard which in terms means you need to have persistence in changing the habits of your organizations. In past engagements my approach has often been to start small, and then slowly increase the change of habits towards the end goal.

This means from retrospectives, root cause analysis and such I urge organizations to only pick one simple thing to change. The reasoning behind is two fold; being too ambitious will cause failure and derail the work of changing habits. And secondly establishing a pattern of microchanges follows James Clear’s 1% Rule, based on scientific social studies. Over time, performing 1% improvements frequently will yield the long term results required.

The second approach is called habit stacking and is best explained as follows:

at a certain trigger point in your work, introduce a new habit or change in habits.

This was discussed earlier in the programming example, where the habit of documentation was added to the template for work items. Stacking the habit of considering documentation on the planning session, allows for a trigger, ensuring that it is at least considered.

Another example could be adding meeting purpose and agenda at the point of calling in meetings. Simply let your mail program by default fill the invitation with an example template, only requiring people fill in the contents of the meeting. This will significantly change how meetings are held and the output of meetings.

Habit stacking can and should also be used on a personal basis to challenge your own way of working. Here reading up on ‘7 Habits of Highly Effective People’ by Stephen R. Covey is a good starting point for your personal journey.

Finally, please note I am not discussing any major change initiatives or change projects. There is a simple reason. Major change projects require a burning platform with significant impact on the organization. Organizations in these positions are in crisis mode and many of the ordinary rules are suspended. Staff may be in stressed mode due to large scale changes and often fear of losing their jobs and so on.

Approaching your Organization

Changing habits in your organisation is key for long term success. When working with an existing or entering a new organisation, I recommend the following steps:

  1. Review the value streams and interaction patterns in the organisations
  2. Discuss and understand motivations and roots for current habits
  3. Analyse current habits and their contribution or lack of to end results
  4. Incorporate habit changing actions in day to day work using habit stacking and 1% improvements
  5. Inspect and adapt over time to keep track of changes in behaviour and results

Do reach out if you want to engage in a dialogue on this subject.

 

Join our Community for Free

related posts

DevSecOps and ITIL4

DevSecOps and ITIL4

By: Niladri Choudhuri, Hugo Lourenco, Jay Shah and Helen Beal DevSecOps has emerged and established itself as the model to assure cybersecurity is properly considered when transitioning to DevOps ways of working. It demands collaboration between the security, IT...

DevSecOps SKILup Day Highlights

DevSecOps SKILup Day Highlights

We’re on the tail-end of yet another eventful month for DevOps Institute. To kick things off, we declared September as DevSecOps month! To celebrate and help the community SKILup on all things DevSecOps, we hosted several events and shared a variety of new resources...

eBook: How to be Resilient in a Culture of Constant Change

Resilience is being able to recognize your own emotions and behaviours when under stress and be able to manage them accordingly. It means embracing the fact that constant change is the norm and accepting the reality it brings.  This ebook by well known organizational...

eBook: Keys to a Successful DevSecOps Adoption

DevSecOps was coined to remind everyone to be mindful of including security practices throughout the entire software development life cycle and into production.  This ebook by by Pete Chestna and Veracode provides an overview of the essential considerations for...