A common problem If your team has an unprepared backlog this is almost guaranteed to cause problems. Planning meetings take ages, and it significantly increases the likelihood that your stories won't get "done" - you'll just end up with a growing pile of WIP. Not to mention the time that gets wasted with the whole team watching one person frantically typing away. Fix this by Ensuring someone or a group "own" the backlog. They should always be refining it, and have a clear understanding of what is in it, and keep it tidy (no duplicates, no tickets randomly created, etc) Refusing to start work on any stories that are not "ready". This will Mean you don't end up with a messy backlog that no-one understands, or takes ages (for many people) to clean up. Shift the focus onto regular refinement, ensuring that stories are prepared, researched fully and then understood by the team. Give you a much better chance of having your work "done" by the end of the iteration. Improve conversations on priorities - changes and so on are much easier when you have a clear and ordered list to discuss. Summary I'm not suggesting this is necessarily an end-state goal, but it could help you get out of a hole and start moving towards more predictable delivery.

The first couple of blog posts were aimed at giving you some essential basic skills, building up your confidence to explore a Linux installation before you get your teeth into the actual day-to-day stuff. As a DevOps engineer, one of the key things that you will be doing includes installing / deploying software and configuring it - so, it’s important that you understand how these tasks are achieved. At this stage, I could introduce you to some DevOps tooling that you would typically use, but I’m not. Mostly because I need you to feel the pain that I went through so that you can appreciate the benefits of tools like puppet, ansible and even containerisation (Docker). What’s your flavour? There are an abundance of Linux flavours ( distributions ) from Alpine, to Ubuntu, to RedHat. Which do you use? In my opinion, it’s not that important at this stage. The differences between the various Linux distributions will be very subtle to you at this point. What is important is that you are aware that different distributions of Linux have different package repositories, and different commands to install, but they essentially do the same thing: Pull down packaged software from a central source Install it and any supplementary files such as start/shutdown & management scripts as well documentation “What is a package repository?” I hear you say. Package repositories are essentially a centralised store of pre-compiled, pre-built and pre-tested software which optionally may include such things as configuration files, management & start-up/shutdown scripts and documentation - basically, everything that you need to start using the desired software. Benefits of using a Package Manager As a rule of thumb, always install software from a reputable source using your chosen OS’s default package manager. Package managers are your client(s) to package repositories, they understand where to look for software, how to install it, upgrade it, and remove it. Installing software using the default package manager will make your life easier as they are: Tried and tested Repeatable and consistent Easily maintainable Standardised installation and configuration Have dependency management built-in; if software “a” requires software “x, y and z” then the package manager will install the required software and appropriate versions If you can avoid it, do not build and install from source as this will give you a maintenance nightmare further down the line. For example (using Ubuntu’s apt package manager) which would you prefer to perform: sudo apt upgrade nginx , or Find and download nginx source files, unpack it, read the instructions to build, configure the build, build and install it Thought you might prefer the first option! If you prefer the latter, then imagine doing this for tens of machines! Still prefer option b? Let the Package Manager do the hard work for you Using package managers to install software is quick and reliable, you can install an application in seconds and have it configured, up and running in minutes. On a Ubuntu system, you can have nginx up and running with essentially two commands: $ sudo apt install nginx $ sudo systemctl nginx start To upgrade it, $ apt upgrade nginx $ sudo systemctl nginx restart To remove it, $ sudo systemctl nginx stop $ sudo apt remove nginx How simple is that? Whichever OS you use, its package manager will allow you to install software as easily as this. The package manager client application will generally allow you to: Search for packages to install Install specific versions of software List what other applications have also been installed by it Lookup information, such as dependencies as well as where files are installed The latter is particularly useful post-install, as in some cases, you will want to know where files have been installed to and where the application’s configuration files are. So, don’t forget to RTFM ( man ) your package manager client software :-) Configuring applications Following an installation of an application, you may want to configure it. Each application will have its own specific configuration to it so there isn’t really one magic rule other than to RTFM. It’s a time consuming activity, but reading the manual can prove fruitful and potentially save you lots of time further down the line. Be armed with: Your package manager, as this will help you identify where files referenced in the manual may be found and what they do. Your newly found Linux command line skills ( https://www.ejmit.co.uk/blog/devops-must-know-utilities ) Your vim skills ( https://www.ejmit.co.uk/blog/devops-the-beginning ) Summary As a DevOps engineer, one of the many things you’ll be doing is installing and configuring software so it’s important to get to grips with the tools that will enable you to do this quickly, accurately and consistently - and using a package manager certainly simplifies this task. Shy away from installing software from source wherever you can as quite often, it is not available as it’s not supported on your particular OS and/or hardware configuration. The only scenario where you will have to consider installing software from source is with software developed by you and/or your organisation. How this scenario can be tackled is beyond the scope of this blog, however it will be covered in a future blog where I discuss containerisation, so keep an eye out for that post :-)

This post is going to continue the theme of testing (by coincidence, honestly) - but don't worry, it's a short one. GeePaw Hill often writes detailed tweets on the intricacies of software development and I found this series really hit the spot. Here he explains how it is that we really approach TDD testing. While many people many view this as black box testing (where you cannot see "inside" the thing under test) as opposed to white box testing (where you are aware of all the internals) the reality is that the testing we most commonly perform is a hybrid - grey box.

So, in the first part of this series of blogs it was suggested that you learn and be comfortable with using a shell ( bash ) and text editor ( vim ). This post follows on from that, giving you some pointers to what utilities you should familiarise yourself with. Unix Philosophy As you progress and learn / gain more experience you will realise that the Unix/Linux (*nix) landscape is made up of lots of small little utility programs, each program does something, and does it well - DOTADIW, “do one thing and do it well”. These tools share common traits, They will be accompanied by documentation They can take input from STDIN , send errors/warnings to STDERR , and output to STDOUT They are modular, and can be combined together to perform amazing things This post aims to introduce you to a few must know utilities, and how they enshrine the Unix philosophy, and will give you an idea of how they can be combined to great effect. RTFM Haven’t come across this acronym before? You will hear and see it a lot. RTFM. Read The F*****g Manual. If someone says this to you, it’s not with malice, the acronym has good intentions, the intention is that the information is there for you, you just need to help yourself, learn and teach yourself and be self sufficient - teach someone to fish and all that... Most utilities that are installed on *nix systems will be accompanied with manual pages accessed via a utility called “ man ”. Want to see what arguments and/or optional switches a utility can take? man will display the manual for said . For the most part, manual pages are well written and contain a complete guide on how to use the , with examples in the majority of cases. They can be long, and there is a temptation to look up the information elsewhere as a result, but know that the information is there for you to reference. Why don’t you try starting with man man i.e. the manual page for the “ man ” utility. No manual page provided for ? Try --help -? Either should give you a short brief guide on how to execute said . For all the utilities that I suggest here, it is well worth spending a bit of time reading the manual pages, there will be some useful command switches that you will simply commit to memory, and soon enough muscle memory. Navigating the file system You will be working in a shell A LOT, knowing how to navigate the file system, as well as creating, updating and deleting files & folders is a minimum. In general, get to know the following commands: ls - list contents of directories cd - change directories mkdir - create directories mv - move / rename files and directories rm - delete files rmdir - remove directories cp - copy files and directories find - find files and directories ln - linking files and directories Working with files By now you would already know how to open, edit and delete files with vim . But, what else can you do? file - unsure what type a file is, use file cat - concatenate and print files [to STDOUT ] less - open a file in read-only mode more - same as less - more or less :-) head - display first lines of a text file tail - display last lines of a text file grep - find text in a file tar - create / extract tar archives Working with text Working on the command line you’ll be working almost exclusively with text whether that be directly on the command line or from text files, so it’s important to know what utilities you can call upon to manipulate text. tr - find and replace text sed - a stream editor taking input from files or STDIN , and outputting manipulated text to STDOUT awk - scripting language for manipulating text data and generating reports regular expressions (regex) - not a utility, but a concept/language, almost any *nix text tool will have some implementation of regex. Working with networks These days it’s almost impossible to do anything without having a network, so knowing what utilities are available to help you find out more about the network that you are on, how to navigate, and lookup information is vitally important - after all, there will be occasions where you or someone working with you will have some network connectivity issues that will require investigation and troubleshooting. nslookup - lookup an IP address of a host dig - DNS lookup utility nc - useful for testing connectivity netstat - show network statistics ifconfig - configure / view network interfaces curl - transfer data from or to a server tcpdump - dump traffic on a network ssh - remote onto another machine securely What is STDIN / STDOUT / STDERR? I’ve mentioned these acronyms in previous sections, without actually telling you what they are and what they do. Simply put they are input / output streams: STDIN - this is where a program can receive input from STDOUT - by default, this is where a program will output information to STDERR - if there are any errors, a program will generally output to this stream Many of the command utilities mentioned in the blog post will typically take input from STDIN and output information to STDOUT . Bring it all together Input / output streams can be redirected to files, other streams, even other utilities by using “ > ”, “ < ”, and “ | ” operators. Why is this useful? Let’s say we have a large directory, with 10s or 100s of files and/or directories. Executing the “ ls ” command will cause your terminal to scroll, you won’t be able to view / search through the directory listing. What you want to be able to do is to view the output in something like more , or less . So, what you can do is redirect the output, save it to a file, and then open up the file in less . ls > directory_listing.txt less directory_listing.txt Actually, do I even need to save the output of ls to a file before opening it in less ? No, I don’t. I can simply “pipe” the output of ls into less : ls | less This is a very simple illustration of the use of I/O stream redirection and the use of pipes (pipes are how you chain commands together), as there is virtually no limit to how many commands you can combine together, the only limit is often your imagination and creativity. For example, take the below: date +%s | sha256sum | base64 | head -c 32 This combines 4 utilities ( date , sha256sum , base64 , and head ), seemingly unrelated, with the only commonality that they take input from STDIN and output to STDOUT , combined together to create a simple password generator. Try executing each of the utilities separately to see what happens, and if you get stuck or get an error (which you will do), then reference the man page to find out what you may have done wrong and how to fix it. The use of I/O stream redirection, and especially the use of pipes to combine commands perfectly illustrates the Unix philosophy described before, with each utility DOTADIW, that can be combined to great effect. You should also know about these utilities: tee - redirects STDIN to both STDOUT and one or more files xargs - take STDIN as an argument to a utility Read more about I/O stream redirection here, and what other operators are available: https://www.tldp.org/LDP/abs/html/io-redirection.html Summary You’ll use many of these commands on a daily basis, there is no escaping this fact. Many of the commands and option switches will be committed to muscle memory, but for those commands that you won’t be executing on a daily basis, such as sed and awk , it’s important to know that they are there, what they can do, and how they can be combined. Do spend a bit of time reading the manual pages for these utilities, get a feel for what problem they are trying to solve, its approach to solving that problem, and how it can be used effectively. Knowing this will save you large amounts of time, reduce mistakes and therefore, increase your accuracy and productivity - and, you’ll go from zero to hero in no time.

Why would that happen? This must be the most common reason for a lack of software agility that I see on a regular basis. Either the pyramid is upside down or it is a sort of diamond shape, meaning narrow at the top and bottom but fat in the middle. This happens when the developer-based tests do not have a sufficient level of coverage, and that coverage is required in order to have a strong base to your pyramid. That's why Part 2 covered this in such detail, those tests form the basis for all testing that comes after, as well as informing what scope those later tests should (and should not) have. The Testing Pyramid The exact layers of a pyramid can vary, but they all have the same basic structure: Bottom layer(s): Tests are faster to write and quicker to run (and are therefore cheaper in terms of time spent) Top layer(s): Tests are slower to write and take longer to run (and are therefore more expensive in terms of time spent)

Introduction I read a lot of blog posts and guides about DevOps, most of these tend to cover specific tools, languages, and concepts but do not really give you any guidance on where to start on that journey, and what essential skills an engineer should have. When I was first starting out as a Software Engineer on Linux, I was fortunate enough to work with some great people who taught and imparted me with some really good, useful words of wisdom - things that have been instilled into me and I rely upon to this day. Through this series of blog posts, I’m going to give you an introduction to what skills I think you should have in order to make a success of your role as a DevOps engineer and to share with you some of those words of wisdom. What advice was given to me When I first started out as a Software Engineer, there was no concept of DevOps, neither was a “fullstack developer” a thing, you were an engineer that was concerned with literally everything, front-to-back, you concerned yourself with how to install, configure and package your applications, how to operate your custom built software in all environments including production. It was interesting and fun times and the technology world is embracing this again with “DevOps”. So, going from writing Windows based software to client/server web applications on RedHat Linux was going to be a bit of a learning curve. I learnt a lot in a short space of time and these were the starting advice given to me: Learn the basics, grow from there Learn to use a text editor, and learn it well Learn a shell, and master it Learn and understand the basics The topics here are intended to give you gentle introductions, to point you in the right direction from where you can springboard to more advanced scenarios and use cases. Learn to use a text editor As any kind of engineer you’ll be working with plain text files a LOT, they’ll be YAML or JSON, or INI, or some weird and wonderful format. These file formats often govern how an application is configured. What all these file formats have in common is that they are in plain text - easily readable and editable from any text viewer/editor, you do not need to install some proprietary software to view/edit. So, one of the very first things you should learn is how to use a text editor - preferably through a terminal, something like vim. Why in a terminal? Well, you’ll often find that you’ll be jumping into different servers ( even containers) examining their configuration files, tweaking them, restarting the services that are attributed to them. These files, for the most part, are out of reach of your favourite locally installed editor (e.g. VS Code, Atom and the like). What you can almost always rely on being available on a remote machine is vim - learn it, use it every day, and when some service breaks in production and you need to tweak a few configuration lines, have the confidence to use vim instead of rushing to install some random text file editor that you probably do not have permissions to install, or pulling the manual out to figure out how to edit a file with vim. As a minimum, learn how to do the following: Create and edit a file (Yes! Really!) Navigating a file, e.g. finding words, moving up, down, left and right, jump by word Copy (words / lines / blocks) and paste Displaying line numbers, jumping to specific lines in a file Closing the editor Opening multiple files, in tabs, in split planes (horizontal or vertical) Navigating from one buffer to the next in tab mode, in split panes For me, these are the basic actions that I tend to do on a daily basis: I like to open multiple files to compare / contrast, so I like to see more than a single file displayed at a time in a single vim session I need to be able to jump from one “buffer” to the next, making edits where required I see some warning/error about some line of text being syntactically incorrect, e.g. syntax error on line 212, so I’d want to be able to open up the file and jump directly to that line - can you imagine scrolling down to line 1053 with the ‘j’ key? Admittedly, as a beginner with vim you will find it convoluted and overly complex to use, but there’s a reason why it’s loved by many - persevere with it, and you will be rewarded. Learn the basics and be comfortable with them, resisting the urge to customise it too much as you learn the basics. Customising it too much and introducing plugins may mean that you become too reliant upon them and be stuck without them on a remote machine where you do not have the same level of freedom. Resources: Vim has been around for many, many years and fortunately, there is a lot of literature and guides on learning, using and customising vim, checkout some of the links below: http://vim-adventures.com/ learn vim by playing a game! http://vimawesome.com/ plugins for vim Learn a shell As an engineer, you’ll be spending probably 90% of your time in a terminal interfacing with some computer through commands in a shell via a terminal session; the other 10% will probably be checking your emails via an email client, chatting to colleagues via Slack / Teams etc., or searching for a fix for a problem that you’ve encountered via your favourite web browser. The shell is a very powerful tool, used properly and as your comfort level and experience increases it can be massively productive. It is critical that you familiarise yourself with a shell. There are a multitude of shells that are available for you to use, the most popular and common is bash. There are others such as ksh, csh and zsh. But which one should you learn and use? Well, we can apply the same logic as we applied to learning a text editor ... learn bash as a priority, you can quite safely assume that bash is going to be available on almost any Unix/Linux installation. Basic things you should be able to do on the shell (with Bash) include: Navigating the folder structure, e.g. changing from one directory to another Finding files and searching for files with specific lines of text Opening files for reading, either in a program or output to your terminal session Searching through your command history Chaining commands together (e.g. the output of one command, is the input of another) Again, these are basic interactions that I have through the shell on a day to day basis: Navigating the folder structure Searching for files where I know its name, but not its location Searching for files that include snippets of text Opening files to read and/or edit Repeating a long command again that I’ve executed previously Resources The below is a helpful place to start to learn about bash, giving you a gentle introduction before jumping in to a bit more advanced topics https://www.tldp.org/LDP/Bash-Beginners-Guide/html/ Summary As the first post on this subject, it was my intention not to overload you too much with information and not to give you too many pointers - yes, some of it was a bit vague, but it was done so as to wet your appetite and to give you a good foundation from which to springboard into more advanced topics. Understanding these basics techniques will be the building blocks as you become more proficient. Then, when you hit problems you are more likely to be comfortable looking up solutions online and understanding the answers that people give. The rationale for this post was mostly because I’ve worked with a large number of engineers who are great at their job, do great work, but sometimes they can get stuck with the most basic of things such as editing a configuration file on a remote machine as the only editor available is vim, not knowing where a configuration file is and not knowing how to locate it. It is amazing how much of a superhero you can be just by knowing these basics.

In my last post I talked about how software can degrade over time, which means changes take longer and become riskier. To avoid this your software teams need to use the practices of eXtreme Programming. This post is not a detailed breakdown of XP. Instead I will focus on a couple of specific areas that will help you to maintain a healthy design and code base, which in turn will help you to avoid the problems I discussed previously. Designing with TDD I'm not going to repeat what I've said before about the benefits of Test Driven Development (TDD) and why you should do it. I've also covered before why the "Refactor" stage of the "Red-Green-Refactor" cycle is critical. What I want to do here is to get into the practical detail of these ideas. Let's start with the video below, from and former colleague of mine Sandro Mancuso . In it he covers: Why TDD can help lead to good design Inside-Out TDD (Chicago style, or Classicist) Outside-In TDD (London style) If you are part of a software team in any capacity, then you must understand these concepts well. These two TDD techniques are not mutually exclusive, they are complimentary, and you need to understand how they work so that you can use the appropriate one in any given scenario. Do try to find the time to watch this in full. NOTE. Other elements of the video such as understanding component association types and how that affects your tests will be covered in Part 3.

Welcome to my first trilogy. It needs three parts so we can cover some points that are critical to your Agile software development - yet it feels like many have missed them entirely. Agile software development is about software I appreciate this sounds obvious (or even obtuse) but there is so much evidence that a lot of people have forgotten this, or even worse they never knew it in the first place. But how can you miss that? As I've said in previous posts (and the people involved in creating the Agile Manifesto are being increasingly vocal about) Agile was originally "a small idea for small teams to solve small problems". But then along came Certified Scrum Master training, and people who knew nothing about software were educated on how to run a team to do so - mostly. Scrum is a great framework - as I always say. But it does have one fairly large gaping hole in the middle of it: It does not tell you how to write software in order to satisfy the ideas it lays out Bit of an issue that if you ask me. This omission is most likely a big reason that the project management world got hold of it so firmly (and promptly turned it into something other than it was intended to be, but lets not go there today) since it did not define any technical approaches, but just how to manage the framework. Come on, is it that important, really? That's a reasonable question. Let me give you some (way too) common examples. H ave you ever heard any of these phrases before? "The code is a mess" "It's too hard to change" "No one has touched that part in months / years, and we're scared to in case it breaks something" "It's all spaghetti code" "If we change that we don't know what effect it might have somewhere else" "It's like a ball of mud" "That change will require extensive re-testing and integration testing, maybe weeks or months" And the absolute classic: "We need to re-write it from scratch" These are all signs that the quality, developer-based micro testing (also known as unit tests), developer based integration tests and most importantly the design have been neglected. And this is where you can come unstuck if you just follow the framework laid out by Scrum. Let me describe what this looks like in software terms over the life of a project. Quietly put your hand up to yourself if you've ever experienced something like this: A new project is started Progress is rapid, new features are easy to write and testing is easy Progress starts to slow a bit, but changes to existing behaviour are taking longer Bug counts start to increase and are harder to fix Things start grinding to a halt, any change to the code takes ages and causes several other problems including regression issues I'm sure we can all admit (privately, no need to say anything out loud) that we've all seen this. But why does that happen? This happens because the basics of good software development (which the group who created the Agile Manifesto were all aiming for, albeit in different ways) have been ignored, plain and simple. So, what is the right way to go about it? I've talked about the Reg-Green-Refactor cycle before, so I won't repeat myself. But that cycle is crucial to maintain good design of your code base. And the good design of your code base is crucial in order to avoid ending up in the mess I describe above. To save a lot of preamble I'll cut to the chase. If you want the benefits of Agile software development and for Scrum to work: Y ou need your software teams to be using the practices of eXtreme Programming . You just can't avoid that fact. This short video from J. B. Rainsberger is a fantastic explanation of this. It won't take you long, as you can see it has the snazzy title of "7 minutes 26 seconds".

I see a lot of people saying that change has to start with culture, and some of these posts get a LOT of likes and positive comments. But I have never seen any specifics as to how they suggest you do this. Honestly, not one. And I think there is a reason for this. What is Culture? A definition from your favourite search engine[1]: culture ( noun); plural noun: cultures - the arts and other manifestations of human intellectual achievement regarded collectively. - the ideas, customs, and social behaviour of a particular people or society. From Wikipedia [2]: is an umbrella term which encompasses the social behavior and norms found in human societies, as well as the knowledge, beliefs, arts, laws, customs, capabilities, and habits of the individuals in these groups. Humans acquire culture through the learning processes of enculturation and socialization, which is shown by the diversity of cultures across societies. From the University of Warwick [3]: ‘Culture is a fuzzy set of basic assumptions and values, orientations to life, beliefs, policies, procedures and behavioural conventions that are shared by a group of people, and that influence (but do not determine) each member’s behaviour and his/her interpretations of the ‘meaning’ of other people’s behaviour.’ Ok, I knew all that Sure, point taken. The aim there was to get a firm idea of what culture is before moving on, because while it may feel easy to define on a closer look it is much harder to pin down. The University of Warwick article alone starts with 6 definitions (from various sources) which all draw attention to different elements. Thankfully I'm not trying to come up with some uber-definition here. Phew. What I do want to point out is the common thread of words like: behaviour, manifestations, processes, procedures. Keep that in mind while we move on. Observing Culture Think about any time you have started working for a new organisation and how you learned their culture. Some may have shown you a written statement that defined it, others may not. Either way, you most likely looked for signs of common behaviours that other people demonstrated (dress code, daily hours, break patterns, personal items, ways of talking, hierarchical relationships etc). These will have either backed up the defined statement or simply demonstrated themes that people have adopted in response to the culture that is actually present. And I believe those are the traits that you will have taken on. Organisational Transformation Now let's get specific. Most of what I read agrees that if an organisation wants to under go an Agile transformation there are some key areas that you will need to address[4]: Systems Processes Culture The key points here is this - I agree with with specific order of these points. Going against the trend I agree with this order for the reasons that are explained in the associated article (see References below). So the crux of the issue that I see is - People state that change must start with culture, but they don't provide any evidence as to how that works - or approaches on how to do so. The big speech Lets say you work for an organisation, and everyone is called together for a big town hall style meeting for a major announcement. Your CEO stands on the stage and proudly states "We are going to change how we work, we are going to move away from our old waterfall ways of working to an Agile approach to deliver our software". There are charts, there are explanations, there are big motivational speeches and everyone goes away highly enthused, looking forward to this great new world and all the benefits it will bring. But then you get back to your desk, and you're still looking at the same specification document you've been working on for the past 2 months - with the same deadline in 2 weeks - for the same project that is due to complete in 15 months on which significant time and money has already been spent. You're stuck. You want to believe the new world is coming, but your boss is still pressing for the work against the existing deadlines. Nothing demonstrable has actually changed . The only way the situation will improve is when the demand for the project (in its current form) is taken away and something new is put in its place, but you are not going to achieve that with culture, you need to change the systems and processes within the company for such a huge shift to take place. By starting with concrete actions that people can actually observe like new systems (organisational design, how work is defined / prioritised), new processes (cross functional teams working on small iterations) people can see a change in the behaviour of the organisation itself. Once that is under way then absolutely you can start to introduce the idea of a new culture because people can see that changes are happening, and new behaviours are being demonstrated[5][6][7] throughout the company, which will make it much easier for everyone to buy into it. But, you can be clear that a change is coming I had an interesting conversation about this recently that highlighted an important idea. Although you cannot start a change with culture it will probably be very useful to inform everyone that a shift is coming, and to describe what that looks like and give some idea of what the goal is. This isn't trying to alter the culture at the start, but it is making clear your intention to do so, and more importantly how you intend to do it. Of course then the organisation will need to follow through on its promises and start to show it's employees that it means it. But when the actions do start then people will have both the idea of the changes and evidence that they are real, which is fantastic - the two can snowball together each giving the other added momentum. Summary Cultures are extremely important, and they are present even if they are undefined. But if you want to change one you need to give people a reason to believe that you mean it, so that they will be able to mentally adjust and buy into a change, by seeing actions and new behaviours rather than just words. Addendum - can you show otherwise? If you have an example of where culture has been changed first I would LOVE to hear from you, so that you can help me understand how it was done, and what steps were involved. Thanks! References [1] https://www.lexico.com/definition/culture [2] https://en.wikipedia.org/wiki/Culture [3] https://warwick.ac.uk/fac/soc/al/globalpad/openhouse/interculturalskills/global_pad_-_what_is_culture.pdf [4] https://www.leadingagile.com/whitepaper/ [5] https://www.tlnt.com/changing-culture-starts-with-changing-behavior/ What people actually do matters more than what they say. Therefore, to obtain more positive influences from your cultural situation, it is better to focus on changing behavior, which can lead to real culture change. Direct appeals to change beliefs, values, or ways of doing things rarely achieve the desired results, but if behaviors are changed the mindsets will follow. [6] https://hbr.org/2017/06/changing-company-culture-requires-a-movement-not-a-mandate But instead of plastering this new slogan on motivational posters and repeating it in all-hands meetings, the leadership team began by quietly using it to start guiding their own decisions. The goal was to demonstrate this idea in action, not talk about it. [7] https://www.management-issues.com/opinion/7236/changing-a-culture-starts-with-changing-behaviours/ a successful culture change relies on a clear focus on behaviours from the outset, and the behaviours need to be seen as the ‘hard’ stuff and it is important to role-model and reward desired behaviours in order to sustain them.