Tag: continuous improvement

  • Scaling DevOps for the Enterprise

    Scaling DevOps for the Enterprise

    Information technology has been an integral piece of the modern enterprise for multiple decades and that dependency is only growing. With digital transformation, there’s the inevitable increase in demand for new applications. As such, software development services will continue to be a vital component of the business amidst the mounting pressure to innovate and deliver. This has resulted in many organizations moving from traditional development practices to more flexible and agile methodologies. Conventional software delivery methods are also being replaced in favor of enterprise DevOps practices such as continuous integration (CI) and continuous delivery (CD).

    While DevOps stimulates innovation and speeds up software delivery, adopting DevOps practices does not guarantee success as there are times when companies have been underwhelmed after implementing DevOps practices across their development teams. Knowing this, it is important to state that most DevOps failures come down to flaws in the execution of the methodology. A best-practice DevOps implementation should increase the value and impact of IT infrastructure by bridging new and old technologies. This allows for companies to better navigate change with clear time-to-value merits and lower risk. In short, it’s about scaling DevOps practices with security and quality embedded every step of the way.

    Look for Small Wins and Build on What Works

    Implementing DevOps best practices can mean a radical shift from the way an organization currently works. It is important that the entire team buys into this new approach. However, different dynamics within different organizations can lead to different results.

    Ideally, you should never have large complex projects. The best approach would be to work in small batches where you and your team can quickly learn from your decisions. By identifying the bottlenecks causing the largest constraints in your delivery process and incrementally changing, transforming and optimizing, your team could demonstrate the advantages of the new DevOps practices and build confidence in the team’s ability to implement the new methodology. Wins like these give a great start to the project before you’ve even introduced the entire IT organization to the changes needed to implement DevOps best practices. 

    Break Down Organizational Silos

    Known as well-intentioned areas of specialization, organizational silos are defined within the business to sharpen expertise and assign roles. Silos may have unintended consequences over time though, as each department potentially starts paying less and less attention to the other departments as they become consumed by their own assignments. As a result, silos inadvertently limit collaboration and have the potential to contribute to delays, bugs and conflicts. This is why C-level executives must initiate the process of removing the barriers to these silos and integrating the different disciplines within the IT department.

    For DevOps to work across the enterprise, executives must reorganize the configuration of software development projects by bringing in representatives from all important IT disciplines.

    Everyone Needs to Be on the Same Page

    Sometimes silos can be deeply rooted in an organization, and even if you do succeed in removing the barriers, there’s always the risk that they could re-emerge. Due to this, it’s important to create motivation for a silo-less enterprise.

    Anyone wanting to change a culture needs to define the actions and behaviors they desire, and design the work processes that are required to reinforce those behaviors. If your ops team is measured only by mitigating risk and your dev team is measured by delivering change, it goes without saying that you have a conflict.

    Through the incorporation of intra- and inter-team collaboration metrics into individual and team performance reviews, you can base a considerable amount of the review on lead times and quality metrics for software delivery. This is important not just for the dev and ops teams, but also QA and security. It’s easier to act your way to a new way of thinking rather than think your way to a new way of acting. 

    Real-Time Visibility Across the Toolchain and Environments

    When a team has poor visibility of their system, it can result in bad decisions and missed opportunities. Teams must replace manual project and release tracking methods that use spreadsheets and emails with an open, web-based solution that your team can leverage to plan, track and govern the entire application release management process.

    As teams and their stakeholders need real-time visibility across the entire DevOps toolchain and production environments, it is important that the chosen solution enables product team members to focus on their critical tasks while providing pertinent real-time information to their managers and stakeholders. 

    Don’t Lose Sight of the End User

    Once deployed, the application or service will interact with existing, and quite often, new systems. As it is developed for use by humans, don’t lose sight of the end user. Their satisfaction determines the success of your application or service.

    Actively involve users every step of the way, not just at the ideation and product requirements level. Teams should take the appropriate time to properly assess and fully understand the issues, challenges, priorities and constraints of their users. This knowledge can be utilized to define key performance indicators (KPIs) and continuous feedback throughout the DevOps toolchain.

    Move Forward on Orchestrating Continuous Delivery

    There’s no question that a lot of work goes into preparing and deploying a release. With the goal of delivering releases that have a high impact, it seems that companies sometimes choose to hold and then bundle together multiple application improvements into a single release. Such a strategy can lead to poor quality and failure—a result of deploying large infrequent releases. As another key driver toward an increased need for orchestration and automation, a lack of skilled employees means that many organizations have trouble releasing software in a reliable manner.

    The orchestration of continuous delivery is a fairly new way of planning and delivering business applications across the enterprise. With a focus on continuous improvement, continuous integration and ensuring you are always ready to deliver what the business needs, release control and deployment automation are vital to ensuring smooth delivery and a basis for governance.

    Conclusion

    The implementation of DevOps is a long term commitment. More a philosophy directing how you work, DevOps is not a rigid set of practices like ITIL, lean or Agile development.

    No organization will reach a state where it can comfortably say it has perfected its DevOps best practices model. Instead, it must continuously experiment with new processes, capabilities and tools identifying those that can yield the highest possible integration across the entire DevOps toolchain to deliver the best value for the business.

    — Mark Levy

  • Leadership Role in Adding Test Automation to Existing Environments

    Leadership Role in Adding Test Automation to Existing Environments

    Leadership is the foundation for all agility. I’ve written elsewhere extensively on a model that works well for the new environment in which we find ourselves: the need for tens or hundreds of very smart people, doing things that have never been done before with new tools, working with people they may not be familiar with.  These creative, expert people make dozens of decisions a day that few others see in real-time, turning ideas into code that must run flawlessly and execute complex business processes. Quite a leadership challenge.

    The leadership model I’ve articulated is simple. Leaders at all levels should focus on rigor (good decisions based on options and data), alignment (everyone rowing in same direction) and efficiency (respecting everyone’s valuable time). Getting the right people, with the right skills and the right kinds of interactions, is more valuable than having the right process and tools. 

    For software agility, we know reducing the friction between development and productive use is a powerful leverage point. This general area we now call DevOps. Coming from the application space as I do, my primary focus has been on test automation. How can we at very low cost continually ensure that our evolving software is ready to be deployed to production (or production staging, if we are doing periodic bundled software deploys)?

    I’ve recently watched a team introduce test automation into an existing application environment. Great leadership was demonstrated throughout by multiple team members. Let’s examine the steps taken and point out the leadership that made it happen.  

    Set the Target

    Team and organizational leaders laid out a clear vision of the business benefits and their support for the initiative. This was the culmination of several months of learning, communication and cost/benefit analysis. Leaders gained alignment based on rigorous analysis.

    Ensure Adequate Leadership and Technical Skills Are in Place

    In the run up to the inception of the work, leaders hired an experienced testing leader, who in turn hired a couple engineers to do the work. Because the environment was a common one in the industry (Salesforce was a big part of it), the leaders sought the best expertise they could find, and wound up engaging an external specialist firm to get them going. People over process. 

    Define the Technical Architecture

    The new team leveraged the knowledge of the consultants and some of their engineering partners to examine options and select an approach. They shared the options and analysis with their team and leaders and gained consensus and understanding. In the process the approach was fine-tuned. The team demonstrated rigor and efficiency and gained alignment. One key of their success was the “towering technical expertise,” a lean product development term, brought by the consultants.

    Deliver Incrementally

    For this item, I will describe the solution chosen, since the specifics will be of interest to this audience. The vision was to train the product owner/systems analysts to write acceptance criteria for each user story (which was the unit of development here) in the stylized language Gherkin. As the development was done during a sprint period, the test team would take the Gherkin and write automated tests for the test tool Cucumber, which would drive execution in Selenium. The execution would be automatically connected to the deployment of new code using Jenkins.

    The team wanted to avoid disrupting the existing flow until the risk was reduced based on proven results. Accordingly, they began by building automation for existing software, proving that the vision worked in practice, and gradually completed the regression suite and started to catch up to work in process that hadn’t been released. Excellent leadership for agility was demonstrated again, driving rigor through proof of the concept and laying the groundwork to get the rest of the team aligned.

    Get the Rest of the Team to Change

    Once the test team caught up to being able to do in-sprint automation, they needed to tackle the training and acceptance of a new way of writing acceptance tests (in Gherkin). The great results they demonstrated helped influence the product owners and systems analysts to give it a try.

    Continuously Improve

    As the creative period of designing the test automation approach and getting into production came to an end, a new period of measurement and continuous improvement began. Here we have another foundational element of leadership for agility: understanding where we have repeatable flows where process really is the key, and where we have a creative endeavor in which the focus on people and interactions must rule. In a sense, the team transitioned from a product development effort to a manufacturing-like flow, and they accordingly changed their approach.

    Conclusion

    Sometimes we make the mistake of thinking that getting to efficient DevOps is all about tools and processes. My experience is that to the contrary, leadership is the key. As the first value of the 2001 Manifesto for Agile Software Development states, “People and interactions over process and tools.”

    — Michael K. Levine

  • Predictions 2020: The Year of DevOps Empowerment

    Predictions 2020: The Year of DevOps Empowerment

    Every year since mid-decade, it seems, one publication or another has declared it to be “the year of DevOps.” Allow me to make the case that it really will happen in 2020.

    The reason? IT leaders are finally empowering their engineers with full-service ownership.

    In a world in which speed, quality and precision will continue to determine the difference between continued success and unmerciful failure–particularly with regard to delivering best-in-class, end-to-end experiences for all stakeholders–full-service ownership is a matter of reality and necessity. Not to mention common sense.

    Developing and delivering products and services that maintain pace and meet the needs of businesses is dependent on achieving faster release cycles without sacrificing quality. But running reliable systems at ever-increasing speeds presents huge challenges that software teams can meet by changing their service ownership policies. The good news is DevOps practices have been gaining considerable traction because they help teams deliver with increased velocity coupled with reduced risk. This enablement, similar to any change introduced, takes time and practice to make work for your needs.

    Code It, Ship It, Own It

    Full-service ownership grants engineers greater responsibility for the code they write and the services they develop during production. The importance of owning and operating your own code and taking responsibility for all deliverables should not be underestimated, because it is the engineers, after all, who should be–and have earned the right to be–accountable. They are the ones designing architectures and systems, coding software and writing runbooks. They are the ones on whose shoulders the overall quality of service sits. They are the ones who are on call when issues arise (invariably, as Murphy’s Law implies, in the middle of the night).

    If they are the ones who code it, then they are the ones who should ship it and own it. The days of engineers “throwing code over the wall” to operations or depending on site reliability engineering (SRE) teams to guarantee the performance of services in the wild are no longer relevant, much less workable.

    That’s particularly important going forward, considering the DevOps market is predicted to grow 18% to nearly $13 billion by 2025. As DevOps tools and solutions become more ingrained in IT operations, the most logical and proactive way to manage this growth, and the inevitable chaos it will bring, is to empower IT with full-service ownership.

    The Forces Behind Full-Service Ownership

    This is happening for three reasons:

    Accountability

    It’s a simple truth; consumers implicitly expect the services they use to work seamlessly and with minimal latency. Considering that consumers will simply move to another site when a page is slow to load or returns a 404 error, the payoff in terms of increasing business’ competitive advantage is immense.

    Full-service ownership promotes higher-quality work because it gives engineers clear visibility into how the code and services they’ve created are performing and impacting their customers’ daily activities. 

    Reliability

    It’s not rocket science to ask the scientist who built the rocket to fix it when it breaks. Likewise, businesses can reduce the amount of downtime and customer impact when a serious incident occurs by immediately bringing in the engineers who wrote the code or created the service. 

    Full-service ownership offers another important advantage: overall institutional knowledge among IT teams. Individual engineers benefit greatly from code reviews, on-call hand-offs, daily standups, casual information sharing and other exercises that build redundancy in knowledge and expertise.

    Continuous Improvement

    A common misconception in the engineering world is that “on-call” is synonymous with “always-on.” That in itself is counter-productive because it can lead directly to alert fatigue. In an ideal world, teams will build time in their development work to go “off-call,” a practice that alleviates alert fatigue and that full-service ownership encourages.

    It also fits perfectly with an integral element of the culture of engineers: a commitment to continually refine and improve their code, product, services and alerting. The most effective process goes beyond just fixing problems, it also includes getting ahead of them, by automating the work needed to prevent them, freeing engineers up to focus on the work that matters most. 

    Five Benefits of Full-Service Ownership

    1. The quality of the code will increase.
    2. Engineers will know when they are off-call, and alerts will be covered by another developer with equal expertise.
    3. Team knowledge and skills will increase through a deeper understanding of the codebase.
    4. Services will become more reliable.
    5. Operations will become more agile.

    When engineers are empowered to code it, ship it and own it, businesses put themselves in a better position to enhance the customer experience and reduce the impact of disruptions, which enables them to focus more on innovation. By defining and refining roles and responsibilities, full-service ownership also reduces the chaos associated with incidents, eliminates silos and unnecessary layers and, ultimately, promotes a culture of empowerment and accountability.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Tim Armandpour

  • Operational Excellence and the Success of Software Deployments

    Operational Excellence and the Success of Software Deployments

    When we talk about best practices for software reliability, the conversation tends to focus on optimizing the applications themselves and the infrastructure that hosts them. The driving idea is reliability must be baked into system architectures and infrastructure from the beginning.

    That’s certainly true. But by focusing too much on the design and implementation of applications, you run the risk of overlooking another crucial element for achieving reliability (not to mention agility and extensibility): a culture of operational excellence.

    It’s only by baking excellence into your organization’s operational culture that you can maximize reliability.

    Let me explain…

    Defining Operational Excellence

    Put simply, operational excellence is a mindset that is embraced across an organization to maximize outcomes and positive results.

    Operational excellence can be reinforced by specific tools and processes, but it’s ultimately a philosophy and a cultural principle. It must be integrated into your organizational culture in order to achieve its full effects.

    Operational Excellence And Software

    Operational excellence is a buzzword that you hear occasionally in the context of business management. It only rarely appears in conversations about software. Nonetheless, the concept has an important role to play in several respects, including making software more reliable and extensible.

    Uniting Disparate Teams

    One of the most pervasive challenges in modern software deployment and management is the fact that every deployment depends on multiple teams. Developers, IT operations, infrastructure engineers and business managers all have a role to play in ensuring that an application is a success.

    Getting all of these teams to work together can be a challenge. The ideal solution, according to the DevOps mantra, is to de-silo your organization by creating a single DevOps teams that oversees development, operations and everything in between. For some companies, that approach will work, but for others, single-team DevOps is not a realistic goal. There will always be some distinction between teams and specializations.

    Yet whether you have a single DevOps team, or multiple teams working toward a common goal, operational excellence can help you achieve the cultural unification necessary to help everyone advance the common good. Operational excellence serves as a cultural goal shared by all teams and team members during the software development and deployment process. By making excellence part and parcel of your culture, you gain a principle that can guide all of your teams, even if they otherwise share little in common culturally—which, generally speaking, is the case; developer culture is not the same as IT culture and certainly not the same as business culture.

    Operationalizing Best Practices

    Another key benefit of operational excellence is that it helps to ensure best practices are actually followed across the software deployment process.

    Most stakeholders in software development and deployment know what they should do when performing their jobs…but they don’t always do it. Your developers might churn out an inefficient function because they are under pressure to meet a deadline and need to deliver something that works, even if they know that they are not following coding best practices. Your IT team may fail to configure granular IAM permissions for a virtual server because they lack the time, even though they know that is not a best practice from a security standpoint.

    Instilling operational excellence into your teams helps to prevent these types of shortcuts. When a culture of excellence prevails, your team will follow best practices, even if they take longer.

    Continuous Improvement

    Human beings are naturally inclined to desire finality. Feeling like we will never reach the end of a task is discomforting (that’s why poor Sisyphus was so unhappy, for example). Yet, this discomfort needs to be managed if your organization is to achieve a culture of continuous improvement. Continuous improvement means your teams constantly find ways to make things better, even if they are already quite good.

    For developers and IT teams, this can be a tough pill to swallow. Developers or engineers who have achieved 99.99999 reliability for their application would probably rather feel proud of what they’ve accomplished than be told they need to add another nine to that figure.

    Still, striving to become even better is what continuous improvement requires. A culture of operational excellence can help ensure that your teams welcome this type of challenge rather than resent it.

    Collective Effort

    When it comes to software development and deployment, personal ownership of any part of the code or process is a risk to the organization. If only one programmer knows how a certain microservice works, or only one IT engineer has the power to create new databases, your organization will lose agility, or it could even end up with a hostage employee situation.

    Instead, software deployment should be as collaborative as possible. Everyone within a given team should understand and (in a pinch, at least) be able to perform everyone else’s job.

    A culture of operational excellence helps to ensure that your teams take a collaborative approach to the way in which they build and deploy software. Instead of letting each individual own part of the process and receive personal credit for its success, operational excellence encourages team members to think of their work as a collective process with collective responsibility for the results. That’s because operational excellence focuses on the success of the organization as a whole rather than individual employees or teams.

    Conclusion

    To be sure, choosing the right architectures, tools and people will do much to help maximize the reliability and effectiveness of your software, but those are only part of the solution. You also need a culture of operational excellence to unite your various teams behind a commitment to best practices, continuous improvement and collective pride in the applications they build and deploy.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    Adopting DevOps means changes from how you build software to organizational processes and cultural behaviors. Large enterprises have even greater challenges to overcome, including supporting a large number of applications and addressing technical debt while also taking on new development initiatives like digital transformation.

    What can we learn from experienced DevOps practitioners?

    In this DevOps Chat we spoke with Mark Levy, director of strategy, software delivery at Micro Focus, covering seven keys to successful DevOps implementations at large enterprises.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, we’re tackling the topic of large enterprise adoption of DevOps—no small task, for sure.

    I’m very happy to welcome Mark Levy from Micro Focus. Mark, welcome.

    Mark Levy: Thank you, Mitch, and glad to be here.

    Ashley: Would you just tell us a little bit about yourself and what you do at Micro Focus?

    Levy: My name’s Mark Levy. I am a director and working in the product marketing organization, and I focus a lot on strategic marketing initiatives as an evangelist, a DevOps evangelist. I develop and write content and commentary about the DevOps market. I’ve had a 25-plus-year career, and like many people, I’ve had many positions. I started out as like a sysadmin and was a developer and managed dev teams.

    But, in 2007, I started to focus exclusively on application delivery. And so, that has been—this whole area of application delivery, software delivery is something that I’ve been really focused on for the last 10 or so years.

    Ashley: Well, tell us briefly, a little bit about Micro Focus. Not all of our listeners might know what you all do.

    Levy: So, Micro Focus has also gone through this major transformation over, I would wanna say, the five to eight years or so. You know, we’re a global enterprise software company. We were established in 1976, we have 14,000 employees and 40,000 enterprise customers, about 4,800 software engineers, and we really focus on large enterprises, helping them run and transform their business. We have sort of focused on four key areas of how do we support our customers through their digital transformation journey, and enterprise DevOps is one of them.

    Ashley: I imagine that our folks, listeners that are from large enterprises are gonna be particularly interested, and I’m sure there are learnings and information that will be useful to other folks as well.

    So, you talked about playing in the space with large enterprises. I imagine that’s probably some global international companies, maybe some that are both European or U.S.-based as well. How would you describe how you differentiate what you do as Micro Focus as compared to other folks? There’s a lot of companies, of course, working to try to help enterprises adopt DevOps.

    Levy: Yeah, of course. And that’s sort of what I’d like to do first maybe is just sort of set the stage, because I always look at this, especially in the enterprise IT world, it’s so interesting. You know, Gartner made this sort of—you know, their strategic assumptions. And they said something like, through 2021, at least 80% of the DevOps initiatives will fail.

    Ashley: I have not seen that, no. Interesting.

    Levy: I don’t know if you’ve heard that, but—yeah. So, it’s interesting. What does that tell me—tell us, I believe? One is, the business is already in the fight. The enterprise, the business side is already in this digital economy and fight. We see that on the streets.

    And the other thing is, you know, IT is sort of behind the curve. And the reality is that our customers, the IT customers, the IT organizations have this incredibly complex hybrid landscape, it spans mainframe, mobile, on-prem, off-prem, and while the principles—the main DevOps principles—are similar to what the unicorns, so to speak, are delivering, that it’s really a whole different challenge.

    Because what’s critical is that there’s this above the line mandate to drive new digital revenue, but at the same time, you know, optimize the enterprise. And, you know, I sort of—I like one of my colleagues, his reference. It’s like, redesigning a jet plane while you’re flying it, you know? And so, I think that’s how, you know, what’s critical with large enterprises is that they’re trying to transform themselves and at the same time run the business.

    Ashley: Yeah, I would almost describe for a large enterprise, it’s like trying to build or transform the entire fleet of planes while you’re building it.

    Levy: Yes! Exactly.

    Ashley: Talk a little bit about—I mean, we all, I think, can appreciate in every business, especially large enterprise, they’re saddled with technical debt; they, of course, are working on operational efficiencies; they have applications that they’re trying to support and maintain.

    How do they take on something like a DevOps initiative successfully, as you were pointing out earlier, so that it doesn’t just stop at one group and kind of fall off from there, they really wanna be able to transform their part of their business? How do you do that?

    Levy: Right. So, I think one of the key things that we focus on enabling our customers to build on what already works, okay? They have all these core investments, and how can they take their core investments and leverage the ROI that they’re already having today, but implement new technologies and DevOps practices and capabilities? And I think that’s critical. I mean, how do they implement and scale DevOps practices, for example? It’s very, very important, and it’s hard.

    And so, we look at it from the basis of, how can our solutions and our products help them really get from point A to B? What is their current state now? Which is what they really need to understand. And it’s amazing how many companies really don’t have a current understanding, detailed, of their current state.

    Ashley: Mm-hmm, or a common one. [Laughter]

    Levy: Or a common one, because, you know, it changes a lot, but how do they deliver value to the customer? You know, what are their value streams, and what are the processes and the flow of artifacts? And so, they need to understand their current state.

    And then, they need to do a number of things that I know the people that are helping the DevOps community, the DevOps community have been evangelizing for a while—I think critical, especially in large organizations and enterprises, you know, they need to first really create this culture of continuous improvement. I think that’s critical.

    Ashley: Okay.

    Levy: You know, they need to enable, motivate and empower the teams, and the leaders really need to get on board, right? Without the leaders, it just will not work.

    Ashley: Yeah, I can speak from personal experience—instituting a continuous improvement culture is no small task in and of itself.

    Levy: Right, and you know, the thing is, the leadership style must also change, right? I mean, command and control really doesn’t work, decisions—it’s about empowering your product teams to drive as much decision making as possible. And that sort of has gone contrary to, you know, the organizational structure of the large enterprises.

    Ashley: Mm-hmm.

    Levy: So, that, I think, you know, is one of the critical challenges that these companies are faced with. Edward Deming made a great quote, “A bad system will beat a good person every time,” right?

    Ashley: Mm-hmm.

    Levy: And when I think of a bad system, I think, in its largest sense, the system. And this is where I think Micro Focus can help quite a bit is, anyone wanting to change this culture really needs to define the actions and behaviors that they desire and then design sort of the work processes that are necessary to reinforce those behaviors.

    So, you know, systems, processes, tools, help with and enforce good culture. But you know, if you have a bad system, it’s not gonna work. So, I think, you know, these are areas that we can help on the cultural side. I come back to thinking about the idea that, you know, sort of the general friction between dev and ops teams, where ops teams are really, initially, only measured by mitigating risk, and dev teams are only measured by delivering change. You know, there’s the conflict that has to be resolved. That’s critical.

    Ashley: You’re talking about culture; the other thing that occurs to me is, there can also be inherent or built in incentives that are counter to the culture that you’re trying to create. That friction is a good example for one. But, you know, there may be past punishment for failures or, you know, emphasis on down time, so the answer is always minimize change or whatever it might be. You’ve gotta take those things head on.

    Levy: Exactly, yeah. And so, I think, you know, you ask sort of where people start. I think, you know, you need to start—and everyone, a lot of people talk about this, and it is true. You really need to start instituting this culture of change, because DevOps drives a lot of change. It’s a transformational journey in the enterprise.

    Ashley: When you said, the number one thing you said was, “Leverage what works.”

    Levy: Yes.

    Ashley: What do you look for? What kind of things are you trying to say, “That’s a practice you do well, and let’s keep that, or let’s build upon that”—what do you look for?

    Levy: Well, you know, I think about, there’s a lot of legacy systems, core investments that these large enterprises have had and invested lots of money and time into it. And take, for example, COBOL, okay? That language, I think people are not necessarily aware how invasive it is. There’s still about 250 billion lines of COBOL around, right?

    Ashley: Mm-hmm, mm-hmm.

    Levy: It drives 70%, they say, of all business transactions—still, in the world.

    Ashley: That’s amazing.

    Levy: It is amazing.

    Ashley: [Laughter]

    Levy: And so, you know, I’ll give you an example of sort of what we’ve done and we’re, you know, we are very good at managing and understanding those environments. We have, you know, that’s a big part of our business. So, we can, you know, lift—if we can lift and shift, you know, COBOL workloads off of, you know, sort of the more legacy platforms into, let’s say, AWS, you know, that’s a big win for our customers.

    As an example, we had one customer that basically had—it was a major global insurer, had about eight different IT environments with a back end COBOL app sitting on the mainframe and then front end and WebOps. And basically, each environment cost about $3 million a year. And, to request that environment, to provision that environment, took six weeks.

    Ashley: Mm-hmm, mm-hmm.

    Levy: And so, we built, through our solutions, we were able to lift and shift that workload to AWS and reduce the cost from 3 million to 120K and reduce the provisioning time from six weeks to two hours.

    Ashley: And I wanna mention, too, to our listeners, too, we just had a webinar in the last week talking about mainframe APIs and frameworks specifically to mainframe environments to make it a little bit easier to adopt WebOps. So, though it doesn’t get the kind of sex appeal that necessarily new technology does, it is a huge, huge issue for enterprises and how do you bring the mainframe environment with the rest of the cloud and everything else.

    Levy: Right, it’s—you know, back to the theory of constraints. I mean, in your value stream, if—you know, you can develop and you can be an agile team, but if it takes six weeks to provision, you know, your mainframe environment?

    Ashley: Where do you suggest people get started? Is it go pick a new, from scratch greenfield project, or pick something that’s, you know, reasonably mission critical so we’ll get the support?

    Levy: Yeah. Well, I think one is, I like, initially, to set up a lab, like taking a greenfield. You need a place to learn. A lot of these things aren’t easy, or they’re not, people are not, the teams are not used to. So, like, I love the idea of what a lot of the community’s doing with DevOps dojos and building sort of a team level, maybe CI/CD, have a place to experiment and take that.

    But then, you know, ultimately, in large enterprises, they’re gonna come up. They might get easy wins early, right, but the challenge is, once they scale, they’re gonna run into some of the more challenging times. And that’s where, back to what they have to really start doing is taking this broader, system level view of the enterprise.

    So, you know, if they understand how they’re delivering value to their customers—and in enterprise, there’s many ways to do that—then they need to understand and prioritize according to the business objectives. Let’s say one business objective might be, we need to recapture value. Maybe our IT budget isn’t really growing, but we need to drive for more innovation. So, we need to—our objective is to recapture that value and redeploy it into delivering value and innovation. And so, that would drive a lot of your decisions in where you optimize.

    Ashley: Speaking of budgets being flat or not growing, digital transformation is all the rage, that’s what many, many companies are taking on, not just in customer experience, but across the enterprise, bringing them into the digital world. How does that fit on top of this if you’re trying to introduce DevOps?

    Levy: I don’t see how they can really run their digital transformation without DevOps. I mean, software today—you know, I talk about this a lot where business innovation and software innovation are generally becoming one and the same, right?

    Ashley: Mm-hmm.

    Levy: And going quick, innovating faster with less risk is critical. And so, IT is, you know, it’s imperative to really deploy DevOps practices to support the digital transformation of the business. So, I think, you know, the IT organizations that implement DevOps, those people are the drivers.

    Ashley: Well, and it’s hard to imagine how you were gonna transform systems and applications you already have as well as ones you might leverage as SaaS services or create yourself without an environment to integrate those altogether due to continuous integration testing, etcetera, as well as be responsive to the business.

    Levy: We’ve seen enterprises, they will typically start out, right, with their team level implementation and they might do really well, and it might be a greenfield app. Maybe it’s a new growth app, which is great, and they may get some early wins, which is super, but it’s still not their core business.

    Ashley: Mm-hmm.

    Levy: And so, they have to, ultimately, really transform their core business in order to be competitive in the market.

    Ashley: Mark, what’s the one thing organizations should not do when they’re looking to adopt DevOps—don’t make this mistake?

    Levy: I think the idea that they can just automate their way out of it, I think, is something that could get them in trouble. Because, you know, really leaving out the whole cultural aspect of it, it really is—you know, it’s interesting, if you read Jeff Bezos’ letter to shareholders every year, he just provides some incredibly insightful, you know, insights on how Amazon runs. He talks about this accelerated decision making process that they run, and they make these decisions, really, based on only 70% of the information that they need, basically. Whereas, large enterprises wait until they typically have 90%.

    And so, they are able to make decisions earlier because of the agility that they’ve built into their system and their culture of change. And this allows them to not only, you know, get earlier into the market, but it allows them to—everyone, it allows them that if they make a mistake, they can recover from their mistakes faster, and the cost of making a mistake actually goes down.

    Ashley: Mm-hmm.

    Levy: But this whole idea of organizational agility and providing that—there’s more than just delivering value faster to the customer, because it’s never a straight line, right, to success. So, we make a lot of mistakes and wrong turns in our journey, and being able to identify that quickly and have the agility to correct that quickly is actually more of a differentiator than just delivering fast.

    Ashley: It’s certainly required for any kind of agility. It’s not just getting things and getting decisions made faster, but changing when things aren’t headed in the right direction—or change.

    Levy: Right, right. And so, this is where, you know, if people are looking at DevOps, they’re saying, “Okay, well, we’re just gonna automate the deployment pipeline and we’re done?” No, there’s no “done,” it’s about really, ultimately, improving as an organization, right, and having that continuous improvement, the Kaizen kind of mentality of the organization. And that, to me, is what is so transformative as a company.

    Ashley: Going back to what you said in the beginning about having a culture of continuous improvement.

    Levy: Yeah, absolutely. And that, it would be, you know, frankly, the most powerful thing leaders can do—is that change. Because it really just changes the whole business. The business, then, gets more confidence, which is critical, right? With all this change, sometimes they’re not confident to make business decisions, but if you can provide them the confidence to go out there and really be aggressive, you know, that’s—you’re gonna see, you know, a whole bunch of positive results on the revenue side, on the public side of the business that’s been driven from, traditionally, the back office IT organization.

    Ashley: Well, Mark, I’d like to thank you. I’d like go for another 30 minutes, [Laughter] but I’d like to thank you for the time on the podcast. You know, I walk away with several things from our conversation. The things you shared that I heard were leverage what works, define your current state, create a culture of continuous improvement, command and control doesn’t work—you’ve got to empower product teams. Start with a lab or a dojo, some learning environment. I think your premise of, you can’t do digital transformation without DevOps is pretty intriguing. And last but not least is organizational agility, being able to make decisions quicker, get out ahead of things without having to have 100% of the information, kinda the Amazon model.

    Well, and that should wrap things up. I’d like to thank Mark Levy from Micro Focus for joining us. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat.

    — Mitchell Ashley

  • 5 Mistakes to Avoid When Chasing DevOps Transformation

    5 Mistakes to Avoid When Chasing DevOps Transformation

    In less than a decade, DevOps has become a buzzword of the IT industry, and enterprises are already reaping its benefits.

    But the implementation part still remains a question for many firms, considering the key mistakes that many organizations report in their very approach to DevOps. Most firms are also unsure about what outcomes they want to see from the process.

    Wondering if you’re making the same mistakes? Here are the five most common mistakes that can be included as part of a checklist to successful DevOps implementation.

    Misaligned Focus

    While automation and tools are the elements that steer DevOps, most firms believe that DevOps is all about tooling and automation. In reality, tools are mere enablers and automation takes off the burden of manual work. This collaboration helps firms to realign focus, eliminate process repetition and effectively manage the available software.

    Ultimately, the value of tools lies in what people achieve through them and hence, firms should focus on utilization to achieve expected goals.

    Faster = More Value

    Time-to-market is another key aspect of DevOps that needs a different viewpoint. In general, most firms think of DevOps as a process to increases the pace of the software process.

    But it has to be understood that DevOps takes a lean movement. By developing software on an exponential pace, DevOps process lets you have products delivered more frequently.

    The lean manufacturing process achieves success in software delivery by breaking the chunks of code into manageable units, which naturally results in continuous delivery. Moreover, if you need to alter one component, you can do it simultaneously without impacting the other. This allows you to deliver at optimum speed and still maintain business agility.

    Lack of Continuous Improvement

    As you learn more and get better, you’ll find better ways to improve or cut down steps that add no value. But this will require some amount of effort and investment.

    DevOps delivery pipeline consists of feedback loops, which allow you to inspect, reflect and decide if you are going in the right direction. The faster you improve, the sooner you benefit from the improvements in the process.

    It’s just not about reviewing the process twice a year or every quarter. Continuous improvement demands that every individual part of the DevOps process should get better all the time.

    Dishonesty About Your Progress

    It is important to be clear about goals and timelines as an individual contributor in the software development process. A delay from an individual contributor can lead to a delay on everyone’s part in the process. This also adds to the lack of trust on a team’s potential.

    Whether it is about building features or changing processes, make realistic estimates. It is important to break your tasks into smaller pieces, making it easier for estimates.

    Change Comes Easy

    Change is a part of the growth process and it’s inevitable. But most people fail to adapt to change and continue with familiar patterns, especially when change is difficult.

    It is important to keep adapting to changing trends in the industry, processes and technological advancements including the software delivery lifecycle to evolve and grow, even when it is tough. Increased success will always bring more willingness to change.

    Conclusion

    DevOps is a process that drives innovation and business growth at a faster rate, provided you keep a check on the pain points that hinder the successful DevOps implementation.

    — Veritis

  • Focusing on the True DevOps North Star: Continuous Improvement

    Focusing on the True DevOps North Star: Continuous Improvement

    When we look beyond the fundamentals of tearing down silos and establishing greater collaboration, communication and transparency, DevOps is a label assigned to a framework of best practices and technologies that organizations leverage to deliver systems faster, more efficiently and without sacrificing quality. The best practice within that framework is continuous improvement, which provides stakeholders with data and feedback to constantly improve their ability to deliver products that advance strategic business objectives. This is done through key performance indicators (KPIs) that align with the goals of the business.

    Continuous improvement thrives on a robust program of KPIs that measure key attributes of a successful development team in the context of what is important to your organization. These KPIs provide you with the opportunity to continuously evaluate your system delivery processes and supporting technologies, and identify opportunities to make changes that produce better outcomes. In general, all organizations should be continuously improving their system development and delivery against three primary KPIs:

    • Quality: The value and performance of software you deliver to customers.
    • Velocity: The speed at which you develop and deliver software to customers.
    • Efficiency: The ease (low resource consumption, minimal latency) with which you develop and deliver software to customers.

    For now, let’s focus on what’s required to continuously measure and improve against them.

    Continuous Improvement KPIs vs. Metrics

    KPIs provide baselines for minimally acceptable performance levels across critical areas that impact the success of your business. Metrics measured against these KPIs help development teams improve what they’re doing to support the performance of the business in light of its goals.

    There are hundreds of metrics available (escaped versus trapped defects, features deployed and mean time to X, to name a few). The problem is most organizations focus too much on non-business-related metrics and data points and end up measuring the wrong things, such as how many lines of code have been written. This data may be interesting, but it tells you nothing of how well or within what time frame the code was written, or how that affects the delivery of value to customers.

    Your metrics should align with the goal-oriented KPIs of your business. For example, if a goal is to increase the quality of software after an influx of customer support issues related to defects, you should measure how many defects are escaping and how many are being trapped in testing. However, the remaining challenge for most organizations is actually capturing this metrics data to accurately measure progress and continuous improvement against, for example, a quality baseline.

    Collecting Data for Continuous Improvement

    A large reason organizations struggle to capture the right metrics data is they rely on outdated project management tools and manual effort. Developers and other team members painstakingly capture and contribute metrics data through status reports and meetings. Project managers then spend the bulk of their time analyzing and producing even more reports to provide the necessary feedback to support continuous improvement.

    In a digital economy where fast beats slow, this slow approach of manual data collection constrains and negates the business objectives of increasing quality, velocity and efficiency simultaneously. Core to Agile is the production of working software and minimizing the amount of work not directly related to that endeavor. If you want to move to an agile, iterative world, you want to minimize activity or any work that’s not directly related to the software delivery effort.

    That’s why, for true continuous improvement, you want your tools to automatically produce the right metrics data to measure and continuously improve upon KPIs, rather than relying on developers to attend status meetings and feed project managers information used to manually build reports.

    Once you’re able to visualize this data with a modern dashboard-driven analytics tool, you can use that information to constantly assess and evaluate system development and delivery productivity, and help developers make behavioral changes. You will have the necessary information to tweak processes and tooling and better educate team members.

    For example, if your software quality drops below its KPI-defined baseline and your metrics show increased efforts utilized to resolve break/fix issues, you can make a valuable correlation leading to smarter actions to improve quality, such as tweaking or changing testing methods and possibly using more effective testing tools.

    In this way, continuous improvement becomes embedded in your software delivery architecture, as you’re no longer making gut-based decisions that require you to wait for an outcome and guess again. Instead, you’re using data to drive strategic, fact-based shifts in behavior as you develop software, with the knowledge that these changes will have a real impact on the business.

    Making Continuous Improvement Across Platforms

    Ultimately, continuous improvement must reach across platforms in your organization—from the cloud to the mainframe. Development teams should work to continuously improve system delivery across all development platforms.

    The KPIs mentioned must apply to the entire development team and business, not just developers on one particular platform or skill set. You want to identify KPIs that are critical to the successful delivery of systems that support your customers, employees and business partners.

    Now that we have covered the importance of continuous improvement through the use of system delivery KPIs, stay tuned as we explore the individual topics of quality, velocity and efficiency at a deeper level in subsequent articles.

    — Rick Slade

  • The Top 5 Ways DevOps Fails – and How to Prevent Them

    The Top 5 Ways DevOps Fails – and How to Prevent Them

    The working hypothesis for a Gartner report on how to avoid failure with your DevOps effort is that, unless the trajectory changes, “Through 2023, 90 [percent] of DevOps initiatives will fail to fully meet expectations.” The reason? You could boil it down to management not fully understanding DevOps tenets and nuances—things such as targeting business value, measuring success, meeting cultural/organizational challenges, fostering collaboration, understanding the inherently iterative process and managing for realistic expectations.

    DevOps is about people from multiple disciplines coming together to solve problems streamline workflows, develop new processes, break down silos to develop business value. “A lot of people fixate on the tools,” said George Spafford, senior director analyst, Gartner and co-author of the report. “They identify best-of-breed, lay out their toolchain and say, ‘Ta-da!’”

    The tools are important, but they are not the difficult part of DevOps. They are not a key obstacle. To succeed with DevOps, you often have to do something much more difficult: Change mindsets. Gartner identified these five top reasons for the failure of DevOps initiatives:

    1. Doing DevOps for DevOps’ Sake

    It’s important for DevOps initiatives to be grounded in generating business value. If the main goal is to achieve DevOps, you won’t be able to demonstrate sufficient value to sustain support. Failure to identify a business goal and focus the effort on attaining that goal can shut down the DevOps initiative  in only a few months. Identify business value by working closely with business stakeholders on a project-by-project basis to identify opportunities or obstacles and define the business value that will be developed. Avoid the temptation to rush DevOps implementation by taking too large a leap. Trust the DevOps process.

    2. Don’t Ignore the Culture

    DevOps can be intimidating in the early stages. Done right, it usually involves organizational change. People need to understand from leadership that this is not optional. They also need to understand what DevOps is and ultimately how it will affect them. Otherwise, what they imagine will tend to be much worse. It’s also of chief importance to communicate the business goals, both for instituting DevOps and the business value that you hope to generate. Senior leaders must recognize that DevOps teams represent “a fundamental shift away from traditional command-and-control hierarchical management models,” according to the report. “To improve agility, decision-making must move to where the information is.” Relaying information up and down the chain of command to make a decision isn’t feasible with DevOps. The teams need to be empowered to make decisions themselves. For that to work, key DevOps team members need to be fully aware of senior management’s strategic priorities.

    DevOps thrives in an open, honest environment where a frank exchange of perspectives is discussed, analyzed constructively by the group leading to decision-making. Many DevOps initiatives fail because they give short shrift to selecting people with the right temperament to help manage this process. Gartner suggests choosing people who you would describe as being team players, trustworthy, motivated, accountable, smart, experienced and effective communicators. Other words that come to mind include responsible, high emotional IQ, fair-minded, open-minded, aboveboard, not prone to casting blame, respectful and collaborative. In the end, for DevOps to work, you need to foster the type of environment people from multiple disciplines, with multiple agendas, can come together in a small team and get things done.

    3. What We Have Here is a Failure to Collaborate

    DevOps should not be limited to just IT and Ops. For it to succeed in generating business value, DevOps teams must work with other groups and stakeholders. This work “requires a systemic perspective and involvement, not uncoordinated silos,” according to the report. That said, while there is no magic number of DevOps team members, some have recommended five to 10 people. When you get into the range of 20 people, you may find that you DevOps effort is less effective. (Aside: It is possible to have more than one DevOps team.)

    In considering collaboration, don’t forget senior management. Look to gain the support of an executive who can help champion the effort. Finally, you know that DevOps is working when DevOps team members are collaboratively compromising deferring to each other’s needs. The trick is to solve multiple problems with every decision.

    4. DevOps is Iterative

    Too many companies get caught up in the notion that they can launch DevOps in a single bound. According to the report, historically, traditional transformation approaches have a high failure rate. “DevOps involves too many variables for this type of approach to be successful in a large IT organization,” Gartner noted. “An incremental, iterative approach lets organizations focus on continual improvements and avoid the risks” of what is often termed the “big bang” approach. DevOps by its very nature is focused on continuous improvement with an iterative process, rolling out smaller improvements more quickly. Any thought of launching it all in one fell swoop misses the point and shows a distinct lack of understanding about the principles of DevOps.

    5. Set Realistic Expectations

    DevOps and DevSecOps are enjoying the huge level of interest and popularity among enterprises. When that happens, the hype tends to overinflate expectations about the outcomes. Gartner advises that you manage expectations by agreeing on objectives and success metrics. Establish your starting point with whatever metric you adopt, then pursue the goal iteratively. According to the report, “DevOps is not a one-time effort; rather, it’s about trying over and over again.”

    — Scot Finnie

  • DevOps and Systems Thinking: The Farmer, His Tractor and Olive Garden

    DevOps and Systems Thinking: The Farmer, His Tractor and Olive Garden

    As a DevOps and Agile consultant, I work with many technology leaders who see DevOps as this big tangled mess of which they are trying to make sense. When I talk to them, I have to teach them to lead in a systems-thinking manner, a key tenet of DevOps. Making sense of systems thinking is no easy task, but to make it a little simpler, let’s tell a tale of farm-to-table that includes the characters of tractor, farmer and popular Italian restaurant Olive Garden.

    A tractor is at the very most multi-purpose—it can till the field, spread fertilizer, pull a trailer to return a harvest, etc. The farmer, on the other hand, might be interested in things such as the acidity of the soil, water levels and local weather forecasts, but his ultimate goal is singular (to produce a yield of crops) and his domain expertise is narrow.

    Let’s say this particular farm provides tomatoes to Olive Garden. Olive Garden views the relationship between farmer and tractor from a completely different perspective. It cares about purchasing tomatoes to add in a variety of dishes, and cares much more about getting the tomatoes delivered to the store than how those ingredients were produced. After these tomatoes leave the farm, they become part of a complex process of delivering quality ingredients to the plates of customers.

    Now that the picture has been painted, let’s pretend that the farmer is really a member of the development team, the tractor is Jenkins, and Olive Garden represents the leadership team or their business priorities. The farmer, or developer, is thinking very narrowly and tactically. Jenkins, or the tractor, can’t prove the farmer is moving business value from one end to the other. Contrastingly, leadership wants to see everything done in a holistic way, connected to metrics and business value. This scenario leaves farmers and Olive Garden working in silos and thinking differently about how to reach goals. Sound familiar?

    This is where systems thinking, or holistic thinking, can help unite leadership and technical teams, improving culture, customer satisfaction and more. So, how do we get from this blasé transaction of tomatoes to table (or code to customer)? In general, if we only focus tactically on what we’re trying to accomplish, we aren’t thinking holistically. Holistic thinking means looking at the entire delivery toolchain and how a single piece of code ultimately will affect the end user or customer.

    The goal of leadership is to try to drive vision and to make decisions based on real data. Developers need to try to prove to leadership, especially when they start talking about tools, automation or cultural changes, that there’s going to be value in those initiatives. Sounds easy enough, but sometimes leadership doesn’t provide a good vision for how they want developers to think outside of the box, and so, they’re stuck. We’ve seen this picture before. We have DevOps engineers that are just another silo in the process; not intentionally, but because leadership doesn’t set a good vision. Systems thinking isn’t in place.

    As a consultant for Agile teams, I often see Agile and DevOps mixed together. And what I don’t agree with is that the intersection point is small; that’s a common misconception. But when we want to think outside of the box, we need to focus on ideas and capabilities and we need to be able to make data-driven decisions.

    So, what is the intersection of Agile and DevOps? Agile is just a component of DevOps. DevOps is the extension of Lean and other methodologies that came before it. In other words, Agile and DevOps can’t live without each other. In organizations that are trying to do both, I’m coaching them to try to utilize both frameworks and both cultures to do what they need because they’re ultimately the same.

    Providing a taste of data-driven DevOps to leaders is how to get them to turn their head in the direction that you want it to go.

    Ultimately, systems thinking breeds continuous improvement because, if you have a holistic view, you’re monitoring all parts of your process, and so you can have more meaningful retrospectives and you’re thinking about what you can improve all along the way. And you’re on a journey to make your organization, or your team or yourself, epic.

    — Logan Daigle

  • Keys to Improving Enterprise DevOps Practices

    Keys to Improving Enterprise DevOps Practices

    As enterprises move to adopt DevOps practices, there is a desire to measure where teams are on their journey. This sometimes leads to the development of maturity models used to assess teams’ levels and progress. While I am not going to pass judgment on what might be useful for certain organizations, I believe that the real key is to drive positive DevOps practices, which include continuous improvement through data such as lead time, frequency of deployments and mean time to resolution (MTTR) (i.e. the key metrics from the State of DevOps Reports).

    Any static maturity model will become outdated. What’s more important is that teams are taught concepts that can help them continuously evaluate what is stopping them from delivering more quickly so that they identify areas for improvement. Key to this is the lean concept of value stream analysis. If you walk up to a team and ask them why they can’t go faster, they will typically say they are waiting for something. They could be waiting for more work to flow into their backlog. They could be waiting for infrastructure needed for development or testing. Or, they could be waiting for another team to develop a service they need to consume.

    Many teams don’t spend time in retrospectives talking about how to overcome these types of blockers or wait states and developing countermeasures as continuous improvement initiatives. One reason for this is the lack of objective data that can be analyzed to provide insights on this. This is where the lead time metric comes into play. Historically, lead time has been defined as (last) code commit to deploy into production. While this is important, it only tells part of story because accelerated delivery and feedback really starts with a customer concept and measuring how long this takes until it is delivered into production so feedback can be provided.

    One challenge to providing this kind of end-to-end metric, which spans the entire delivery value stream, is the lack of an integrated delivery pipeline from which data can be automatically collected. A customer concept starts in the portfolio space, which might result in data being entered in some type of PPM (portfolio management) system. Once approved, this results in features being created which eventually should flow into a product backlog. Stories are then created that can be pulled by the agile line supporting that product into an iteration. This information is typically in some agile management system (e.g. Jira or IBM Rational Team Concert). Then the team develops and builds the stories, tests them and deploys them into production via a deployment tool like UrbanCode. So, this flow of work goes through various tooling and generally is not visible or easily traceable across the value stream.

    Our initial goal in measuring lead time was to shift left and measure the time from story card backlog until the story was released into production. This would then give us four discrete measures that would provide more insight into the time spent in different parts of the value stream.

    1. Time spent in the backlog
    2. Time spent developing the story
    3. Time spent testing the story
    4. Time spent once the story was completed (marked “done”) until it was deployed

    We mapped the first and last categories into wait times and the second and third into process times to provide a baseline of this metric. While we have just started providing this information to teams, we are finding that scrum masters believe this type of data can be used in retrospectives to better understand why some lead times are high. They also believe that this will help the team better understand when blockers are encountered during development and testing and what contributed to them. We also plan to make that visible as part of our metrics (time spent in a blocked state). Tooling like TaskTop Integration Hub can help integrate your pipeline tooling to provide visibility and insight.

    Once teams gain more insight into what is slowing them down, they can identify countermeasures that can be applied. Categories of wait-states include:

    • Waiting for a dependent area to provide functionality necessary to complete a feature
    • SLAs associated with a service that is provided by a centralized organization (e.g. performance testing or security testing)
    • SLAs associated with infrastructure needed for an environment
    • Contention for a shared test environment

    Countermeasures associated with these types of wait-states are:

    • Architecture decoupling
    • Dark Launching / Feature Toggling
    • Expanding cross-functional teams to enable them to do self-service performance and security testing (at least some portion of it)
    • Automated Provisioning Capability for environment to avoid wait-states and contention

    The “State of DevOps Report 2017” contains information on the importance of architecture and how decoupling dependencies (using APIs and microservices) can mitigate certain types of wait states. DevOps Case Studies provides more information on applying DevOps practices such as dark launching.

    But again, at the heart of this is getting teams to think more about what their value stream actually looks like, how long it takes to deliver business value that can generate feedback and what is getting in their way of going faster. This is not a technology play. This is not something that somebody can sell or educate you on. This is something the team itself needs to take on.

    A good starting place for a team is to educate themselves on some of these concepts for DevOps practices using a book club. A great place to start is to study the “Phoenix Project.” This novel approach combines aspects of both DevOps and Lean to drive home some key points in the journey to discover types of work, manage work in progress and ultimately make visible and gain control over the work being done for the business. Once a team has an understanding of their value stream and blockers, they can then study the “DevOps Handbook” that provides practical guidance for improving their delivery capability and speed.

    About the Author / Carmen DeArdo

    Carmen-DeArdo-sqCarmen DeArdo is the director of Build Technologies at Nationwide Insurance. He is responsible for helping drive accelerated delivery utilizing Lean and DevOps techniques across the end-to-end delivery value stream.  One current focus area is the creation of an integrated delivery pipeline capability.