devopsy.kinsta.cloud

Tag: stakeholders

  • Why DevOps Principles Fit Well in Highly Regulated Industries

    Why DevOps Principles Fit Well in Highly Regulated Industries

    DevOps is best suited to digital start-ups with minimal regulation and few restrictions, right?

    Initially the DevOps movement stemmed from the agile, innovative, born-on-the-web companies that were able to change their way of working quickly. However, the principles and practices are completely transferrable to all organization types. This includes those at the other end of the spectrum, where processes are very tightly controlled and regulation dictates a significant part of the business investment.

    Why Highly Regulated Companies Initially Resisted DevOps

    When DevOps first emerged, the major concerns for companies following strict regulations were to maintain their security controls and governance processes. Deploying changes more frequently was viewed as a risk to security and the governance controls that were firmly in place.

    Another reason for not moving toward a DevOps way of working was the “segregation of duties” requirement, making it impossible for developers to deploy into production—thereby not being able to “do” DevOps.

    Related Content:

    Break the Rules and Win at Digital Transformation

    Understanding is Key to Achieving DevOps Culture

    ‘Is DevOps Really Worth It?’

    There were established, formalized processes in place that satisfied all the regulatory needs. Some organizations saw making any changes to those processes as more work than what would be saved by automation. This meant that the processes stagnated and hindered future change.

    Despite this, the majority of executives now believe that DevOps is a crucial ingredient in making sure that their company can adhere to new regulations and stay ahead of their competitors in compliance adoption.

    Why DevOps is Actually Better for Highly Regulated Industries

    DevOps can be your biggest ally when it comes to regulation and compliance—as long as you follow a few simple rules:

    1. View auditors (regulators) as stakeholders in the DevOps journey.

    By collaborating with the auditors in the same way as other stakeholders, you can engage with them early in the process and ensure details get agreed upon without costly change further down the line.

    Getting buy-in from auditors on any technical solutions at an early stage reduces the likelihood of change requests, missed deadlines and non-compliance. By working closely with auditors, you will ensure that the company has a strong understanding of the level of compliance needed for each different aspect or component of their systems. This helps avoid the waste of being compliant in areas which are not necessary.

    Sometimes you will only be able to clearly interpret a regulation through close collaboration with auditors. This avoids misunderstanding and unnecessary rework. In some cases, working closely with the regulatory body can highlight aspects that had not been addressed previously, developing a feedback loop with them. This evolving feedback means that the company will end up with a solution that is satisfactory.

    Close collaboration with auditors increases trust in the processes which have been developed in your organization.

    1. Codify compliance requirements and policies.

    Good DevOps processes will increase the amount of audit trails and governance in the process, while enabling fine-grained traceability throughout the entire delivery process. Compliance documentation can be enforced more easily as part of projects. There is generally less need for process documentation, as so many tools now automatically generate any documentation required. By using collaborative sharing tools we can also reduce the problem of different document versions.

    1. Automate your delivery pipeline end to end.

    Automation gives reliability, repeatability and traceability. Automation means we have a predictable outcome and fewer manual processes, which is good for auditing and tight control.

    By having fewer manual tasks, we can also reduce the possibility of manual error and missed processes. Automated environment provisioning improves the quality of testing and gives a high level of confidence in the change.

    With end-to-end automation and process orchestration, controls are written in and embedded to processes and systems. This helps to reduce liability. Systems are designed to reduce the risk of individuals making errors, forgetting processes intricacies or even taking malicious action. This also helps to develop a blameless culture. Bullet-proof processes means that security protocols now become built-in. Rather than see DevOps as a threat to security, it is now being viewed as the best way to mitigate risk. It also becomes a way of enforcing security, audit and compliance requirements.

    Automation in all areas allows you to quickly evolve with changing regulation requirements and last-minute additions, helping you to stay ahead of your competitors who aren’t able to do that. Future regulation is likely to require reporting on the lowest-level processes, and the only way to ensure that processes are being followed reliably every time is to introduce automation and DevOps—a culture of ongoing improvement.

    What is Happening Now

    Some of these companies in highly regulated industries are actually starting to lead the curve in terms of innovation and DevOps adoption now. They have seen just how powerful DevOps can be and are creating an agile business that can meet regulatory requirements and evolve with customer needs, making their business much more competitive.

    — Bronwyn Davies

  • Quality Culture, DevOps Forge Better Connections Between IT, Lines of Business

    Quality Culture, DevOps Forge Better Connections Between IT, Lines of Business

    The automation of software development does not obviate the need for a collaboration between IT and the lines of business, or the development of a culture of quality on the part of the development team. Achieving that quality culture requires more than a change in mindset as developers seek to align quality with the speed and automation goals of DevOps.

    There are five items required for a quality-driven DevOps environment:

    1. Understanding the proper role of “minimum viable product”
    2. Collaboration between IT and lines of business
    3. Having metrics in place
    4. Across-the-board buy-in

    “Quality culture is characterized by employees who are motivated to consistently strive for the highest level of quality,” said Al Riles, principal consultant at Tunnell Consulting, a firm providing solutions to the complex problems faced by life sciences and biopharma companies. “That’s one key component of it, as well as the ongoing process of continuous improvement.”

    Minimum Viable Product and Continuous Quality

    Aligning quality with the speed and automation goals of DevOps is critical to success, and part of this is gaining a deeper understanding of the role of “minimum viable product” and understanding when that approach contributes to the development process.

    “The concept of ‘minimum viable product’ does not, as its name would suggest, contribute to a substandard product,” said C.R. Venkatesh, CEO of Dot Com Infoway, a CMMI Level 3 IT company. “Quite the contrary, the concept is the basis of continuous and iterative improvement, and encourages the use of user feedback, which often results in insights that might be missed by the in-house team.”

    The concept of quality culture and MVP are not mutually exclusive in a DevOps environment, so long as continuous improvement is part of the equation.

    Collaboration Between IT and Lines of Business

    The collaboration that is a key part of DevOps is also a key part of quality culture. “You have a culture in place where everyone embraces that fabric that includes the right type of behaviors and the right values, including communication, reward and recognition, as well as clarity on roles and responsibilities,” said Riles. “That working fabric gets well-defined, because everyone is functioning around the same key elements that constitute that strong corporate culture.”

    “Collaboration has always been important in a DevOps environment,” said Venkatesh. “But we need to define precisely where that collaboration exists. In an internal environment, that collaboration is between IT and lines of business. Increasingly though, IT and development is an outsourced function, and in such cases, that collaboration must be preserved. What this means is that it exists not just within the confines of the outsourcing provider, but also between the provider and the client. The developer must seek out alliances not only with the client’s sourcing manager, but also with other internal stakeholders in the project.”

    If You Don’t Measure, it Doesn’t Exist

    Quality initiatives require an active role in changing the mindset of all stakeholders, but mindset alone won’t get the job done. Metrics must be in place and tied to those quality initiatives. “Even in the smallest of development projects, defined quality metrics must be set ahead of time, with clearly defined outcomes,” said Venkatesh. “By asking what we hope to accomplish with a development project, clearly defining the goals and adhering to a set of predefined quality standards, developers—whether in-house or third-party—are able to accurately predict what the outcome will be.”

    Riles’ process involves a quality management maturity grid, which identifies multiple dashboards. “It allows the organization to become familiar with what a quality organization consists of, and then you can use this maturity grid to measure where the organization is once you embrace this initiative. Then, you can implement the initiative, and come back and re-evaluate yourself to see the progress you’ve made,” said Riles.

    Everybody Has a Seat at the Table

    Incentivizing all stakeholders, throughout every level of the company, is paramount and, according to Riles, “It has to do with communicating what the vision is, and having a clear quality message that’s coming from leadership. Then, there has to be a shared quality mindset among all staff.” Riles notes that the quality mindset is shared by everyone in terms of understanding the organization’s objectives, policies and procedures and their roles in hoping to achieve them.

    This is reinforced by leadership at all levels, who are actively engaged in supporting the development of a quality culture, and they engage and motivate others to do the same. For it to be sustainable, we realize that success is based on the sum of all parts of the organization. They must be continuously monitored and fine-tuned as the organization grows, and this includes communication, reward and recognition, and engagement.

    About the Author / Dan Blacharski

    Dan Blacharski is a thought leader, advisor, industry observer and PR counsel to several Internet startups, and author of the book “Born in the Cloud Marketing: Transformative Strategies for the Next Generation of Cloud-Based Businesses.” He has been widely published on diverse subjects relating to cloud computing and technology, and he is editor of BoozeHub.com. He lives in South Bend, Indiana with his wife Charoenkwan and their Boston Terrier, Ling Ba.

  • How Agile Are Your User Stories?

    How Agile Are Your User Stories?

    Around the world, enterprises are adopting the concept of Agile development. This methodology is based on a set of principles for software development by which requirements and solutions evolve through the collaborative effort of teams. User stories form the foundation of the Agile requirements process, and teams gather to create them by exploring how users will interact with their solutions. To facilitate planning and discussion, teams typically jot down stories on pieces of paper and then physically arrange and rearrange them. It is a curiously old-school process for such a forward-thinking method.

    User stories are so vital because they give developers just enough information to estimate the level of effort needed to implement the functionality described by the story. When written well, they can be powerful, because they help developers and testers view requirements from a customer’s perspective. They provide context and an understanding of what motivates the people who will use the solutions they deliver.

    Struggles with Stories

    Agile represents a significantly different workflow than developers have previously used. As enterprises work to expand and mature their Agile practices across their projects and teams, they struggle to figure out how user stories fit, because:

    • Developers and testers may prefer user stories over a lengthy, text-heavy business requirements document, but user stories are new to most business stakeholders and business analysts. As organizations try to transition to Agile, these individuals struggle to write high-quality user stories that accurately and sufficiently describe all customer needs. They get bogged down writing and managing them and lose focus on the bigger picture.
    • The number of user stories can get out of hand quickly due to complexity. Most enterprise projects involve the development and enhancement of multiple, integrated systems to deliver functionality for a variety of roles. Users can take many paths that often interconnect and overlap with other processes. This can mean hundreds of user stories for a project of any size. Manually recording and managing the wealth of information that the development team needs is not feasible, and user stories can be missed or misinterpreted in the process.
    • Critical nonfunctional requirements—such as those for compliance, security and performance—complicate the adoption of user stories because they weren’t designed to represent those types of requirements. User stories scribbled on sticky notes or created in an Excel spreadsheet don’t support the rigor enterprises need for audits, change management, history and traceability.

    Enterprises want to reap the benefits of Agile for their complicated, expensive, high-risk projects, but they want to manage complexity and risk as well. They need a robust Agile requirements tool to help them, especially for the creation of reliable, consistent and high-quality user stories.

    Making the Shift to an Agile Requirements Tool

    Just as approaches to development have changed, so has the workplace, necessitating a new approach to teamwork. PricewaterhouseCoopers noted in its paper, “Adopting an Agile Methodology, Requirements Gathering and Delivery“: “As companies shift from small projects and teams engaged in Agile to more complex projects and potentially distributed teams, there is a need to shift from paper and spreadsheets to tools that provide workflow, persistence and traceability.”

    The power of best-in-class requirements management tools is that they enable teams to use user stories for development while making it easier for business stakeholders and business analysts to create them. These tools eliminate the need to manually create user stories within the development teams’ Agile tools. They bridge the gap between traditional and Agile requirements, enabling enterprises to scale Agile while managing enterprise concerns.

    The powerful capability sets of tools such as this help teams to:

    • Generate high-quality user stories and tests automatically from process flows. Product owners and business analysts use customer journeys to automatically generate user stories and acceptance criteria with the click of a button. They push these artifacts into the development teams’ Agile management tool of choice, where developers and testers also have access to related requirements information, such as regulatory information, visual models and constraints, supporting a comprehensive understanding. User stories are reliable and consistent, and there is no longer a need to spend time and money to teach business stakeholders or business analysts to write them.
    • Work together to visually define customer journeys. This allows stakeholders to “tell their stories” as they work with product owners and business analysts to collaboratively define customer journeys. Using the familiar construct of user models—with steps, decision points, actors and condition statements—the entire team collaborates to record and analyze processes in a shared workspace. Teams maintain a focus on strategic objectives when making prioritization decisions and spend less time managing a huge list of user stories manually.
    • Reap the benefits of Agile while using enterprise-level capabilities for visualization, traceability and reuse. Support for visual models and the ability to relate them to one another and other requirements artifacts helps teams establish the precise traceability they need to ensure full requirements and test case coverage. It also supports improved change management and decision-making, ultimately leading to higher-quality software. Customer journey models can be reused across projects and teams, as can user stories and other requirements artifacts, saving time and improving consistency.

    Great strides have been made in Agile requirements management tools recently, but many enterprises are still using sticky notes to create and organize their user stories because they don’t know about what these tools can do. A next-generation tool enables organizations to scale Agile across the business and create a common ground for IT and business to meet. With capabilities including visualization, collaboration, traceability, management analytics and reuse, teams are more effective and applications are delivered faster.

    About the Author / Ruth Zive

    ruthziveRuth Zive is Vice President of Marketing at Blueprint. She is a metrics-driven marketing strategist who has worked for two decades serving B2B clients in the technology, healthcare and financial services industries. At Blueprint, Ruth is responsible for product marketing, analyst relations, branding, demand generation and inside sales initiatives. Connect with her on LinkedIn and Twitter.