devopsy.kinsta.cloud

Author: Mark Smalley

  • BVSSH and the Digital Zeitgeist

    BVSSH and the Digital Zeitgeist

    I like the book, “Better Value Sooner Safer Happier” (BVSSH), by Jon Smart with contributions from Zsolt Berend, Myles Ogilvie and Simon Rohrer. It is not only a punchy title that captures much of what we do in IT, but it also has the depth and nuance that is sorely needed. It focuses on outcomes while recognizing the intrinsic unpredictability of the systems (in the broadest sense) that we work in.

    DevOps

    Although it will be of interest to most IT-related disciplines, because of the people who follow Jon and his publisher, the book’s first audience will probably be the DevOps community. DevOps is a broad church, but many of the constitution have a strong focus on getting stuff shipped frequently, quickly and reliably. This is reflected in the metrics that are typically promoted for DevOps: deployment frequency, lead time for changes, change failure rate and mean time to recover. It is good to note that lead time is measured from code commit to production, so very right at the end of development. They are concerned with the tools for, and process of, successful deployment of increments of software. The functionality that is being shipped is often of less interest to those tasked with deployment. The boxes just have to be shipped, whatever their content. Most of the 67 practices in the excellent “DevOps Handbook” reflect this. The principles behind DevOps, however, can be applied beyond the deployment area, and many people do this. But DevOps’ sweet spot in terms of its contribution to improving activities is deployment.

    Agile

    Similarly, Agile also has a sweet spot: developing software increments that are potentially deployable. This definition of done demarcates where Agile guidance defers to DevOps guidance. An equally interesting demarcation is at the start, where the focus is on opportunities, hypotheses, requirements and specifications. Does Agile guidance help when there are unarticulated user needs and ambiguous hypotheses? Or is this the natural habitat of business analysis? Dave Snowden speaks of “pre-scrum techniques,” implying that Agile shows its value when requirements are clear enough for development of the first viable product increment. Just as with DevOps, Agile also embodies principles that can be applied beyond its sweet spot of software development.

    IT Operations, IT Service Management and Value Realization

    At the end of the value stream, we are concerned with ensuring that the potential value of the software products is actually realized. Much of this is beyond the scope of influence of the service provider, where IT operations (including site reliability engineering) and IT service management concern themselves with ensuring that the systems are performing well and that the users have access to the systems. Not only does the information system have to be operationally resilient, but users also have to use the functionality effectively, interpret the information correctly and take better decisions and, finally, act on those decisions.

    The ‘What’ of BVSSH

    Return of investment in digital products and information systems is only realized when people or things actually do something with them (or avoid undesirable action). This extends the definition of done way beyond deployable, deployed and accessible. “Done” is when value is realized, and this is the “what” of BVSSH. As Jon says, “It’s why you are doing what you are doing. It is of value to someone. It could be financial; it could be maintaining public safety; it could be charitable.”

    The ‘How’ of BVSSH

    The “how” of BVSSH is represented by better, sooner, safer and happier. Better refers to quality that is built in from the start. Sooner covers the end-to-end value stream, although I would extend the scope beyond the provider’s “getting it into the hands of a customer.” Safer is about “governance, risk and compliance, information security, data privacy, regulatory compliance and resilience in chaos. […] It is speed and control, not one or the other. […] The better the brakes, the faster you can go.” Finally, happier covers customers, colleagues, citizens and climate. “It is a more humane way of working, with empowered multidisciplinary teams and high levels of psychological safety, enabling experimentation and improvement.”

    Digital Zeitgeist

    I was delighted to see parallels with what we had written in ITIL 4 High-velocity IT. We recommend considering five objectives that help you identify and assess your weakest link across the whole value stream, and discuss which improvements you could make:

    • Valuable investments – Strategically innovative and effective application of digital technology.
    • Fast development – Quick realization and delivery of digital services and products.
    • Resilient operations – Highly resilient digital services and products.
    • Co-created value – Effective interaction between service providers and service consumers.
    • Assured conformance – Adherence to governance, risk and compliance (GRC) requirements.

    Valuable investments and co-created value correspond with value, fast development with sooner, resilient operations with better and assured conformance with safer. Happier manifests itself in co-created value but also in the five key behavior patterns that I believe employees aspire to:

    • Help get customers’ jobs done.
    • Trust and be trusted.
    • Accept ambiguity and uncertainty.
    • Continually learn and improve.
    • Do the ethically right thing.

    As I pointed out in another article, Gene Kim came up with a similar concept to the aspirational behaviors in his book, “The Unicorn Project.” He calls them the five ideals:

    • Locality and simplicity in our code and organization.
    • Focus, flow and joy in our work.
    • Enablement of improvement and achievement.
    • A culture of psychological safety.
    • A relentless focus on our customers.

    This all reinforces my belief that many of us are thinking along the same lines. We have tuned into the zeitgeist. People are increasingly concerned about doing the right thing and doing it well, and I am sure that “Better Value Sooner Safer Happier” will contribute to energizing this community.

  • The Phoenicorn Project

    The Phoenicorn Project

    The Unicorn Project is the sequel to the ground-breaking book The Phoenix Project. Most people know the story about Bill the IT manager at Parts Unlimited, who is tasked with fixing a derailed IT project or having his IT department outsourced. The Unicorn Project takes it a step further, with developer and architect Maxine in the starring role, helping Parts Unlimited to develop new products in new markets–the riskiest combination of all. This requires gambles that are only justified when the organization can experiment rapidly, break the rules and deviate from the processes that govern their current–but diminishing–business.

    The content of the book revolves around five so-called Ideals:

    1. Locality and simplicity in our code and organization.
    2. Focus, flow and joy in our work.
    3. Enablement of improvement and achievement.
    4. A culture of psychological safety.
    5. A relentless focus on our customers.  

    These are a natural progression of the themes in The Phoenix Project, in particular the first and third of The Three Ways of DevOps: 

    1. Attending to the performance of the entire system, as opposed to the performance of a specific silo of work or department (related to Ideal 2).
    2. Creating short feedback loops, enabling necessary corrections to be continually made.
    3. Creating a culture that fosters continual experimentation, taking risks and learning from failure; and repetition and practice as the prerequisite to mastery (related to Ideal 3).

    Topics related to the first four Ideals have been explored in other books in the same family of publications, in particular The DevOps Handbook. The last Ideal–customer focus–is for me the most significant addition. It really draws attention to how IT and business have to converge and even merge in order to develop new business models. Meaning that those people-previously-known-as-IT have to up their game and develop a much deeper understanding of the jobs customers need to get done. The business value of DevOps has interested me since I got involved in the movement, and I’ve captured some thoughts in a white paper for the DevOps Agile Skills Association.

    It’s another easy-to-read, fast-moving and plausible story that will undoubtedly inspire the DevOps community. So far so good. But as a facilitator of GamingWorks’ The Phoenix Project DevOps game, it got me thinking how I can incorporate the Five Ideals (and more) into this highly-interactive game.

    My first analysis is encouraging. Starting with the last Ideal and working backwards, the game–that is based on the book–has strong focus on the customer while at the same time ensuring that technical debt (another key topic in the book) is kept under control. Psychological safety comes up a lot in the game–when it’s clear that somebody isn’t really participating, there’s a time out to discuss the importance of people feeling safe to share their concerns without fear for their reputation and position. Continual improvement is hard-wired into the game, with retrospectives after each sprint, leading to hypotheses and experiments for the next sprint. As for focus, flow and joy in our work, we encourage the participants to visualize the value stream and see how work flows from role to role. There’s also plenty of fun, particularly when they hit their revenue targets.

    Locality and simplicity in our code and organization is probably the least dominant Ideal in the game–it’s a non-technical game so there’s no coding, and it’s a small team so almost by definition it’s local. We do discuss, however, the challenge of scaling–which is when this Ideal comes into play. I’ll experiment with the Five Ideals in my next The Phoenix Project games so watch out for further blogs.

    The Five Ideals triggered another association. I was lead editor of the upcoming ITIL 4 High velocity IT module. This is about how digitally-enabled organizations place higher demands on IT, requiring different ways of thinking and working. One of my contributions is the concept of five Key Behavior Patterns:

    1. Help get customers’ jobs done–helping customers become who they seek to become.
    2. Keep raising the bar–taking things to a significantly higher level.
    3. Trust and be trusted–as professional knowledge workers in a healthy workplace.
    4. Accept ambiguity and uncertainty–not scared of not knowing an answer.
    5. Commit to continual learning–all as part of their daily work.

    I believe many practitioners want to work in organizations that foster these behaviors. As such, I see them as aspirations. As marketing legend Seth Godin said, “people like us do things like this.” You can see the similarities with the Ideals: 

    • “Help get customers’ jobs done” equates with “A relentless focus on our customer.”
    • “Keep raising the bar” and “Commit to continual learning” are close to “Enablement of improvement and achievement.”
    • “Trust and be trusted” is the same as “A culture of psychological safety.”

    It is so encouraging to see similar thoughts emerging within different communities. This will hopefully break down the silos that exist in the IT industry and bring us all closer together. All too often, conferences and communities are organized by specialization. They stick safely to themselves and reinforce their stereotypical stories about other disciplines. Praise and power to the rebels who practice what they preach (T-shaping and multi-functionality) and liaise with their industry colleagues, organize joint conferences etc. Evolution thrives on diversity and it would be a shame to see inbreeding in communities, leading to extinction. Let’s not only read The Unicorn Project but also do something useful with it.

    — Mark Smalley

  • Top DevOps Challenges at DOES19

    Top DevOps Challenges at DOES19

    I recently attended the prestigious DevOps Enterprise Summit in London. During the three-day event, I asked people what their major DevOps transformation challenge is. I wanted to examine these at global events, asking the same question.

    I was GamingWorks’ booth boy at the event, which gave me a chance to ask a lot of delegates visiting the stand.

    Here is a summary of what they said, with my commentary based on what I have picked up on my travels as The IT Paradigmologist.

    Business Value

    • Understanding the link between IT work and the business strategy.
    • Seeing the whole end-to-end picture (visibility, transparency).
    • Measuring the right things—team performance in terms of business outcomes.

    Commentary: Not only do IT people have difficultly understanding the business value of their work, they often are poor at articulating it to business executives. My DASA white paper, “The Business Value of DevOps,” and accompanying webinar elaborate on the topic.

    Governance

    • Finding the right balance in standardization across teams.

    Commentary: Governance is such a tricky topic. What do people mean by it in the first place? How negotiable should the boundaries be? Particularly in complex and therefore unpredictable systems, professionals need to make judgment calls and act for the best. Regarding standardization, the question is always about value: Does standardization and centralization lead to significant improvements in results without introducing frustrating bureaucracy? Otherwise, you’re better off letting the individual teams decide for themselves what is most effective for their value streams. Yes, it might be more expensive than one-size-fits-all, but the benefits usually outweigh the costs.

    Velocity

    • Doing things quickly while maintaining quality.

    Commentary: It’s a question of balance. Not only speed and quality (depending how you define it, of course), but also resilient operations, co-created value and assured conformance. I like the Deloitte #BVSSH way of putting it: Better, value, sooner, safer and happier.

    Value Streams

    • Breaking down silos.
    • Collaborating better between silos.
    • Giving more autonomy.
    • Integrating DevOps parts in a predominantly non-DevOps value stream and vice versa.

    Commentary: On the conference scene, almost everybody has an idea of what value streams are. Visit an average IT department though, and for most people it’s an alien concept. We live in a bubble. You have to take a few steps back and start from where they are. Take it step by step. Collaboration seems to be one of the top challenges as confirmed by the recent DOI skills survey, which had this as a top soft skill. It may be a soft skill but it is hard to achieve. The article “DevOps and Collaboration: Fraternizing with the Enemy” provides some guidance on collaboration.

    Ops

    • Discovering a new way of doing ops.
    • Shifting from old ops to new ops.

    Commentary: This is a very hot topic. Witness the promising changes in ITIL 4. Less process, more heuristics, more value-orientation (for instance, value streams and co-creation with the service consumer) and more human. It’s very encouraging to see how DevOps communities—some more enlightened than others—are developing their ops capabilities to restore the balance. But ops work differs fundamentally from dev work, and that has to be reflected in the way of working.

    Organizational Change

    • After the initial enthusiasm, “what’s next and how?”
    • Overcoming resistance to change and inertia in general.
    • Accepting the consequences of doing DevOps.
    • Unlearning 30 years of doing the same thing.
    • Learning quickly.
    • Developing skills to transform.
    • Assessing the risk of transformation.
    • Sharing (and learning from others’) practices.
    • Upscaling.

    Commentary: There is too much lip service and too little commitment. There are notable exceptions, but too many people are looking for the quick fix and believing they’ll find it. Good luck. As Taiichi Ohno said, “You have to think for yourself and face your own difficulties instead of trying to borrow wisdom.” If you don’t know who Ohno-san is, that’s a good place to start. If you’re serious, take a look at Paul Wilkinson’s astute observations about challenges and enablers for DevOps success at DOES18 USA. You’ll notice many similarities with my findings at DOES19 UK.

    Culture and Emotions

    • Getting enough diversity in the team.
    • Getting different personalities to work together.
    • Trusting and being trusted.
    • Feeling non-DevOps teams are worth less, but not worthless.

    Commentary: More on culture and people can be had on the DOES18 blog, but it is encouraging that people are actually talking about this more often. It’s something that almost always crops up in The Phoenix Project business simulations that I facilitate for organizations. Topics such as psychological safety: whether you feel comfortable being and expressing who you are. So, do you? Dr. Christina Maslach referred to the toxicity of some workplaces with the analogy, “You want less toxic mines, not more resilient canaries.” Work-in-progress.

    Tooling

    • Understanding which tools are around (tool confusion).
    • Integrating and then orchestrating tools.

    Commentary: Finally a topic I know little about, but I wholeheartedly endorse many vendors’ socks.

    — Mark Smalley

  • The Third Way of DevOps: Stacking the Cards in Your Favor

    The Third Way of DevOps: Stacking the Cards in Your Favor

    In the Third Way of DevOps, change is as much attitude as it is behavior

    In our first post, “The Third Way of DevOps – From Knowing to Being,” we shared our thoughts on effectively applying knowledge to put the Three Ways of DevOps into practice. This blog explores a complementary dimension: How to build confidence when faced with a seemingly impossible task.

    This is the all-too-familiar setting. You’ve seen an opportunity to improve things and genuinely want to do something about it. But you soon feel the clarity and anticipation draining out of you. First there’s the pressure of the day job. Then there’s the inertia of your co-workers, who are oblivious of or indifferent or hostile to your ideas. And finally, as if these concerns weren’t enough, you’re faced with the difficulty of unlearning old habits and developing new ones. In short, you don’t take action on what you have learned and know.

    Self-efficacy

    Expressed in the somewhat abstract language of the theories of Planned Behavior and Reasoned Action, there’s a gap between behavioral intention and actual behavior. A plausible explanation for the gap is low self-efficacy, defined as the conviction that one can successfully execute the behavior required to produce desired outcomes. It’s the belief we have in our own abilities, specifically our ability to meet the challenges ahead of us and complete a task successfully. This is a crucial precondition because investigations have shown that peoples’ behavior is strongly influenced by their confidence in their ability to execute that behavior.

    If-Then-Else

    So why doubt your ability to change? Well, when a change seems large, the gut reaction is to feel the need to come up with a project plan. Because a plan creates the confidence that when the steps are taken, the desired results will be achieved. Without a plan, we’d be irresponsible risk-takers. That’s how we’ve been taught to think. And rightly so—at least, in a predictable environment, where you can determine which steps will have which effects. If you work with IT, you are likely to think in terms of If-Then-Else. This is how we would like to believe IT always works. Predictably.

    If-Then-Maybe

    However—and this might be the biggest “however” you’ve come across for a while—things are not always predictable. Not unpredictable in the sense that it should have worked but something just went wrong because we didn’t do enough homework; unpredictable as in simply unknowable. Unpredictable as in possibly seeing a pattern of behavior in hindsight, but never having been able to predict it, let alone control it. Unpredictable as in “complex adaptive systems,” as they are referred to in the world of complexity thinking. It’s no longer If-Then-Else; the name of the game is If-Then-Maybe.

    Complexity Thinking 

    Complex adaptive systems are all around us but if you’ve been used to thinking that things are—or could or should be—predictable, you tend not to see them for what they are: one of kinds of systems that exist in nature. The Cynefin sense-making framework describes systems in terms of five domains: obvious, complicated, complex, chaotic and disorder. Obvious and complicated are both predictable domains, where something in the complicated domain needs a bit of work to discover the predictability than when it is obvious. Complex and chaotic are unpredictable domains, the main difference being that something chaotic is dangerously unpredictable and therefore needs direct action. There is a fifth domain: disorder. You are in this domain when you don’t know which of the other four domains best describes the current situation. A word of warning: People’s cognitive bias will often lead them to think that they are in their usual domain, in which they feel most comfortable.

    Step by Step 

    The way to introduce changes in complex systems successfully is to take it step by step. Because you can’t predict the results of a step, you have to closely monitor what effects—both desired and less so—each step creates. Then, based on your assessment of the new situation, you determine which next step to take. Rather than moving in a straight line toward a “to be” end state, you move each step to the “adjacent possible.” You make good use of the disposition of the system; in other words, where the energy is tending to flow.

    No Big Answers, Just Little Questions

    So, it’s not a case of looking for the big answer. It’s about a series of small questions. The Toyota Kata approach recommends asking ourselves (and others) these questions:

    • What are we trying to achieve?
    • Where are we now?
    • What obstacle is now in our way?
    • What’s our next step, and what do we expect?
    • When can we see what we’ve learned from taking that step?

    A key concept is that we should work towards the next “target condition.” This is an interim goal on the way to whatever we want to achieve. It just describes where you want to be next, not how to get there. It labels the future set of circumstances that lie just beyond our current level of understanding. It will typically have to be achieved between a relatively short period between a week and a few months; otherwise, it will be ineffective. How we will get there will emerge though the process of experimentation.

    Stack the Cards in Your Favor 

    So the next time you feel inspired to make a (little) difference, don’t be discouraged by the prospect of having to think everything through in detail. This is often even contra-productive. The liberating realization that you can take things step by step, is good for your self-efficacy, increasing the chances of actually achieving results.

    This article was co-authored by Mike Orzen.

    — Mark Smalley