devopsy.kinsta.cloud

Category: DevOps Culture

  • Agile QA at Scale: Software Testing Strategies for Enterprise Teams

    Agile QA at Scale: Software Testing Strategies for Enterprise Teams

    Change is hard; it’s a universal truth not many people would disagree with. When you’re forcing (or strongly encouraging) change in a group of people, it’s especially hard. Even if that group is small, there’s bound to be miscommunication, disagreement and other friction points that make the change hard to implement.

    Now, multiply those difficulties by a factor of five. Now 10, 20 and so forth. This is the challenge of growing and expanding an organization. While you need to bring more people on board to fuel your growth, build a better product or improve the leadership, you also need to manage the complexity introduced by a skyrocketing headcount.

    More and more teams are accepting the challenge of switching to agile QA because it saves time, improves team collaboration and results in a superior product in a consistent, repeatable way. But most of the how-to articles and strategy guides out there only focus on small teams. What about the enterprise team ready to make the switch?

    Let’s look at a few software testing strategies for enterprise teams who have—or are in the process of—adopting agile QA in their organization.

    Outline a QA Strategy that Is Scalable

    Scalability starts early. You don’t want to set off running with a strategy that doesn’t fit your current team or is unable to expand with your team as it grows in the future. It’s key to adopt an approach that is flexible in all areas, from the technical aspects (tools and infrastructure) to team hierarchy and how resources are managed. If you don’t have a QA expert in-house, you may consider hiring a QA vendor to mentor you on testing approach, scalability best practices and team structuring.

    Bring on the Right Skill Sets

    Know what your business priorities are, what types of skills and technical expertise those priorities require and hire the right team for the job. With a solid team in place, you can scale up or down as needed. It helps to bring in both generalists (people who can handle a bunch of different domains) and specialists (people with a niche focus or specialty area). As you grow, your rock-star engineers will, too—they’ll move into management roles, continuing to motivate, lead and challenge their direct reports.

    Choose Metrics that Make Sense

    If you don’t measure progress and team output, you won’t know when it’s time to scale—or in which area that scaling is required. Be sure to invest time and care into the process of defining your success metrics, as they’ll have big implications for how your team is structured and how it grows in the future. Also be aware many success metrics focus too narrowly on code coverage and the number of tests executed. These are important numbers, but not as important as the overall quality of the product, which should be your “North Star” metric.

    Automate What You Can

    One of the easiest ways to scale without immediately adding headcount is to invest in automation testing. By automating regression testing and other intensively manual tests, you can free up engineers to work on higher priority projects, save more of the team’s time and cut resourcing costs. Plus, automation can help improve the quality of the product by reducing the number of human errors.

    No experience with automation testing? There are QA vendors out there offering expert automation teams who can learn your product, culture and processes in no time flat.

    Monitor and Maintain

    If you can spare it, devoting headcount specifically to monitoring the errors and alerts that arise during testing can help expedite the rest of the team’s work. When engineers don’t have to go back and work on every little fix or patch, they can focus on driving through their higher priority workload. Nitpicking the small stuff just isn’t feasible at the enterprise level, especially if you’re employing gifted and talented engineers.

    Here’s What You Need to Know

    1. How to Scale Your QA Team Effectively
      • Involve QA as early as possible
      • Design effective test strategies
      • Focus less on narrow metrics; more on product quality
      • Switch to smaller, more frequent releases
      • Test based on real-world user experiences
    2. Attributes of Agile QA at Scale
      • Automation is a part of the process
      • Engineers take ownership of their modules
      • Quality is top priority (“North Star”) of the whole team
    3. Strategies for Scaling QA
      • Understanding business priorities
      • Building a skilled team that reflects those priorities
      • Creating a roadmap for troubleshooting quality issues
      • Implementing technical and managerial strategies that scale

    Wrapping Up

    Everyone knows change is hard, especially when it requires people to work differently, work harder or work together in ways that are new, inefficient (only at first) and potentially uncomfortable.

    Successfully scaling agile QA is one of the best ways to ensure you’re consistently delivering a quality product to market. No wonder why teams small, large and enterprise-level are taking on the challenge—and with these strategies, you can too.

    — Anand Ramakrishnan

  • Radical Transparency in DevOps and ITSM Helps Achieve Excellent Customer Experience

    Radical Transparency in DevOps and ITSM Helps Achieve Excellent Customer Experience

    Here’s what I’ve noticed after spending several years in service management: DevOps is coming up more in the conversations I’m having with service desk leaders. Usually, these conversations start with one of the similar questions: DevOps is going to be the death of ITSM, correct? Alternatively, some consider DevOps as a challenge, and ITSM doesn’t seem so relevant because you don’t have in-house development going on.

    I always answer these questions in the same way: ITSM is relevant, and DevOps is not a threat to it. There’s more to it, however. ITSM professionals can still achieve their most relevant goal–excellent customer service.

    If you allow me a moment, I’d like to offer some background as to why excellent customer service is essential for every ITSM professional, then walk through some of the ideologies or frameworks used and how they interact. I’ll close this piece by discussing what radical transparency means in practice and how it can help you achieve an excellent customer experience.

    Some Background

    When discussing DevOps, we usually see three parts: Development, operations and the actual business. The business demands different things from both development and operations. Development teams are asked to push out code as fast as they can, and operations teams must keep the existing services available and make sure everything is stable. Development is trying to fulfill as many business needs as fast as they can, while the operations team is accountable if things go wrong.

    These might be extremes, but these are the traditional silos that have their expertise, priorities and goals, but there is no holistic overview. These internal organizations also use their way of working, based on a framework or ideology: DevOps tends to use agile, the business uses lean and ops focuses on ITIL. These ideologies can clash and compete at times.

    Because so much is happening with DevOps, we see significant developments. The speed of development and deployment is increasing, leading to additional continuous delivery advancements and technology implementations. The collaboration and breaking through walls between the development team and the operations team for deployment has come a long way within many organizations.

    Meanwhile, ITSM professionals face more and more challenges. Apart from the existing incident handling, they encounter incidents about newer, faster releases. Also, how are they supposed to deal with knowledge management, an already complicated process in itself? The increased speed of development makes it look as if they are always running behind. Getting out of that reactive approach is not getting easier.

    Customer experience and satisfaction is the number one priority in ITSM, creating quite the challenge. In ITSM, all input comes in: If things do not work at all or break down; if things do not work as expected; and if users need help to get things working. Good feedback also usually comes in via the service desk. When examining customer experience, there is a thin line in how fast you can go: If functionality is delivered too quickly, customers will not be able to use it. When delivered too slowly, customers will be unhappy about it as well.

    You can argue that a new silo comes into the picture–namely support. The support team keeps things up and running. Likewise, there are communication links between the customers and the other silos where they can filter bugs to development, info on any outages to operations and feedback on how the customer perceives the value of the functionalities to business.

    What if you don’t have in-house development? Well then, DevOps and the link with ITSM can be even more challenging, meaning you only have part of your DevOps and some of your support outsourced. For one application, perhaps you are relying on one or multiple vendors, but it might be the case that your vendor is dependent on another vendor.

    In other words, the process looks more like a plate of spaghetti than a smoothly laid smooth IT process. There are significant benefits to outsourcing, which is why we keep using outside vendors for some of our operations. In these cases, consider the shift of responsibility, the extra expertise, stability and continuity you gain. However, there are also downsides, such as loss of transparency.

    A Shift in Responsibility

    Shifting responsibility does not mean the same as a shift of accountability. Your ITSM team will still have to take ownership because even if you are not controlling everything. You have to be in control. In the end, you are still responsible for your customer experience and happiness. Customers do not want to wait two years for new features because the update of the vendor cannot take place for whatever reason. Also, it would be best if you had insight into what is going to happen for your users, and you need extra insight regarding how everything is working.

    Silos make this a challenge without outsourcing and are even more so the case when outsourcing these responsibilities. Before we move forward with solutions, let’s first take a step back and look at the frameworks and ideologies the different silos are using. As discussed, first, we have ITIL, typically used in operations.

    “ITIL is the most widely accepted approach to IT service management in the world. ITIL can help individuals and organizations use IT to realize business change, transformation, and growth,” stated Axelos on their website. It’s about aligning services to the needs of the business and supporting its processes.

    Next, we have lean, which is about maximizing customer value and minimizing waste. Lean is where value stream mapping comes in. You identify what works then look at how you can improve flow. Finally, agile, the cultural aspect of DevOps.

    At first sight, each of these processes seems contradictory, but actually, this is not the case. The key is using each of these principles correctly. For example, consider CAB, which comes out of ITIL. In many cases, the A in the acronym stands for “authorization” instead of “advisory.” Knowing that might make things much better and can open up the possibilities of automation, which is crucial to improving things.

    Likewise, some people tend to say that agile can never work in an ITSM context because it is against processes, but that’s also not true. Agile speaks to individuals and interactions over processes and tools, not without appropriate processes and tools. However, if you take a step back, you see they have more in common than you might think and some changes coming to ITIL4, for example, already address how to achieve a better correlation between the three.

    Let’s look at all of them together. Usually depicted as a horizontal value stream, but looking at it as a continuous loop, makes things a lot clearer for me.

    When you start in the business with the idea, take it through the design, code, build and test phase, then move over to the release and deploy and then we get into ITSM territory with the support and monitor stages. Where you see the blue line is where DevOps focuses mostly, so this is also where you witness the creation of a new silo: support (where ideologies or frameworks come in the picture).

    Radical Transparency

    So how do we break through these silos? Radical transparency. First of all, silos have to share their common purpose, which in the end is excellent customer experience. You can change it however you want; but in essence, that is what the business, development, operations and support all strive.

    To accomplish this, we first must know what impacts the customer experience.

    Let’s break it down: There are visible and invisible effects for the customer that can either be positive or negative. Visible results on the positive side will be features; on the negative side, defects. On the invisible side, positive things include architecture and process improvements. On the negative side, technical debt.

    For excellent customer experiences, we need to focus on the visible effects. Invisible effects must be worked on, too; if completely neglected, these will become visible at some point. The most prominent and the first focus should be on the visible effect. To do that, we need insight. If we all have the same set of information, often we all come to the same result. Getting to that same set of information requires radical transparency and also sharing information and insights.

    Shared Workload Tooling

    First disclaimer: When I talk about sharing tooling that does not necessarily mean using one tool. I will specify. I mentioned before that ITSM professionals have to know what is going to happen that might affect the customer experience. They have to be aware of which new versions are coming out and which customers are going to be or are on that version. For that reason, you need to share relevant information from your release orchestration tool to your ITSM tool. For instance, in our service management tool, we can see who is on which version via an automatic integration.

    That is a flow from DevOps through ITSM. The return flow also is essential. Any feedback that comes through your ITSM process regarding bugs has to flow back as well. So, for that, you need an integration between your ITSM and bug tracking tools. I also have seen some examples within the ITSM process where a Kanban board is used to improve collaboration between development, operations and support.

    Just making visible those tasks that impact customer experience and being able to follow up on the progress made by all stakeholders is so valuable. It also gives the support team the necessary insight to be able to communicate with the customer.

    If you are working with one or multiple vendors and dependencies there, you will want to include vendors in this as well. Moreover, that might mean you even have to tie in your and their ITSM tools.

    Another thing you want to share is customer satisfaction insights. First, measure satisfaction throughout the entire chain. That includes employee satisfaction, as well. We have seen the proof that employee satisfaction has a direct impact on customer satisfaction, so make sure you have all those data available and insightful.

    Knowledge Sharing

    Next up is sharing knowledge, which requires proper documentation. Think of federating knowledge into a knowledge base to make relevant information available to the right people. Make sure you have a good understanding of each other’s processes, and the impact they have on one another is essential. As an example, we had some challenges in collaboration with one of our hosting partners. When we sat down to discuss this with them, we found out some choices we had made in the deployment and support process, were not as reliable because we had assumed things about how the hardware had been set up and those assumptions were not correct.

    Excellent documentation and communication are key. If you have things outsourced, you want to make sure your vendor is the right partner, and you have a common understanding.

    Another important thing that should be shared is dashboards, where you can have a total overview of all parties involved and the impact they might have. You especially want to have visible what the effect is on the customer experience. It is valuable to have insight into all things that need your attention, but for your shared dashboard, focus on those things that are not going well and that have an impact on the customer experience.

    When you work with one or more suppliers, you want to make sure they are also using these dashboards and actively monitoring these. For you to be sure they use that, add that in your vendor selection criteria. The only way this works is if there is that radical transparency, where all parties involved have access to your vendors, development, operations, support, business and customers.

    Takeaways 

    Hopefully, because of this article, you’ve taken some additional perspective about where DevOps and ITSM come together, why the silos have to be broken down and how working with one or multiple vendors can be especially challenging. Also, hopefully, I’ve provided a bit of background on the various best practices, frameworks and ideologies most used and how they share commonalities. Radical transparency means breaking through the silos and how this can improve your customer experience.

    Finally, to sum it up:

    1. Make sure all parties have a common purpose and are doing everything to achieve that.
    2. Share relevant information. All words here are significant: share to achieve radical transparency, applicable because you don’t want to flood people with things that are not of use to them, and sharing too much may distract them too much. Provide just the relevant information so everyone can focus on the common purpose.
    3. If you do all that, you will produce better value for your customers, all for excellent customer experience.

    — Jeroen Boks

  • 5 Tips to Eliminate Knowledge Gaps in Dev and QA

    5 Tips to Eliminate Knowledge Gaps in Dev and QA

    To create and release high-quality software, the software development lifecycle (SDLC) was established using different roles and processes designed to work seamlessly together. This approach is of critical importance because it spans the initial planning phase, all the way through production release and monitoring.

    Roles vary within projects but typically include designers, business analysts (BA), developers, testers, scrum masters, project managers, product owners (PO) and technical architects (TA). Each one brings different expertise and skills to a project but ultimately, they are meant to collaborate and determine how to implement different aspects of the software.

    The amount of processes can also vary for projects based on team size, release schedules, availability of resources and the complexity of the software.

    What is the Knowledge Gap?

    Without a distinction of responsibilities or a roadmap that identifies who owns each task in the SDLC, everyone assumes someone else will complete the tasks. The result is that the majority of these important steps remain incomplete or undone.

    The reason this happens is because a knowledge gap exists among the team. This is especially true when teams are a mix of entry-, mid- and expert-level individuals. Sometimes, assumptions are made regarding the skill set, experience and domain knowledge that each individual brings to the project. Knowledge gaps can also develop at a more granular level, with teams using the same tools but in different ways. As an example, developers and testers might be using a single testing platform quite differently.

    As teams begin collaboration on features for the software, they may encounter the following situations:

    • Each team member has a different interpretation of the project requirements
    • Developers assume testers have their same level of technical expertise
    • A lack of ownership and assigned responsibilities among the team
    • A PO has a feature idea and each team member has different ideas for how that feature should work
    • The TA explains how a feature should be implemented using technical jargon that designers, POs, BAs and testers don’t understand
    • A tester is not allowed appropriate time to complete testing due to tight release schedules

    Identifying Knowledge Gaps

    Knowledge gaps not only negatively impact the release of high quality software, but also team morale, productivity, job satisfaction and empowerment. The first step to finding acceptable solutions is to identify exactly where a knowledge gap exists. Some questions to help teams do this include:

    • What are the common problems that occur in each phase of the SDLC?
    • What processes are in place during the requirements, design, development, testing, acceptance and release phases of the SDLC?
    • How effective is the communication between different roles in the team?
    • Are the responsibilities of each team member clearly identified?
    • How visible is the status of the project at any given time?
    • How often are release cycles pushed to accommodate for more development and testing?
    • Are the teams aware of what kind of customers are going to use the product?
    • Is the velocity of the team stable? How often does it fluctuate and by how much?

    Bridging Knowledge Gaps

    Finding gaps in a team’s knowledge is the first step. The next step is determining how to narrow the divide. The following key factors help bridge the knowledge gap in teams:

    Training

    Sufficient training and tools should be provided to help teams do their jobs better. Proper training has a domino effect on the success of the project. It helps designers understand how to design mockups so developers can effectively implement the feature; testers can attend code reviews without intimidation and use tools more effectively; developers will understand why the testability of a feature is important and understand which tools can aid the development testing effort; the scrum master can better manage project tasks; the project managers can ensure the team collaborates to meet release schedules and deadlines; and finally, stakeholders can have an overview of the project through reports that are generated using various tools.

    Visibility

    For teams to work seamlessly together, we need to ensure the results of everyone’s efforts are visible to the entire team. It is important to understand how each contribution maps to the overall goals of the project. To increase visibility, teams can consider using the following:

    1. Checklists: a list of items to be completed during each phase of the SDLC. If the items in the list are marked as done, then there is no ambiguity about which tasks need attention.
    2. Visual Dashboards: give a high-level overview of the project’s health and status. These can be created on whiteboards, easel boards or in software and during daily meetings, teams can address the dashboard to ensure everyone, including business stakeholders, are aware of the high-level project status.

    Clear Definition of Roles and Responsibilities

    Each person needs to understand his/her role on the team, as well as the tasks they must accomplish on a daily, weekly, monthly or quarterly basis. Goals, objectives and expectations for each team member should be defined and discussed with respective peers and/or managers. This eliminates confusion and increases productivity and task completion.

    Empowerment

    In an age where individuals are increasingly more technical and skilled, what they still lack in their job functions is empowerment and autonomy. Contrary to the conventional wisdom that a project needs a single leader, the leadership responsibility can be effectively divided within each role on the team. Having one point of contact each from the design, development and testing teams means each can help to lead their respective sub-teams and help to ensure everyone within the project is working toward the same goals and objectives. By operating within this structure, the whole team becomes empowered.

    Experimentation

    Once sprints are completed and knowledge gaps have been identified, the whole team should come together to discuss solutions to existing problems. Based on this discussion, the team can start experimenting with different solutions to determine what works well or doesn’t. This constant experimentation and feedback loop helps to make the team more creative and empowers them to come up with solutions that work for their organization.

    In summary, the knowledge gap has been a major obstacle for development teams in reaching their fullest potential. By identifying and reducing these gaps, teams can be more efficient and achieve faster release cycles with higher quality software.

    — Raj Subramanian

  • Best Practices for Software Change Assessment

    Best Practices for Software Change Assessment

    Business spending on enterprise software has been on a constant rise over the past decade with 64% of businesses spending more on IT operations in 2018. It is estimated that in 2019, the number will reach $462 billion worldwide. This not only includes the procurement or development of new software and digital innovations, but also investments in modifications and upgrades.

    However, implementing software changes is no easy feat. It involves serious financial investments and staffing resources, which is why it is critical to get it right. A well-implemented change assessment is a key component of every software change project. This gives decision-makers an accurate and complete understanding of the impact of the software changes and identifies potential disruptions to specific departments, functions and processes.

    There are many ways to approach and implement software change assessment. These best practices can ensure a glitch-free software change rollout.

    Use a Comprehensive Discovery and Dependency Mapping Technology

     One of the disadvantages of the modern workplace across all industries is the emergence of information silos. They can hamper growth and efficiency and cause other problems, including redundancy of effort, stalled collaboration and other missed opportunities.

    In order to break these silos, efficient application discovery and dependency mapping is a crucial step in every software change project. Unfortunately, most businesses are failing miserably in this department. A Forrester survey revealed 56% of IT managers “do not have a complete view of dependencies between applications or between applications and infrastructure.”

    The same survey revealed 30% of the IT managers think that having a complete inventory of all enterprise hardware and software in use at their organizations is critical for IT efficiency. Ironically, 42% do not collect the necessary software data, while 39% are maintaining their inventory manually.

    The disadvantages of inadequate discovery and inefficient dependency mapping include low productivity, project delays, increased overhead costs and poor team morale, among others. A key step in solving this predicament is investing in the right discovery and dependency mapping technology, which can support a solid foundation for a software change initiative or any IT project for that matter.

    A reliable, agile software solution should provide both macro and micro views. The more granular, the better. Additionally, it should be able to give IT decision-makers a consolidated view of their application stack across multiple message queues, APIs, databases, unifying codes and languages.

    Use the Seven R’s of Change Management

    One thing IT managers should realize when assessing software change is, they’re not pioneering the process. Many organizations have done it and made mistakes along the way. Experts have used these mistakes and learnings to create roadmaps for others.

    One of the most well-established resources for IT change management is the Seven R’s of Change Management conceptualized by Information Technology Infrastructure Library–a set of detailed practices for IT service management. The seven Rs represent the following questions designed to help businesses make educated decisions on how to proceed with change requests.

    1. Who raised the change?
    2. What is the reason for the change?
    3. What return will the change deliver?
    4. What risks are there if we do or do not carry out the change?
    5. What resources will be required to perform this change?
    6. Who is responsible for this change being performed?
    7. What relationships are there between this and other changes?

    While these concepts are not exclusive to software change assessment, they provide a solid framework for businesses to identify noteworthy software change projects. This is especially helpful for organizations creating their software change assessment protocols from scratch.

    Never Skip Impact Analysis

    This is especially important for software vendors who are operating on tight budgets and strict deadlines. Software change impact analysis encompasses five major areas:

    • Identifying the impact of the change request on the software development project or on a business’ IT infrastructure.
    • Determining all software resources that need to be modified to implement the requested change.
    • Calculating the cost and manpower capital needed to perform the change request.
    • Ensuring the requested change complies with internal and external regulations.
    • Eliminating or minimizing any security risks associated with the change.

    To make sure businesses covers all the bases for any software change initiative, it’s best to use a checklist or template sourced either from the technology vendor or one their IT team put together, tailored to their needs.

    Not All Changes Are Created Equal

    Today’s ever-changing business landscape dictates business technology must evolve to keep up with an organization’s shifting needs. Software changes, when implemented strategically, can help businesses achieve new heights in productivity, efficiency and profitability.

    To ensure software changes serve this purpose, IT project managers need to implement an airtight software change assessment system. With the help of technology, checklists and well-established industry best practices, organizations can quickly outline a process that yields beneficial results in the end.

    — Aditya Sharma

  • DOES London 2019: Better Value, Sooner, Safer, Happier (BVSSH)

    DOES London 2019: Better Value, Sooner, Safer, Happier (BVSSH)

    One of the key themes for this year’s DevOps Enterprise Summit in London was BV-S,S,H. It stands for Better Value, Sooner, Safer, Happier. It gets to the heart of what DevOps is trying to do: Deliver better value, sooner, safer and it results in happier people and organizations. Gene Kim mentioned this several times on stage at DOES London. I had a chance to dive a little deeper into this during my interview with Jon Smart (Deloitte) and Tom Clark (ITV).

    Both Jon and Tom are DOES veterans and I have had the chance to interview them at prior DOES events. Both of these gentlemen are two of the more thoughtful and enlightened people I have had the pleasure to meet through the years in DevOps. They both have great ideas and notions of what has worked and what hasn’t.

    In our discussion on BVSSH, “C” for cheaper also entered into the discussion. We covered some interesting points about how important cheaper is in the BVSSH discussion. Ultimately, cheaper is part of BVSSH–in my mind anyway. Tom may disagree.

    In any event, have a listen to our discussion on this. Below the interview you can find the presentations from Tom and Jon at this year’s DOES London event.


    Hope you enjoyed these great videos. For more information on how you can be at the next DOES event, check out below.

    Don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening from October 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already, and join us for a premier event for the technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    — Alan Shimel

  • Successful Transformation: Challenge the Status Quo

    Successful Transformation: Challenge the Status Quo

    If enterprises are going to succeed in their digital transformations, they need to be able to shake-up and challenge the status quo within their organizations. In fact, not being able to challenge the status quo is one of the biggest barriers to successful digital transformations. Yet, challenging the status quo is always a risky move for individuals and small groups within organizations.

    “Many large organizations are intrinsically unable to challenge the status quo and execute a large scale successful digital transformation,” said Mads Hennelund, advisor at consultancy Nextwork. “There are good reasons for this, since established bureaucratic organizations are built in order to handle complex procedures.”

    “Most CIOs, CTOs, and enterprise technology leaders want to challenge the status quo, but doing so can be dangerous because there’s no room for error,” said Laura Stringer, principal at strategic consultancy Ninth Fourth LLC. “IT leaders are under intense pressure to deliver continuity and multiple competing projects on an insufficient budget.”

    But it’s even more than just budget. It’s human nature’s near-ubiquitous aversion to change and inability to endure a number of losses on the road to find big wins. Stringer and other experts we questioned about challenging the status quo all agreed senior business and IT leadership must acknowledge the risks inherent with experimentation, while also providing a comfort level so teams can execute on transformational initiatives.

    Some initiatives will certainly fail and some will succeed. Ideally, like a portfolio of investments, while some investments will fall short, the winners will more than make up for the losses.

    “The organization needs a shift in culture to encourage all employees to become more open to changes in their daily processes and tools–digital transformation is largely about creating a culture of constant learning. Without the pressure to provide perfect continuity in current technologies, IT leaders can become more comfortable trying new things,” said Stringer.

    “This is one of the reasons why it’s common to see large organizations collaborate with smaller companies for projects,” said Hennelund. “In the financial sector we see a flourishing fintech and insurtech market around established banks and insurance companies. Companies successful in challenging their status quo are those that can navigate between these collaborations or even small in-house sub-divisions that develop new digital IT-based projects,” added Hennelund. “Putting into place a quick decision-making process is also critical.”

    This could include making it possible for stakeholders to hold meetings and move forward with their consensus without always having to get board approval.

    Such shifts in behavior require culture change. So, how do organizations and IT leaders get there?

    First, leaderships needs to make the staff feel safe taking risks and, even potentially, failing. “This only happens in an environment where current practices can be freely challenged without repercussions from upper management,” said Nabil Freij, CEO and GlobalVision International, Inc.“This means that upper management needs to be on board with digital transformation.”

    Only then is the right culture, one that can safely challenge the status quo, possible. “The right company culture is extremely important. One that embraces adopting technology, taking calculated risks, thinking outside the box, rocking the boat, challenging status quo, rejecting complacency, empowering employees to lead and overcome challenges…is the essence of enabling digital transformation,” said Freij.

    The ability to challenge the status quo all begins with building the right culture. A culture that encourages fresh thinking and intellectual risk taking. “Thirty-eight percent of CIOs think their digital strategy would fail without an innovative and experimental culture,” said Joe Garber, global head of strategy and solutions at Micro Focus.

    If so, it’s essential for organizations to build and maintain such culture.

    — George V. Hulme

  • Three Insights from the World’s Leading IT Organizations

    Three Insights from the World’s Leading IT Organizations

    IT is in a state of change on a consistent basis, but never more so than now. With the increasing importance of the digital customer experience across all industries, technology is at a new inflection point in how it can fundamentally impact executive priorities. And while nobody can speak for the direction of IT as a whole, there are a few resources so comprehensive that they’re worth reviewing when they’re released.

    Take, for example, the 2019 Harvey Nash/KPMG CIO Survey. It’s the largest global survey of CIOs with data from 3,645 respondents across 108 countries. IT leaders who participated in the survey controlled a whopping $250+ billion in annual IT budgets. The CIO survey examines how board priorities, technology adoption, skills gaps and IT leadership is changing in the age of digital business.

    Here are three insights that explain the tectonic shifts occurring in enterprise IT teams today.

    Digital Leadership: Three Steps to Becoming a Digital Native

    The 2019 Harvey Nash/KPMG CIO Survey shows only 30% of IT organizations are digital leaders. These organizations are unusually adept at “using digital technologies to advance their business strategy,” and can launch innovative solutions that generate new revenue streams, enable faster time to market and cut down operational costs. Here are three defining characteristics of what it takes to be a digital leader in 2019:

    • It’s All About Data. Data management and analytics is a core competency of leading IT organizations. Digital leaders are in a strong position to maximize the value of their organizational data by extracting, aggregating and curating the right information. This data is then used to train machine learning models, create high-value assets and deliver customer value on an ongoing basis.
    • Speed of Execution. Digital leaders are willing to either quickly double down on successful experiments or pull the plug on products that don’t deliver expected value. They are also more likely to leverage agile and DevOps practices to increase software release velocity and iterate rapidly on solutions using fast feedback loops.
    • Expansive Mindset. Digital leaders have transitioned from project thinking to product-centric innovation for creating enduring value from their software investments. They also build cross-functional teams across their business and IT silos for better collaboration and faster decision making for digital transformation initiatives.  

    What Does This Mean? CIOs will need to embrace big data analytics, agile delivery models and product-centric teams to create the right foundations for digital business. Without proper foundational investments, IT leaders will struggle to meet business demands, gain customer trust and withstand competitive pressures in the face of escalating customer expectations.

    Business-Managed IT: How Shadow IT Finally Became Respectable

    In the last decade, the adoption of cloud services led to the phenomenon of shadow IT where business units would directly buy cloud solutions without consulting IT teams. CIOs resented their growing irrelevance and tried their best to bring shadow IT under their control.

    The 2019 CIO survey confirms 64% of enterprises have made peace with business-managed IT investments. In fact, 10% of IT leaders actively endorse this approach. What factors have led IT teams to change their mind on shadow IT?

    The survey shows organizations with business-led IT scored better on key metrics than organizations without any mandate for business-managed technology spend. Business-led IT organizations delivered “better customer experiences and faster time to market for new products (52% more likely) as well as positive employee experiences (38% more likely).”

    For business-managed IT spending to be truly successful, CIOs will require the right guardrails in the form of central IT oversight. The 2019 CIO survey makes the case that organizations without IT team involvement are twice as likely to have multiple security issues and are also less likely to build customer trust with their technology investments.

    What Does This Mean? Instead of actively opposing shadow IT investments, CIOs should partner with their business counterparts to create effective governance and operating models for business-managed IT spending. Central IT oversight will ensure the right support for digital business initiatives, reduce the risk of unauthorized breaches and minimize wasted spend.

    Influencing Without Authority: What It Takes to Be an Effective Technology Leader

    Board membership for CIOs dropped this year, with only 58% of IT leaders being part of the executive team in 2019 as compared to 71% in 2017. Does this mean CIOs no longer have executive backing for orchestrating and executing digital business strategies in their enterprise?

    The 2019 CIO Survey indicates board membership, headcount or annual budgets are not the right indicators of the power and influence of technology leaders. Instead, CIOs should focus on building trust across organizational boundaries, creating partnerships with the right executive stakeholders and ensuring the success of critical initiatives. CIOs working for digital leaders are comfortable exerting influence without authority and are driving organizational growth, by being “three times more likely to collaborate strongly with business leaders.”

    What Does This Mean? Formal board membership or the size of the IT team is not the best way to assess CIO influence. The best technology leaders ensure successful enterprise transformation by garnering strong commitment from the board, building digital capabilities with cross-functional teams and creating a sense of urgency for rapid innovation.

    — Deepak Jannu

  • Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Much like “blockchain” and “big data,” the term “DevOps” is another buzzword currently being thrown around the IT departments of large organizations.

    Many have identified the need for faster software development life cycles; a more precise process closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations teams. DevOps is essentially agile, all grown up and ready to take on the constantly innovating and rapidly deploying needs of the modern business.

    For security professionals, it’s a fantastic initiative: We can inject security into the process far earlier, reducing the cost of fixing bugs and avoiding potential catastrophe down the track.

    The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become a white elephant, you know, one of those “don’t mention the war” projects.

    So, what’s the problem? There are a few ways to approach DevOps that I believe will make for much smoother sailing. An effective program goes beyond a few fancy new tools, titles and team meetings. It’s not always going to be easy but taking the time to fix a broken strategy (or implement it the right way from start) is going to be far less painful in the long run. Ultimately, it’s going to result in higher quality and more secure software.

    Let’s break it down.

    Let Go of the Agile Apron Strings

    There is somewhat of a misconception that an organization must choose between agile or DevOps, setting down one path or the other, never to look back.

    The thing is, the development process works best when both are being considered and implemented as one. DevOps is not a reinvention of agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation the process will be exactly agile, or completely different from agile.

    Agile supports the principle of cross-functional teams, bringing designers, testers and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing systems, security and operations into the mix to offer a robust, end-to-end skillset that had the ultimate goal of full, functional software delivery to the customer.

    During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original agile team working together, with the security and operations additions still finding their way in the machine. No one is quite sure how to include them, what they should be doing and their overall objectives.

    DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management but getting everyone on the same page with the enhancements DevOps functionality will bring is half the battle.

    Increasingly, DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which security skills can be built within the development team.

    Automation Isn’t Everything (and It’s Not the Most Secure)

    Another feature of DevOps methodology is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you can likely guess, very reliant on tools.

    Tools are awesome. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance and storage elements with relatively seamless ease.

    However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked and that presents enormous quality—not to mention security—issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.

    The happy medium is to ensure you have a balance of people and tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:

    • Allocate enough time for people to become familiar with the chosen DevOps toolchain.
    • Focus on effective collaboration (and how the tools can support that).
    • Address any gaps in the process, whether they are skill/knowledge or tool-based.

    In short, don’t just tool up and hope for the best.

    DevOps Isn’t a Buzzword, It’s a Culture – Are you Growing Yours?

    Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.

    You see, merely saying “let’s do DevOps” and making the operations team move desks isn’t going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is walking the walk. DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.

    What does a great DevOps culture look like?

    • Individuals are empowered to lend their expertise to a process, not just leaders.
    • Open, honest and respectful communication between teams.
    • Each person takes responsibility for the overall objective of building quality and security into the development process.
    • Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person’s role.

    For years I have emphasized the importance of building positive security cultures in development teams, and DevOps is no different.

    The right tools, knowledge and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team’s eyes to the importance of protecting our data. With DevOps, you must lay the cultural groundwork for positive change: Ensure everyone understands their role, value and expectations, the overall project goals and steps in the process.

    Have you mastered that? Great. Now, let’s shift the needle, dial up the security aspect and make DevSecOps the ultimate plan for software excellence.

    — Pieter Danhieux

  • How to Transition to Become a DevOps Engineer

    How to Transition to Become a DevOps Engineer

    You’ve either heard the buzzword or you’ve seen the extensive list of rewarding aspects that come with being a DevOps engineer. Whatever the reason you’re here, this guide should help with taking the right steps toward becoming a DevOps engineer, whether this is your first job after graduating or an opportunity to reskill leveraging your prior industry experience.

    Immerse Yourself

    Learn the fundamentals, practices and methodologies. Understand the why behind DevOps before jumping into the tools. I believe the key goal of any DevOps engineer is to increase speed and maintain or improve quality across the entire software development life cycle, in order to provide maximum business value. Read articles, watch some YouTube videos and go to one of your local Meetup groups or conferences–it’s useful to become a part of the welcoming DevOps community where you’ll learn from the mistakes and successes of those that have been here before you.

    Your Background

    There are likely two key times where you’ll be transitioning into the role of DevOps engineer; either reskilling during your career or as your first job after graduating. You may have prior experience in technology, such as working as a software developer, systems engineer, systems administrator, network operations engineer or database administrator, all of which will bring broad insights and useful experience for your future role as a DevOps engineer. If you’re starting your career, maybe you’ve finished your degree in computer science or any other STEM field which will give you some of the basic stepping stones you’ll need in this transition.

    I think it’s important to breakdown the broad spectrum of what DevOps engineer roles entail. Most enterprise companies today will use DevOps engineers in three different positions.

    • DevOps Engineers, with a Dev Bias: Work in a software development role, building software applications. The key point is they leverage CI/CD, shared repositories, cloud and containers as part of their everyday work, but they are not necessarily responsible for building or implementing tooling. They will understand infrastructure and in a mature environment, will be able to push their own code into production.
    • DevOps Engineers, with an Ops Bias: Could be compared to systems engineers or systems administrators. They understand software development but do not spend the core parts of their day building software applications. Instead, they are more likely to be supporting software development teams to automate manual processes and increase efficiencies across the human and technology systems. This could mean breaking down legacy code and using less cumbersome automation scripts to run the same commands or it could mean installing, configuring or maintaining infrastructure and tooling. They ensure the right tools are installed and available for any teams that need them. They enable teams with learning how to leverage CI/CD and other DevOps practices.
    • SREs (Site Reliability Engineers): Think of site reliability engineering as having software engineers solving operations and infrastructure problems. SREs focus on creating scalable, highly available and reliable software systems.

    In the ideal world, DevOps engineers will understand all the above, which is the norm at some mature technology companies. However, if you knock on the door of top tier banks or many Fortune 500 companies you’ll realize oftentimes these roles do usually have biases towards dev or ops.

    Operating Systems

    Whichever background you’re coming from, you should start with the fundamental technologies you’ll need to use and understand as a DevOps engineer. Linux is most likely the operating system you’ll be using daily, although some of you might be using Windows. This is where everything runs, and fundamental knowledge is important. You can install Linux at home where you’ll be able to break as much as you want and continue learning along the way.

    Scripting

    Next up you’ll need to pick a scripting language. There are many to choose from, such as Python, Go, Java, Bash, PowerShell, Ruby and C/C++. I suggest starting with Python, it’s one of the most popular for a reason, it’s easy to learn and interpret. Python follows the fundamentals of object-oriented programming and can be used for web development, software development, creating desktop GUI apps and even business applications.

    Cloud

    After Linux and Python, my next pick would be cloud, where you could choose from Amazon Web Services, Azure or Google Cloud Platform. I’d start with AWS, as they have an extensive collection of free learning tools available to  take you down any track from learning about AWS as a developer to operations and even the business facing components. In fact, you might even be overwhelmed by how much is on offer when you first get setup with AWS. Maybe start with EC2, S3 and VPC and see where you want to go from there.

    Programming languages

    For those of you with a passion for software development. You should keep on improving your programming skills. Some good languages commonly used in this role include Python, Go, Java, Bash, PowerShell, Ruby and C/C++. You should also become familiar with tools such as Jenkins and Git/GitHub which you’ll be using frequently as part of the CI/CD process. Infrastructure is no longer left to the operations guys so you’ll need to have some exposure to a cloud platform such as AWS, Azure or GCP.

    Containers

    Finally, start learning about containerizing code using tools such as Docker and orchestration platforms such as Kubernetes. All the above have extensive online learning resources for free and most cities will have local Meetup groups where you can turn up and learn from experienced people in a friendly environment.

    For those of you with less experience in development, you can still get involved using your passion for automation, increasing efficiency, collaborating with others and a never-ending desire to improve on your own work. I would still suggest learning the tooling outlined above, but with less emphasis on the coding/scripting languages. It will be useful to learn about Infrastructure as a Service, Platform as a Service, cloud platforms and Linux. You will likely be setting up the tools and learning how to build systems that are resilient and fault-tolerant while writing your own code.

    Reskilling

    If you’re transitioning into a DevOps role during your career, you should start within your company to explore opportunities. Can you reskill by working with an existing team? There might be an option for you to shadow other team members, ask for advice and reskill without even leaving your current job. This might not always be possible and some of you will need to move into another company.

    If you can learn some of the practices, tools and technologies listed above, you’ll be in a good position to demonstrate relevant knowledge during interviews. The key is to be honest and to not set yourself up for failure. Most hiring managers understand you don’t know all the answers but if you can show what you’ve been learning and explain you’re open to learning more, you should be in with a good chance.

    Starting Your Career

    You can apply to direct open opportunities at companies who are hiring junior DevOps engineers. You will often find these companies say they’re looking for more experience and you should apply back in future when you’ve gained some commercial experience. It’s the typical, frustrating scenario of “we want more experience” but nobody is willing to give you the first chance.

    It’s not all gloomy though, there are a few companies focused on training and upskilling graduates directly out of the university. MThree, where I currently work, delivers exactly that. We hire fresh graduates and train them for eight weeks in our Alumni Academy. Training covers everything from theory through to hands-on projects with Python, Jenkins, Git, Ansible, Docker, Kubernetes and AWS. By the end of the training you’ll have some solid exposure to the entire software development life cycle and a good understanding of how this applies in a Fortune 500 environment. The best part is once qualified, our teams then leverage their extensive list of clients to provide job opportunities for junior DevOps engineers. MThree pays these associates on a full-time salary with benefits for the first 18-24 months before they join the client as direct employees at the end of the agreement. This is a great way to bridge the gap from university into your technology career.

    In summary, there are many ways to transition to become a DevOps engineer. This is a very rewarding career route which will likely keep you engaged and challenged as well as increasing your earning potential.

    — Conor Delanbanque

  • Leadership Drives Digital Transformation Success

    Leadership Drives Digital Transformation Success

    When it comes to near-term survival, organizations know they are fighting for their digital existence. Still, despite 80% of organizations moving forward with their digital transformation efforts, very few have experienced the heights of success they hoped. In Digital Transformation: Coming from Behind, we reported consultancy McKinsey & Company found less than one-third of digital transformations are successful.

    What makes for a successful digital transformation? Services provider Fujitsu believes its recent survey has cracked the code. With Fujitsu Future Insights Global Digital Transformation Survey Report 2019, Fujitsu found less than half of the organizations can say their digital transformation efforts have resulted in forward progress.

    The survey, which spanned 900 IT executives across nine countries, also found what Fujitsu believes are the factors of success in digital transformation: leadership, ecosystem, empowered people, a culture of agility, the value from data and business integration. These are all the organizational capabilities Fujitsu identified as necessary for successful digital transformation and calls them the “digital muscles.”

    While there were six digital muscles identified, there’s one essential to strengthening them all: leadership.

    Leadership came on top when it aligned social and revenue goals. When survey respondents expressed what factors would improve their trust in enterprises, 67% said they would trust companies that make a positive societal impact and more enterprises indicated they’re embracing social responsibility as well as revenue. According to the survey, 72% of respondents said their companies have a responsibility to help solve social challenges in addition to the pursuit of profits and 74% said it is important that business goals and social goals are aligned.

    According to the survey, 70% of respondents believe their business leaders practice empathic leadership and most management teams actively communicate with their employees. And 68% said their management readily communicates important information, and their ideas, to their employees.

    Leadership also means enabling staff to do what they need to do to succeed.

    “Businesses have huge unused and latent capacity of their people in their ideas and understanding of business challenges. Many people in a business have a deep understanding of certain issues, like specific customer needs, or understanding the potential of a technology, in a way that the leadership often does not. But people who perform transactional tasks, acting only as business resources, are using a minimum of their potential,” the report stated.

    The takeaway for leadership is to empower employees to develop creativity, empathy, problem-solving and digital skills.

    Leadership in helping employees to achieve work-life balance was believed to be important to 78% of respondents. Additionally, 74% agreed diversity is important, 72% for inclusion and 71% said they encourage their employees to act proactively.

    “Companies that recognize the importance of these factors seem to have greater success in digital transformation,” the report stated. “A good work-life balance enables employees to work with a sense of fulfillment. They can be motivated to transform. Taking advantage of diversity can help companies to attract talent and to form more creative teams, which brings creativity and innovation,” the report continued. “In addition, companies emphasizing inclusion earn the respect of individual employees and encourages greater sharing of ideas and opinions. Creating a corporate culture that motivates employees to innovate will help drive digital transformation.”

    Finally, the report found leadership that helps build their people’s ability enjoys better transformational outcomes.

    From those companies that support a work-life balance and diversity, 41% said they delivered good digital transformation outcomes. However, for those that didn’t place importance on work-life balance and diversity, only 19% and 22% respectively had good digital outcomes.

    “Among companies that emphasize inclusion, 40% said that they had delivered digital transformation outcomes, whereas for companies that do not regard inclusion as important, the figure was only 24%,” the report said.

    The survey shows leadership that primarily focuses on technology transformation and don’t focus on helping their employees enhance their capabilities as part of an organizational transformation, risk falling behind those organizations that do prioritize employees.

    — George V. Hulme