DevOps is the latest industry trend about changing the way IT works. The good news is there is a strong recognition that DevOps is more about culture and people than it is about technology. However it is a sad state of affairs that we even have to stress this fact! People are, and have been for the last 15 years, the most important factor for IT organizational success and the factor that IT managers give the least amount of effort and attention to.
Why do we fail to give the People factor enough attention? It can’t be that we don’t know how to, as the majority of ATO’s that I speak to offer some kind of Organizational Change Management (OCM) training, but there is little uptake. (Managers obviously don’t feel that they need any new people related skills)!!!
Perhaps because IT managers come from a technology background, ex-technoids themselves promoted to positions of management (I was too). They understand technology and techno-speak and struggle with the soft, gooey people speak like ‘culture’, ‘motivation’ , ‘inspiration’, ‘collaboration’ ,’team building’, ‘leadership’. And, as all of us technoids know, the solution to most IT problems in the universe is to throw a tool at it.
Why can’t people be more like computers? After all, a new system doesn’t worry about the culture of the organization. You don’t need to motivate a server to do the right thing. A server doesn’t have to be a team player, you don’t have to pat a server on the shoulder and say ‘good job! Well done’…..You simply instruct it to do what it should do and it does it. If not you simply install a fix or an upgrade. Or reboot it. Or replace it! ‘Why don’t people confirm to the same rules as the technology and do what they are programmed to do’!……….perhaps that is exactly what they are doing only the programming isn’t fit for purpose? As Organizational Behavior management techniques reveal ‘you get the behavior that you reinforce’ (see the term code below).
Considering this fact, that we in IT are more likely to show interest in ‘technology’ concepts, I thought if I position people in terms of latest technology terminology then managers might pay more attention.…..here is my list of some trending technobabble-buzzword-bingo terms; their technology meaning (with thanks to Wikipedia); and how we can apply the term to people.
First of all to set the scene…
Digital transformation: We are….have…entered an age of digital transformation. The sudden dawning that ‘software is eating the world’ (Marc Andreessen 2011) and that ‘every company needs to be a software company’, also represents a transformation for IT organizations and more importantly IT people. It is no longer enough to ‘install a fix’ in people (tweaking what we have), it is time for a radical ‘upgrade’ (new functions and features).
Agile: Refers to an iterative and incremental method for managing the design and build activities in engineering solutions.
A management method. Not a method for managers to be quick and agile in avoiding the sticky brown stuff as it hits the IT organizational fan and then blaming the people. The Agile method should be applied to ‘reengineering’ people. Rather than expecting them to go from being ‘technoids’ to being ‘business partners’ in a single bound (like superman able to leap tall buildings in a single bound.) and then blaming them when they can’t - iterative and incremental steps are required to change the attitudes, behaviors and, in time, the culture. Design and build new ways of working iteratively and collaboratively.
Behavior Driven Development (BDD): A development methodology that asserts software should be specified in terms of the desired behavior of the application.
The same should be applied to people, instead of trying to develop new processes and procedures we should focus on specifying the desired behavior of people. Not adopt the latest framework or approach, e.g DevOps, IT4IT, ITIL practitioner, or the latest set of automated tooling… but focus on ‘what behavior change are these frameworks aimed at realizing’?, ‘what behavior is the automation designed to support and enable’? And why? (what should the application of the behavior lead to in business terms).
Bug: A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
As a result of failing to do the above ‘Agile-Business Driven Development’ people usually start to behave in ‘unintended ways’. Adopting standard management techniques of shouting at them even louder and telling them what to do, may be a temporary fix (work-around), but it is unlikely to be a permanent solution (remove the root cause). Feedback, such as provide in a ‘retrospective’ will help determine whether this unintentional behavior is because there is a failure in the system (new ways of working not fit-for-use or fit-for-purpose), or the inability to perform as intended (e.g. lack of training), or people deliberately do not apply the agreed ‘desired behavior’ (deeper root cause analysis needed). Very often the bug comes from the fact that we never explicitly defined the ‘expected results’.
Code: is a system of rules to convert information—such as a letter, word, sound, image, or gesture—into another form or representation.
A new vision and set of corporate values (e.g Customer focused) is converted into another form of representation ‘desired behavior’. This needs to be embedded into the way of doing things, becoming as it were the new culture of the organization.
Unfortunately what we often see is a list of container terms such as ‘customer focused’ or ‘collaborative’ or ‘professional’ without having defined ‘which visible behavior demonstrates for example ‘customer focused’’? As a result people say ‘but I am customer focused….therefor I don’t need to change’!
Continuous integration (CI): … the practice of merging all developer working copies to a shared repository….The main aim of CI is to prevent integration problems, referred to as "integration hell". Maintain a central shared code repository all developers use.
Merging new ways of working into an existing culture often meets with ‘Integration hell’ some people integrate and internalize new ways of working whilst many retain the old way of doing things (see bug). Using container labels such as ‘Customer focused’ which can be interpreted differently by different people only adds to the confusion and may produce unintended results (see code and see bug). What is needed is that all people subscribe to a consistent, central repository of code - the shared vision & values for the IT organization and the corresponding shared ‘desired behavior’ and ways of operating.
Continous delivery: is a software engineering approach in which teams can produce software in shorter cycles. It aims at building, testing, and releasing software faster, more frequently and more reliably.
Introducing the newly required behavior changes in shorter incremental steps. It’s not DevOps in 1 day, or 1 year!... It is deploying reliably released new behavior, more frequently and reliably. Testing that people understand and are applying and testing that it delivers the required results. Just like code deployment the business will tell us whether it met their needs.
Continuous deployment: Continuous deployment is about getting the change into production…. The purpose of the deployment pipeline has three components: visibility, feedback, and continually deploy
Deploying new ways of behaving into the live environment is often performed as part of an ‘implementation’ project that has designed new procedures, e.g. ITIL and thrown them over the wall. Deployment requires that new behaviors are ‘visible to every member of the team to promote collaboration’, that there is feedback so that we can ‘learn of problems as soon as possible’ enabling us to fix them. Continually deploy – embed the new behavior into existing HRD systems and tools so that new employees get the latest version and release of ‘desired behaviors’. The new behavior becomes embedded in the culture and becomes automatic ‘this is the way we do things’.
Scrum: Enables teams to self-organize by encouraging collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.
Unfortunately many IT organizations adopted the wrong definition of scrum. Adopting the Rugby definition when two teams (e.g Dev and Ops, clash, bang heads, clobber each other and try to force their will on the other). Scrum is actually meant to be face-to-face as opposed to two-faced meetings in which teams actually listen to each other and collaborate rather than clobberate.
Shift Left: is an approach in which testing is performed earlier in the lifecycle (i.e., moved left on the project timeline). It is the first half of the maxim "Test early and often."
I prefer here the association with ‘Left-wing’ politics – ‘supporting social equality, and egalitarianism (equality for all) and having a concern for those disadvantaged’. IT teams often are confronted with a them and us attitude between business and IT, Dev and Ops each feeling disadvantaged and victimized. DevOps talks about ‘engagement’ and ‘collaboration’ with open, honest feedback and operating as equals in a team. ‘Power to the people’! Managers must engage with and empower teams to collaborate.
….and finally all my hard effort above will be undone when we get to the next term
DevOps: is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while AUTOMATING….
..many people stop reading here. They have seen the word they were looking for AUTOMATION..TOOLS!
let’s just adopt the latest set of integration, delivery and deployment tools and automate the complete end-to-end chain and remove the people factor!.....remember ‘A fool with a tool is still a fool’.
DevOps Toolchain - DevOps tools fit into one or more of these categories (I have added the translation to people).
Retrospective: In agile development, retrospectives play a very important role in iterative and incremental development. At the end of every iteration a retrospective is held to look for ways to improve the process for the next iteration.
In many organizations people say ‘we don’t have time to do improvement work we are too busy’.
In the world of an ever increasing amount and pace of change we can no longer afford to stand still. ‘Improving your work IS your work’. Retrospectives offer a good way of identifying bugs in our behavior and identifying appropriate fixes.
Rebooting: is the process by which a running computer system is restarted, either intentionally or unintentionally. Reboots can be either cold (alternatively known as hard) or warm (alternatively known as soft)
Finally when you have tried everything you can think of but still people don’t want to change many managers turn to the ‘hard’ reboot. Adopt a new framework, make some more processes, mandate new ways of working, install a tool to solve the people issues through automation, implement ‘punishment’ mechanisms in favor of ‘reward’ and ‘recognition mechanisms. A warm, inclusive or soft reboot is what DevOps promotes. Creating an environment of ‘trust’, stimulating engagement and collaboration, and empowering teams continually reflect on things that don’t work and improve together.
What will your next people related reboot be? Hard or Soft?