devopsy.kinsta.cloud

Tag: simulation

  • Accenture Cloud Simulation Platform Advances DevOps

    Accenture Cloud Simulation Platform Advances DevOps

    Accenture has launched a cloud simulation service through which DevOps teams can better determine which workloads will run best on different cloud computing environments.

    Kishore Durg, growth and strategy lead for cloud at Accenture Technology Services, said myNAV is a cloud service created by Accenture that leverages machine learning algorithms and other forms of artificial intelligence (AI) to leverage a knowledge base Accenture developed during its decade-plus working on cloud projects. DevOps teams can leverage that expertise without requiring Accenture personnel onsite to account for deployment variables such as technology infrastructure, types of application workloads, data, operational models and even business outcomes before committing to a specific cloud computing platform, he said.

    DevOps teams can also employ myNAV to engage in canary testing of application workloads, Durg added.

    DevOps teams employing myNAV are guided through a three-step process that starts with scanning and assessing the existing infrastructure, application and data landscape to recommend the most appropriate cloud architecture. An AI engine developed by Accenture then accesses a knowledge base curated by Accenture to come up with a recommended enterprise architecture. Finally, simulation and testing tools are applied to make sure the IT environment will scale as required.

    At the end of the process the DevOps team is presented with a bill of materials that resembles the bill of materials that might be presented when building a house, said Durg.

    Despite commodity pricing models, not all cloud computing platforms are created equal. Various attributes of application workloads lend themselves better to different attributes of cloud computing platforms. It’s not uncommon for IT organizations to find themselves rolling back applications from a cloud platform after encountering performance issues or discovering that cost of running a specific type of application on a cloud exceeded their available budget.

    Durg said 3-D visualization tools make it a lot easier to determine which cloud platform to employ and derive the maximum value from that investment by ensuring the cloud environment chosen is optimized for that application workload. Accenture research suggests that as many as two-thirds of organizations are not getting the maximum value from their cloud investments, he noted, and most of those issues stem from the cloud platform being poorly configured, added Durg.

    Whether by accident or deliberate, most IT organizations are employing multiple clouds to build and deploy applications, but their cloud platform selection process is often haphazard. Developers often default to the cloud platform that is easiest for them to access, which could create cloud platform lock-in. Cloud simulation platforms make it easier for the entire IT team to better appreciate the trade-offs in selecting one cloud platform over another.

    Of course, most IT teams would like to unify the management of multiple clouds under a single console through which they can more easily play one service provider off against another using a hybrid cloud computing model. Until that day arrives, however, most IT organizations will find it advantageous to know as much as possible about any cloud platform before making a decision they may come to regret.

    — Mike Vizard

  • The Power of a Game: What I Learned from Facilitating The Phoenix Project Simulation

    The Power of a Game: What I Learned from Facilitating The Phoenix Project Simulation

    I recently had the opportunity to become certified to lead a simulation based on the best-selling IT book, “The Phoenix Project.” The Phoenix Project simulation is not a product as much as it is an experience. The realistic scenarios, challenges and pain points embedded in the game built a creative tension in a safe environment and allowed everyone (including me) to discover new insights into applying DevOps to improve flow throughout the value stream—from the business request through IT and to customers.

    DevOps and Agile practices are built on the back of Lean principles that go back decades before the Toyota Production System. As someone who attempted to apply Lean to IT long before DevOps came into existence, I have always said that DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. I was fortunate to meet with Gene Kim many times while he was writing “The Phoenix Project.” We always talked about Lean thinking, Lean systems and Lean tools. Those discussions eventually morphed into The Three Ways—the core principles of DevOps.

    Alignment with the Business Changes the Feel of Work

    The simulation put people in a position where it was easy to see and feel the impact of not being aligned with business and not being coordinated with all the elements of it (AppDev, engineering, IT Ops, change management, etc.). In each round, the team was able to reflect and learn from the experience and experiment with new ways of working. What we all experienced was profound: The DevOps principles, systems and tools are effective only when the team directly experiences the frustration of a broken work system and they work together to solve the problem.

    It was amazing to see how quickly people took on the personas of the functional role they had been assigned. The woman who took on the role of retail operations—you may remember Sarah in “The Phoenix Project”—became rather aggressive as she demanded results. The CISO—John in the book—constantly nagged people about SOX-404 issues. And of course, the CEO was a royal pain to everyone. Although we all knew this was a simulation game, everyone reported the stress and tension they felt as we embarked on round one with no real plan of how we were going to transform into a DevOps team.

    You Can’t Improve What You Can’t See

    Among the chaos of trying to get the work done, it became instantly apparent that the team had no visibility of all the work or priorities. True to life, there was more work that our people could handle so we needed a way to see the work, compare it to our capacity to do the work, identify trade-offs and then work with the business and other stakeholders to set priorities. Once the team was able to accomplish this (through some trial and error) we all could feel the alignment of purpose, see the smiles on people’s faces as we created value and feel what collaboration between silos is really like.

    This discovery was just the tip of the iceberg. As a coach and facilitator, I was able to ask the team questions that positioned them to reflect on what had just happened and see within themselves additional changes that needed to take place to improve the quality, speed and volume of our deployments. Some of the other topics, which were experienced and later expanded on, include:

    • A recipe for coordination among silos.
    • Making time for improvement, learning and technical debt.
    • DevOps without Value Stream Mapping can be hazardous to your health.

    At the end of the day, DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. The Phoenix Project Simulation creates an environment to give everyone that experience. From there, they return to work and begin their journey.

    — Mike Orzen

  • Simulating DevOps to Discover the ‘Culture Thingy’

    Simulating DevOps to Discover the ‘Culture Thingy’

    DevOps … is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably. — Wikipedia

    We are all, I believe, familiar with the fact that culture is an important factor when adopting DevOps.

    Groan!

    Most engineers and technologists are probably tired of having the “C” word thrown at them: culture.

    Because let’s be brutally honest: DevOps value comes from the automation stuff. The latest “State of DevOps” report confirmed “that automation is a key differentiator for organizations.” All the shiny technology that supports the “continuous-es”: continuous integration, continuous deployment, continuous delivery, with infrastructure as code and spinning up servers in the cloud and then collapsing them when no longer needed, with other cool technology concepts such as containers, microservices and a whole array of sexy build, test and monitoring tools. Just when we start getting excited about it and drooling about the new tools we get to play with, somebody else pipes up with that culture. stuff again …

    Groan. Just let us get on and do IT!

    But equally, probably the most important part of the “continuous-es” is continual learning and improvement, because again, let’s be honest: The real value of DevOps takes years to realize. It is not a one-time, overnight migration with a simple press on the ‘Install DevOps” button. It is an iterative exercise involving people from the end-to-end value stream; therefore, it is all about continual experimentation, learning and improvement—and doing it with people from different siloes who don’t usually like talking to each other. So, it’s a “cultural thingy.”

    If it’s not somebody talking about culture and collaboration and communication, it’s one of those “frameworky-geeks” talking about agile, scrum, lean thinking and IT service management (ITSM) and how we need “flow,” “process engineering,” “voice of the customer,” “kaizan,”kanban,” and a whole host of other Japanese-zen-like mysterious terms which only consultants are qualified to talk about and do, as they are the enlightened-ones (probably with their own secret handshake or Doctor Spock type split fingered salute!).

    “DevOps is a philosophical movement,” we hear. Now, if there are two things that I wouldn’t normally associate with each other it is technical engineers (I was one!) and philosophy. Although I do remember trying to stare down a server once, hoping by the power of positive thought and sheer will power for it to start working again; the alternative was a sledgehammer …

    Where was I? Oh, yes. So what are some of these “culture things” we should care about, apart from the “Wall of Confusion” that everybody keeps talking about? “We’re not confused! It’s the other lot on the other side of the wall that don’t get it!”

    Below are some of the key discoveries relating to the culture, or soft skills, issues that teams experience and recognize during the DevOps business simulation, “The Phoenix Project.” Before you start getting all excited again, this is not a computer game in which you can win points by zapping Ops people who get in the way or setting phasers to stun when you see a developer about to release some more untested code or beam up an uppity product owner who tells you that what you coded may have been what they asked for but isn’t what they were thinking. This business simulation is a dynamic, interactive, classroom-based workshop in which people have to get together—face to face—and, well, communicate and collaborate! The simulation workshop has been performed with literally hundreds of DevOps teams across the globe and across different industries, and is used to support DevOps training and to help empower teams. (see a blog posted on this site).

    What are Some of These Key Learning Points and Takeaways?

    I have mapped these discoveries onto the DASA (DevOps and Agile Skills Association) competence model, particularly the “Skills & Behaviors” area.

    DASA has developed the competence model to help organizations assess and develop the right knowledge and skills within their DevOps teams. The competence model is based upon industry feedback from practicing organizations, and helps organizations assess their level in terms of Novice, Competent, Proficient, Expert and Master. It looks at four key Skills & Behavior areas and eight Knowledge areas.

    Skills & Behavior Areas: Courage, Team-building, DevOps Leadership, Continuous Improvement.

    Simulation exercise discoveries for Courage:

    • “Feedback” is often seen as negative. People don’t like or dare to give feedback. It is perceived as personal, as criticism and often as blame. A blame culture makes it even more difficult to create open, honest feedback which is a barrier to learning and improvement.
    • “Fail fast” often means “blame fast,” or “pass the blame.” A blame culture creates a lack of trust and willingness to experiment for “fear of failure.” Often in the simulations if things go wrong, people revert to asking,”Whose fault was that?” rather than asking, “What happened? How can we stop that happening again?”
    • Sharing knowledge. Still in many organizations, knowledge is power; people don’t like to share knowledge or don’t think others are capable of using knowledge. A critical aspect of DevOps is multi-functional teams with broad shared skills and knowledge.

    Simulation exercise discoveries for Team-building:

    • Teams are unaware of the need for active listening, confirmation of agreements and decisions and verifying “assumptions”—many mistakes are the results of “assumicide” and poor understanding, which causes disruptions and excessive hand-off moments to gain the right information resulting in waste, delays and rework.
    • Ownership, responsibility and being proactive. Many IT people wait to be told what to do. Many people don’t like to admit they don’t know or that they need help. others don’t actively seek out and ask, “How can I help,” asking upstream and downstream, “What do you need from me to be able to do your job?”
    • Many teams have an aversion to getting together as they have poor experiences of pointless meetings with lots of talking and then not a lot of decisions being made or action being taken.
    • Many teams don’t set for themselves goals for a meeting or learning objectives from a training session. They do not ask themselves, “What do I need to take away from this session?” They often don’t ask, “What do you expect from me?” “What should my contribution be?” They often cannot answer the question, “What problem do you want to be able to solve after attending this?” Many times in a session people say, “I was told to come.”
    • Silo thinking: Many teams still think from siloes, e.g the technology team they are in or the development team, and don’t think end-to-end. They are building and supporting a technology solution and not managing end-to-end business value.

    Simulation exercise discoveries for DevOps Leadership:

    • When there are managers in the simulation, people often sit back and wait to be told or managers feel they must come up with the solution and give instructions.
    • Managers have difficulty letting go, and sometimes don’t have the patience to let teams learn and improve themselves.
    • Managers fear experimentation and failure, as they may be blamed.
    • Managers often blame teams for not becoming self-steering, becoming self-empowered or for not taking ownership, yet they do not help coach and empower teams.
    • Often managers are unable to answer the “why” question: “Why are we doing DevOps?” If managers do not know then how can they expect team members to know?

    Simulation exercise discoveries for Continuous Improvement:

    • Teams are poor at reflecting, analyzing, thinking and coming up with solutions. They lack skills in “problem thinking,” also in terms of Kolb learning cycle. Often they recognize one symptom and then leap to conclusions and solutions.
    • Lack of skills in facilitating a stand-up meeting. See the five key team skills mentioned by Jan Schilt on devopsy.kinsta.cloud. These skills are: The stand-up; Facilitating a retrospective; Managing the Kanban (Visual Management System); Managing the Andon: (and swarming problems); and Collaboration.
    • Many teams struggle to record issues in their work, such as a CSI (continual service improvement) register. They agree it is a good idea, then nobody does it, or if they do then nobody looks at the list again. If I ask, “Who owns this?“ they usually look at each other the point to the business or IT manager. There is no sense of ownership for improvements. This confirmed our own mini-survey of 650 organizations: Less than 20 percent had formal CSI.
    • With improvements, teams wait for somebody to say, “You will do this,” rather than suggest, “I can pick up that.” Improvements mean more work and teams are already busy enough, allocating time for improvements and rewarding improvements are not valued.
    • Teams often say they do NOT reserve time to reflect and discuss improvements. They are often too busy and managers do not stimulate, or allow them to reserve time for thinking and acting on improvements to the way of working. Priority is given to completing the ever growing backlog of work.

    Knowledge Areas

    Business Value Optimization:

    • Many technology people do not understand the business they are supporting, the critical business activities and business times, how a system delivers value to the business, what happens at a given time if a critical IT feature, function or technology is not available. There is a technology mindset as opposed to a business mindset.
    • Many technology teams have never seen a user or seen how users or customers use and experience the technology. Many think they don’t need to know this. This is a top-scoring ABC (Attitude, Behavior, Culture) card worldwide in global workshops and has been for 15 years. “IT has too little understanding of business impact and priority,” and is also a top concern for business managers.
    • In every single simulation and workshop I conduct worldwide, the issue of prioritization is raised, again in relation to business impact and business value, yet all teams recognize a growing pressure on scarce resources, a dilemma between “innovation” and “maintenance work” and a need for clear prioritization.
    • Product managers in teams are often unaware of technical debt and its impact. ITSM teams have difficulty quantifying the impact of technical debt and how this impacts current and future business plans.

    And finally, the latest “State of DevOps” report also confirmed the importance of skills and behaviors, particularly what it calls “Transformational Leadership”: “By 2020, half of the CIOs who have not transformed their teams’ capabilities will be displaced from their organizations’ digital leadership teams.” The survey continues: “Leaders are the ones who set the tone of the organization, and reinforce the desired cultural norms.” Oh! There is that “C” word again. Are we ever to escape it?

    What are the characteristics of a transformational leader, according to the State of DevOps findings?
    Vision, inspirational communication, intellectual stimulation (challenges people to think about problems in new ways), supportive leadership, personal recognition. These characteristics are one of the reasons why leadership is one of the four key Skills & Behaviors in the DASA competence model.

    Conclusion

    A simulation experience helps make the “C” word become a reality. Delegates can translate it from a buzzword into meaningful behavior. The simulation allows delegates to see, feel and experience the benefits of communication and collaboration, while helping them to translate DevOps theory into practice.

    As a leader, you can use a simulation exercise as an instrument to communicate your vision in an inspirational way. End-to-end stakeholders can be brought together and stimulated to explore and develop DevOps skills, knowledge and competences together. At the end of the simulation experience teams have been empowered to capture takeaways they want to apply.  As a leader, you can support them in translating the captured takeaways into real behavior and helping shape together a DevOps culture for your organization.

    About the Author / Paul Wilkinson

    Paul has been actively involved in the IT industry for more than 35 years. Fulfilling a wide range of roles ranging from computer operator to IT infrastructure operations manager. He was co-author of the ITIL publication, “Planning to Implement IT Service Management,” and was a member of the ITIL advisory group for ITIL Version 3, and the architects team for ITIL Practitioner. Paul is also co-director and owner of GamingWorks, the company that developed the internationally renowned “Apollo 13 – an ITSM case experience” ITSM simulation game and most recently the “Phoenix Project – DevOps business simulation,” which is based upon the Phoenix Project book . He was also co-author and developer of the “ABC of ICT (The Attitude, Behavior and Culture of ICT)” publications, having conducted ABC workshops and simulation workshops with delegates representing more than 4,000 organizations worldwide. Follow him on Twitter or connect with him on LinkedIn.

  • Simulation: The ‘Aha’ Moment for DevOps Adoption

    Simulation: The ‘Aha’ Moment for DevOps Adoption

    Every IT transformation requires that people, process and technology align and work together to achieve success. As organizations begin to appreciate the benefits of a DevOps approach and look to change to a DevOps model of software development and release, there will be significant pressure on people, process and technology to support that change properly.

    The technology and process changes required to enable DevOps to work efficiently shouldn’t be underestimated. Considerable time and investment is required in embracing the automation technologies that support a proper DevOps environment, and in developing the processes that make best use of that technology.

    But DevOps cannot work unless your people are ready to change. Development teams and IT operations—who traditionally have worked in silos—must work together, integrate seamlessly and understand not only their roles and responsibilities within the new environment but also the roles and responsibilities of those around them.

    And therefore, like every change, the real key to success is your people.

    Creating Successful Change

    The benefits of taking a DevOps approach are numerous: By moving toward more frequent delivery with reduced elements of change, you lower risk and increase system stability. Although automation is costly to implement, it allows teams to work far more efficiently, increases reuse, reduces errors and brings development teams closer to the customer. New functionality released continually and rapidly can be validated in the market, feedback can be received, lessons can be learned and improvements implemented quickly.

    But in making such a radical cultural shift, how do you ensure you change the mindset of people who have been used to working in a certain way? How do you provide your people with the helicopter view of what that future state will be, instill in them your fervor for change and provide them with the understanding and motivation necessary to embrace new ways of working? How do you ensure everyone is rowing in the same direction? Because without that, your change—already difficult and challenging—will become impossible.

    The Key to Change

    The key to any successful change is communicating your vision to your people. But providing your staff with a clear vision of what that future state could be is enormously difficult. You can outline the benefits of change, explain to them what good will look like, tell them what is in it for them, and all of these are hugely important.

    But there is no substitute for allowing people to actually feel what your future state will be like.

    Nothing compares to parachuting them into a situation where they can work through the changes required in a risk-free environment, experience the pitfalls and live the successes. As you move them to a fully functioning and productive DevOps environment, you will accelerate buy-in from your team rapidly, and give them a much more profound understanding of your vision and future state.

    The Power of Simulation

    Simulation training is one of the most effective tools to explain complex concepts and operating models quickly and convincingly. A presentation on DevOps—or almost any other topic—is not a productive method of showing someone the difference it can make to their work or their business. It’s the difference between reading a script and performing a play. More and more, companies are using simulation training as a shortcut to inform, educate and convince their teams of the value of large-scale organizational change—and DevOps is a prime example. 

    One of the key benefits of the simulation model is that people learn together. Your team learns at the same pace, working toward the same goals—and, as a result, they collectively show each other the value of change. With a traditional change program you need each employee to go on his or her own journey to recognize and adopt your vision. With a group simulation you take everyone present down the road toward a collective “aha” moment. Once that moment has happened you have an instant group of advocates who can go out to the business together and begin to effect change on a much more fundamental level.

    Simulation Brings Agility to Adoption

    Providing a simulated environment in which to train is not new; it has been used extensively and successfully by the military for decades. Commercial pilots train on simulators to provide them with as close to a real-world experience as possible of some of the life and death decisions they may need to make in an emergency. They understand the power of experiential learning.

    Simulating a DevOps model brings that power of experiential learning to your business, allowing you to immerse your people in a concentrated and deeply focused environment where they face the same challenges as they will in the real world.

    In one short morning they get to experience building a culture of DevOps themselves, making mistakes, understanding them and learning from them. It demonstrates the business value and positive impact of a DevOps approach in only a few hours, and can accelerate the adoption of DevOps across the enterprise, successfully turning DevOps opponents into advocates.

    In a world where the quality of your software can make or break your organization, it is critical to create an environment where developers and operations are not only aligned and more efficient, but also empowered and able to concentrate on developing and releasing products that add the most value to the business.

    Rome wasn’t built in a day, and you can’t effect convincing organizational change in a single morning. However, by immersing your team in a simulation, you can take a giant step forward and create a team of advocates who will go out and sell your vision for you.

    About the Author/Andrew Macintosh

    A_Macintosh_PhotoAndrew Macintosh is a Creative Solutions Director for G2G3. He works with clients across the globe, helping to understand requirements and craft technology based solutions to engage staff and customers, internally and externally. Prior to joining G2G3 Andrew ran a production company and worked within the TV industry for 12 years.