devopsy.kinsta.cloud

Tag: agile culture

The Need for Agile, Adaptable IT Infrastructure
Through the adoption of Agile concepts and new best practices such as automated testing, organizations can move beyond the innovation curve and bolster their IT infrastructure. In fact, the need to build agile and resilient IT infrastructure has become increasingly pertinent over the past 18 months.

From remote working and managing the diverse needs of employees in remote locations to the growing rates of cybercrime, the move from the physical world to the virtual one has seriously impacted the ability of organizations to operate. It comes as no surprise that business leaders are increasingly investing more in new tools and technologies to improve their IT infrastructure, transform operations and drive business value.

That said, it still remains relatively rare for enterprises to wholly adopt Agile approaches and techniques, despite the fact that doing so can help improve the efficiency at which goods and services hit the market. The fact is that many technology companies still do not use Agile as it is difficult to implement at scale. In addition, Agile transformation demands a cultural change, which can often take time.

Nevertheless, sooner or later, Agile IT will need to be implemented across businesses in various industry sectors, as well as across all branches of an organization. Our experience has been that Agile transformation will help your business grow and succeed.

What is Agile IT?

Agile is a philosophy—a mindset that can be applied to improve the provisioning, management and operation of digital infrastructure. Agile promotes business-led development, whereby a product owner and software development team collaborate as a single entity to deliver tasks that are prioritized based on business value. These tasks are also delivered over a short timeframe, such as via two-week sprints.

Essentially, your infrastructure is far more likely to be both secure and resilient if Agile concepts are implemented throughout the software engineering process. As a result, new digital products can be delivered to customers more quickly. For example, Agile ways of working include making small, iterative changes to deliver high-quality results with speed. You can also spin up infrastructure when needed, which keeps the cost of innovation down.

The Differences Between Agile and Traditional IT Infrastructure?

Infrastructure agility is best achieved using modern solutions such as cloud technology. This significantly differs from the traditional approach of having on-premises infrastructure, which cannot be scaled up or down as needed. In fact, on-premises solutions often require extensive upfront capital, while investing in cloud resources works on a pay-as-you-go model to deliver flexibility and elasticity for strategic needs.

The conflict between adaptive software methods and predictive methods is another significant difference between these approaches. Development teams follow a comprehensive plan in traditional waterfall approaches, and any changes must go through stringent change control management. Agile requirements, on the other hand, require flexibility, allowing teams to adjust to changes as soon as they occur. This method is suitable for smaller projects that must be performed quickly and efficiently.

Benefits of Implementing Flexible IT Infrastructure

The advantages of having Agile IT infrastructure are numerous. In fact, the adoption of Agile methods not only promotes business growth but is also a great way to reduce costs and improve team performance. By working in sprints, teams can turn around features more often and nurture their value throughout the business. Agile transformation also enables organizations to offer new products or solutions to customers faster, gain early feedback and make changes if necessary, thus avoiding error from the very beginning.

Cost optimization is another benefit to consider. With Agile infrastructure housed in the public cloud, IT leaders can expand or decommission resources based on consumer demand. Cloud companies’ pay-as-you-go strategy also ensures that costs are kept to a minimum viable level. For example, maximum limitations can be set for the scaling out of resources. Most importantly, agile working methods eliminate the need for substantial upfront investments, resulting in a higher return on investment (ROI).

How to Achieve Agility

The benefits of Agile transformation are clear; however, the journey to achieving this can take time. First and foremost, becoming Agile requires a clear understanding of what it means and why it is important for your business’ competitive context. Once the ‘what’ and ‘why’ are defined, the ‘how’ becomes easy. The three core steps to achieving this agility are:
1. Implementing new methods
  Instead of trying to rework existing IT management tasks and procedures, it is often better to think of new ones as part of the Agile journey. This will ensure that your system’s performance and availability are in line with your core goals.
2. Investing in the right tools
  Agile is all about delivering smaller outcomes quickly. To achieve this speed, automating key stages of the software development process is key. There are a host of tools available to undertake this automation, including hybrid cloud solutions that can seamlessly switch between the public and private cloud. A careful selection of the tools that best fit your needs and the correct implementation of these throughout the organization is paramount to achieving success.
3. Changing the culture
  To become an agile business, the entire organization requires a cultural change—from how the business discovers a problem to how that problem is resolved by technology teams and monitored in production to enable a faster feedback loop. At every stage of the process, team members need to perform tasks differently, which often requires training, buy-in from the wider team and a collaborative approach.
Investment in Agile IT is a smart decision for business leaders hoping to transform their operations, ensure resilience and drive business value. By choosing infrastructure that caters to these needs, you can save money and ensure confidence at critical moments.
November 10, 2021
3 Building Blocks for Enterprise Digital Transformation

DevOps has gone from a new idea to a buzzword in every boardroom over the last decade. With society increasing its reliance on digitization and pushing their preferences for speed and convenience, enterprises of all types have had to change their business culture to help their teams to work together with greater speed and autonomy.

While the pandemic has undoubtedly heightened the importance of DevOps in the workplace, its widespread use predates the last few years. HGS Digital research from as far back as 2018 found that only 3% of software development businesses had never heard of DevOps. The 2021: Future of the Atlassian Ecosystem report revealed that 54% of organizations have implemented a DevOps strategy—up from 48% in 2020. A further 27% of respondents are hoping to adopt a DevOps strategy in the next three years.

Indeed, DevOps is now mainstream, and the uptick in job listings for ‘DevOps engineers’—as well as enterprises’ quickness to tout their ‘experienced DevOps teams’—is perhaps further evidence of this. However, some of these postings and sentiments can also be considered red flags as they suggest that organizations are applying DevOps practices to isolated teams. Or worse, they are simply labeling traditional engineering roles with the DevOps label rather than implementing a complete mindset shift that applies to the entire organization and enables it to release reliable products at a much faster pace.

With this in mind, here are three key building blocks for enterprises looking to avoid common downfalls and effectively scale their DevOps strategies. These will help them change the way they work and think across all aspects of development and operations.

Changing Culture and Empowering Employees

Everyone needs to be on board for DevOps to be successful, and buy-in is strongly dependent on the business culture they are working within. For example, Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations. And the reasons why have to do with issues around organizational learning and change.

To put it another way, if employees don’t understand DevOps’ deeper thinking and benefits both to them personally and to the wider group, they will naturally be resistant to the change. It is, after all, an entirely new way of thinking for many departments, especially operations teams who traditionally reduce risk by minimizing change and taking things slowly. DevOps encourages them to speed up with minor changes delivered through continuous integration operating in a fail-fast and often fail-forward pipeline.

Therefore, educating employees is vital for success. In particular, organizations should give staff a clear idea of how it will feel to work differently. Shared definitions of success, shared vocabulary and shared visibility of the work to be done is key. With that—and along with sharing actionable insights that teams can apply to their work and then observe the results—no matter where they are in the pipeline, the real value of DevOps can be achieved.

The reality is that people are the most critical component of any DevOps transformation, making their commitment to the cause non-negotiable for success. Despite the tech-heavy nature of software development, soft skills like communication, collaboration, flexibility and decision-making must be prioritized as much as security, coding and infrastructure knowledge. It’s imperative that all businesses look to adopt a DevOps mindset and implement these traits into their culture in the future.

Applying Four Fundamental Processes to the Foundation of DevOps

That said, a successful DevOps transformation can’t happen unless enterprises step away from traditional IT’s ‘trust but verify’ methodology. Instead, they must incorporate a set of essential processes that empower everyone to work more efficiently and effectively toward achieving faster, high-quality software delivery to suit the end-user’s needs. These fundamental processes include collaboration, automation, continuous integration and continuous delivery (CI/CD) and monitoring.

While collaboration has been one of the most significant rallying cries for enabling globally distributed IT teams to align their goals and meet their objectives, automation has also been highly crucial. Many of those ingrained in DevOps environments will tell you that automation is what makes DevOps highly valuable. It helps teams achieve high levels of efficiency and allows employees to focus more on complex problems and less on repetitive tasks. When a company’s automation strategy is aligned with its broader business goals, it can help deliver value at scale.

But as is the nature of software development, problems can arise. And this is where continuous integration and delivery come into play; it forces developers to merge their source code updates with others far more frequently than they might otherwise choose to. Operations teams can ensure they’re not creating a bottleneck with manual testing to get releases out to users. The approach means smaller changesets; helping to identify, target and resolve bugs more efficiently. This increases the flow of work, the quality of releases and helps to avoid nasty problems at the end of the development cycle.

But there’s no point in having a speedy, heavily automated CI/CD process with a genuinely collaborative culture if enterprises don’t take the time to measure what’s working and assess which actions need to be improved. This is why an effective DevOps plan needs to be built on the mantra ‘implement, measure and improve’. After all, DevOps is about maximizing value and efficiency through increased visibility of work and constant feedback. Measuring real-time metrics becomes vital to ensure business’ transformations are in line with their objectives at all times. If enterprises stick to these fundamentals, they’re well on their way to a successful DevOps strategy with complete buy-in.

Adopting the Right Tools for Transformation

As teams grow and DevOps processes scale, predictable performance is imperative. Therefore, the enterprise’s tools must be available around the clock and should perform at a high level to support their collaborative pipeline.

But using DevOps tools doesn’t automatically mean organizations are applying DevOps principles. The value of tooling is limited by businesses’ commitment to using them holistically with the sort of culture and processes mentioned above. It is this combination that allows them to transition how they develop and deliver their products. With all that said, it’s important to understand how important it is to adopt the proper toolchain—and the wide variety of choices and combinations available—this is why it’s easy to understand why decision-makers might become overwhelmed.

After all, there’s a lot to keep in mind. They need to choose tools that step up their collaboration, keep context-switching to a minimum, aid automation, encourage visibility and allow for effective monitoring. But there’s also the risk that they’ll pick the solutions that they feel most comfortable with, which can be counterintuitive to transformation. This approach can lead to a tool binge, bringing on too much technology where integration isn’t a priority, and leaving enterprises with nothing that does the job they need.

With this in mind, enterprises need to take the time to consult on which tools are right for them while constantly keeping the fundamentals of DevOps in mind. To illustrate just how valuable this is, DORA and Google Cloud’s 2019 State of DevOps report found that the highest performing engineers are 1.5 times more likely to leverage easy-to-use tools. Meanwhile, failure to do this is perhaps a primary reason why a separate study from the DevOps Institute uncovered that the DevOps transformation journey is still arduous for more than 50% of respondents.

Taking the Next Step Toward DevOps

A successful DevOps transformation rests on in-depth understanding, mass buy-in and an organization-wide adoption of fundamental principles and practices. When this agile mindset is applied to the people, processes and tools that make up an organization, enterprises can drive significant change across their teams while increasing their products’ reliability, stability and security.

It’s always important to keep in mind who DevOps is designed to benefit the most—the customer. This mindset is particularly valuable in today’s landscape, where businesses and consumers alike are flush with more choice than ever. With speed and convenience now at the forefront of most people’s purchasing decisions, DevOps can play a huge role in helping organizations strive for greatness and offer the customer something they didn’t even know they needed. Using the above building blocks, organizations of all sizes can dramatically improve their customer experiences and work more efficiently to quickly get the right products into their hands.

September 10, 2021
DevOps Agility Shines in the Midst of a Pandemic

As a career developer and now a chief technology officer, I am experiencing firsthand how COVID-19 has forced us all into new ways of working. I’m also aware that these new ways may be with us for a while. Last month Gartner announced that 74% of companies intend to shift some percentage of their workforce to permanent work from home status.

The fears many technology leaders have is that working from home will disrupt the processes in place for coworkers to communicate and collaborate. I would argue that DevOps overcomes those challenges by design. Organizations have become increasingly confident in DevOps with research from Global Market Insights finding “DevOps Market size exceeded $4 billion in 2019, and is poised to grow at over 20% CAGR between 2020 and 2026.” Companies that hold onto practices that are less agile will find they hamper velocity and allow competitors to vault ahead in a rapidly changing digital environment.

A study by the software developer CA Technologies ⁠— now part of Broadcom ⁠— found that more agile companies achieve 60% higher revenue and profit growth than their peers. In another study of agile companies, this one from industry research firm Gartner, 74% of respondents reported better alignment between IT and the business.

DevOps and Agile go hand-in-hand toward greater organizational success.

Software Developers Feel the Need for Speed

Developers working remotely will thrive on the unimpeded workflows and synchronous collaboration DevOps makes possible, even while separated. Today, when customers are consuming more digital services than ever, the traditional development methods just don’t meet the speed required. In a recent xMatters survey of 300 consumers, 90% said they are using digital services — from grocery and takeout food delivery to videoconferencing and banking. Eighty two percent said they will continue to do so even after the pandemic is history. Customers previously accustomed to brick and mortar services now have high expectations for uptime, performance and feature sets for digital services, so leaders will have to embrace DevOps to continually improve the user experience.

One Team One Dream

Given the various specializations within organizations, embracing DevOps must often begin by bridging the unique cultures of each team, including development, quality assurance, security and customer success. One way to do that is to establish shared Service Level Indicators and Service Level Objectives with a focus on customer experience. For example, working toward five nines digital service availability, sub-second website page loads and same-day security patch deployments as common goals will aid in the formation of a cohesive unit. Additionally, the team should feel executive-level DevOps buy-in, which should manifest itself in optimal technologies and appropriate alignment of talent.

DevOps Developers Are Hot, Don’t Let Them Burn Out

Developers with experience working in a DevOps organization have always been in demand, and the rapid adoption of digital services is making these software professionals even more valuable. According to a recent LinkedIn report, DevOps is the single most recruited position on the platform today. Attracting and retaining these skilled workers can be extremely challenging.

One way to increase retention is to foster a culture that respects work-life balance. When surveying consumers about the impact COVID-19 had on the adoption of digital services, xMatters simultaneously asked 300 IT professionals about the impact this mass-scale adoption was having on them. Unfortunately, 88% said their work-life balance had deteriorated. Most DevOps teams were already accustomed to being on-call 24/7; so if they’re feeling COVID-19 has pushed them over a line, burnout is a real risk. It’s essential to recognize this and act on it. Providing DevOps teams with the right tools to automate CI/CD in a secure way, even while working remotely, goes a long way.

Time for DevOps to Shine

The changes driven by the pandemic will have long-lasting effects on the frequency with which we use digital services to live and work. Customer experience will remain paramount and those metrics will be increasingly visible at the executive level. We will also see a greater focus on lean practices and cost reduction. I can think of no approach that does more to meet consumer expectations, address fiscal challenges and increase employee satisfaction than DevOps does.

June 5, 2020
From Automated Cloud Deployment to Progressive Delivery

Your team is on its agile journey and you can more or less track a deployment from a story, through git commits, to an automated builder, to an artifact repository, into a container and then onto the cloud. Or, in fact, any other of the many valid variants that lead you to believe your deployments are largely automated. What you can point to is a business request comes in and the result is a service or a new app. Your purview seems to stop before your users can even respond though. Is that good enough?

Let’s go back to the early idea of a release. It was a collection of all the features and fixes the loudest stakeholders had persuaded the product owner to put at the top of the story list. A date was promised, but QA was late, and the persistent stakeholders squeezed a little more juice out of a story. Then it was stuffed into a ball and delivered to your servers overnight, lest anyone notice. The next day, the developers had to deal with the fallout as the support queues grew with confused users.

While developers were getting the hang of the agile notion of automated deployment, the release lifecycle did pretty much end with a deployment going live. This gave certainty that what had been built and placed in the artifact repository was the same thing the testers had seen in the staging environment. And it also had the changes Jira said it had.

This type of release was very much like a birthday present. Your uncle talked to your dad briefly, without your knowledge, and agreed you really would benefit from a new pair of socks. Then these were delivered on the day with the receipt in the bag, just in case you needed to take them back.

The first evolution came with the concept that a release wasn’t exactly synonymous with a deployment. Finally, the end-user’s perspective nudged its way into corporate release strategy–updates could be deployed without necessarily impinging directly on every user. What if there were two identical release environments with clever network switching, meaning only one was truly live? This type of flip-flop arrangement (sometimes referred to as blue/green deployment) allowed changes to be tested internally in a realistic environment before going live.

It was the advertising industry that prompted the idea of A/B testing. Instead of guessing one variation of a campaign might be superior to another, the surprisingly scientific method of using a controlled sample and a variation was used on audiences to see which they preferred. In the digital age, it is possible to deploy two variations of the same release to different server sets. This might mean each user session could be using either release. It would then be necessary to associate the resulting click-throughs, or whatever success measurement is chosen, to the specific release flavor. The worth of this kind of experimentation was only as good as the question you asked, but it was at least observing real user interaction.

Moving on, DevOps environments began to use more feature flags or toggles. These were code paths that could deliver feature changes in live servers, controlled through configuration changes. This reduced the need to re-deploy to make certain changes. Release minded teams were coalescing around configuration, as opposed to just code. Whereas code once compiled and built was locked away in unreadable artifact files–a larger stakeholder community could administer configuration files, usually encoded in English. This helped to keep the feature changes closer to the stakeholders and less likely to slip back into silos.

As a more defined understanding of delivery arrived, so did the understanding of the user community. It used to be the case that a user was a one-line entry in a database. Even firms whose business is not mining their user’s data understand there are different sets of users for products and services.

Traditionally, there has always been internal users or beta testers–those within the firm whose job is to check the bits they understand, or are responsible for, are working as expected. Then outside the firewall, there are the tech savvy community who actively want the latest updates. These guys report bugs and often compare your product with the competition, perhaps using both. This audience will not lose their marbles if you deliver a bug to them. More to the point, they will notice rapidly–perhaps telling everyone on social media–about your failings.

The disengaged users who may only have the free version or tier of your product come next. These people are more likely to work on impressions and are best not disappointed. They are also unlikely to be keen on updates. Finally, the large core of solid users who pay their way, just want things to work and need to understand a path to continuity will already appreciate the software and will understand the roadmap by osmosis. These will probably include your biggest users, too. Of course, if you have no way of distinguishing your users all the above is moot.

With services sitting on a public cloud and CDN like edge services such as CloudFront, the ability to release by territory is much more straightforward. This is also increasingly necessary for legal reasons–EU regulations, for example. This allows for tactical releases to communities in different time zones and sizes. The practice of deploying changed services to a small group for risk mitigation, or “canarying,” is another method that takes advantage of smart routing. This requires the ability to quickly observe and rollback releases though.

Today, most software has some degree of dark launch that restricts the visibility of a release to the appropriate community, until all is well. In this sense, a progressive delivery (defined as “continuous delivery with fine-grained control over the blast radius” by James Governor) can be seen as the virus-like spreading of your software or services from your development teams’ laptops to the last user.

Observing service use is simply part of the core concern of virtually every company in the tech space. From this perspective, progressive delivery changes the way to see your development team as mere builders to user fulfillment specialists, which of course, they always were.

The future will undoubtedly involve increasingly customer-driven releases, which goes hand in hand with the increasing use of data science to study user communities and their exhaust. The important take away is to make sure your team is reaching further to the right-hand side of the product journey, and keep the user’s reaction to what you make as a larger part of your sensory input. Think more about constant small changes and less about ceremonial releases.

— David Eastman

October 10, 2019
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
August 26, 2019
Is DevOps in the Enterprise Real?

Is DevOps in the enterprise real? The short answer is yes, but you may assume it’s only relevant to the world’s leading cloud companies because they’re the ones that make the headlines. DevOps offers the promise of agility, quality and ultimately better-performing software. While DevOps processes can increase agility, and agile approaches are a great help in improving responsiveness to change, the overall process still needs a clear objective, measurable KPIs and a finite scope.

In other words, unlocking the promise of an agile (product) organization requires a few complementary approaches. If those are ignored or applied incorrectly, DevOps agility can become an impediment to adaptability and agility for your enterprise.

Yet, I’ve read so many blogs about how the cloud and DevOps processes solve problems. It’s true they can, but the nuance is that, while a few teams can coordinate change amongst themselves, when you attempt to deploy a DevOps practice at scale, challenges are quickly apparent. For example, if I’m working for a startup that has fewer than 50 developers and very few layers of management between the CTO and her team, the management and communication lines are likely short enough that strategy and direction can be conveyed directly to the teams. However, for larger organizations—where there are many often geographically distributed teams with silos of responsibility and layers of management—far more coordination and communication are required.

In these environments, it is more likely the business will achieve agile teams but not an agile culture. This is because it’s too simple and, therefore, commonplace for these environments to execute in silos not aware of changes to other silos and where environmental constraints and dependencies are not considered throughout the development process.

The best solution to these challenges is to focus on a cascading framework of objectives and goals. Every company has its mission-critical goals—some call them strategic imperatives, others call them (or include in them) board-level mandates—and those goals should cascade into a more refined product, program and team goals as you traverse the management tiers. This ensures the business leaders can set a strategic direction that will be measured in a certain way, and every subsequent layer below them understands how their initiatives align with supporting that direction.

The first critical element for building a successful, sustainable DevOps culture is understanding your goals and how you’ll define and measure success.

The next element is to establish which decisions each level of management can make autonomously. For example, risk tolerance is a strategic decision, architecture and security posture are typically defined for a product, platform-level technology decisions can be delegated to program teams and project teams can then focus on making the more granular technology decisions that will differentiate their product, service or feature.

Finally, communication is key. This sounds trite, but communicating this cascading decisioning framework, exposing the decisions each group makes that could impact the particulars of an environment and then discussing requirements and challenges of architecture and software choices can ensure that each team, at each level, can remain agile and adapt to change effectively.

The question is: Do you have the management rigor to dig into these challenges and own them? The answer likely lies in how important the pursuit of agility is to you and your business.

— Ari Weil

July 29, 2019
Consider the Role of Programmers as Storytellers
Every time I speak with the programmers of our team in casual conversation, I ask what they’re working on. Every time, I get the same kind of answer, “I’m building a dashboard,” or “I’m optimizing a database,” or “I’m testing the user interaction.”

In other words, I get the same answer as the proverbial masons, “I’m laying bricks,” or “I’m building a wall.” But not, “I’m building a cathedral.”

At an abstract level, programmers understand the value of the big picture. But at a practical level, they focus on the immediate next steps. Since time is always crunched, programmers skip absorbing the big picture.

“This is a mistake,” I told them. “Your work improves if you know why you’re doing what you’re doing.”

“How?” the curious ones asked. That’s when I told them the story of Andre.

Andre told me he was creating a dashboard. I decided to ask him the five whys.
1. “Why are you building this dashboard?” I asked. “Because my team leader told me to,” said Andre.
2. “Why does he need it?” I then asked. “Because the client Rudolph told him to build it,” he answered.
3. “Why does the client need it?” I continued to ask. “Because his boss told him … I guess?” he replied.
4. “Why does his boss need it?” I asked him. “I don’t know,” he said.
I knew I couldn’t get further. So, I asked to see the dashboard. It showed 14 metrics and their performance across time. I had no idea what I was supposed to infer from the numbers.

I spoke to Rudolph, the client, and asked why he needed the dashboard. His answer was similar, “Because Victor, my boss, wants to know how our operations are doing.”

“So, do you need all 14 numbers? As a table?” I asked him. “Yes,” he said. “I need to know how each number is performing.”

I tried a different tack. “Suppose you’re on an elevator with Victor, and he says, ‘Hi Rudolph, how’s it going?’ How will you answer? Are you going to recite all 14 numbers to him?”

Rudolph thought for a while and said, “No. I’ll probably just tell him about what’s improved and what’s worsened. Then I’ll tell him what I’m going to focus on improving. That’s all that matters to him.”

That left Andre and me wiser. Our aim was not to show 14 metrics. It was to help Rudolph and Victor figure out what’s improved and worsened.

This helped Andre change three decisions.

Change the Development Priority

Not all metrics were equally important. Some were consistently stable. Some fluctuated a lot. He wrote the queries for the fluctuating metrics first. So, when the deadline hit and he wasn’t fully ready, he still had the most important metrics in place.

Change the Design

He added simple traffic-light colors to the metrics that grew the most and fell the most. It made it much easier for Rudolph to figure out what’s improved and what’s worsened. Rudolph never commented on it. But we knew without it, his response would have been, “There’s something wrong with this, but I don’t know what.”

Change What to Optimize

The queries run slowly. Rather than optimize all queries, Andre reordered the queries to render the fluctuating metrics first and optimized those. Those results appeared first, markedly improving how fast the dashboard appeared to load.

Conclusion

There’s a reason modern agile processes refer to user stories to capture requirements. But we lose the spirit of the story when we write, “As a user, I want to see the performance of 14 metrics.”

The next time you write a requirement, don’t hesitate to write the full user story for the programmers. “When my boss is in the elevator and asks for a quick summary, I want to tell him what’s improved and what’s worsened, in less than 10 seconds.”

Stories are memorable. They are easier to understand and communicate. They help explain why we’re doing what we’re doing. They also help prioritize development, improve the design and optimize better.

Always ask for requirements as stories. Always narrate requirements as stories.

— S. Anand
July 24, 2019
Successful Digital Transformation Starts With Developers

Digital transformation (DX) continues to be a primary focus as companies both large and small look to become more agile, improve and accelerate the delivery of product and service offerings and enhance data-driven business decisions. The C-suite typically leans on IT departments and developers to champion such transformations, designing the software and tools that will lead the experience both internally with staff and externally with customers. The challenge often lies in the fact that most organizations lack the software resources to drive a successful transformation. In addition, research has found that 45% of executives don’t know where to start with DX projects, resulting in added pressure on the developers who hold the technical knowledge but may lack the managerial expertise for a successful rollout.

So, with IT having the opportunity to be the hero or the scapegoat of a DX initiative, where should development teams start? Typically, digital transformation requires development transformation, so you can start at home, by modernizing the way you develop and deliver software. Doing this also significantly improves the odds of a successful digital transformation and puts development in the driver’s seat.

Here are four factors to prioritize before kicking off a DX project:

Buy vs. Build

A DX initiative requires a number of digital tools and software applications, some of which can be purchased through third parties while others may need to be built in-house, depending on the desired goals of the program. Organizations must determine whether they want to build or buy new software solutions, and the answer is almost always mixed. Most developers believe that each application can be built in-house, while the C-suite often encourages purchases from a third party to accelerate adoption. Before starting to code, ask yourself if the solution you need should be bought or built. Oftentimes, the same goal can be achieved through a purchased solution, empowering you and your team to spend more time customizing those solutions rather than starting from scratch while focusing on the projects that will have the biggest impact on the business—ultimately accelerating time to completion.

Accelerated Rate of Change

Once applications are built and available to the public, you can expect bugs to be identified and requests for improvements to be made at an accelerated rate. Developers are constantly making software updates, but when applications are being used to support DX, the rate of change for business requirements is going to speed up, especially when those applications are customer-facing. Developers will need to learn fast and iterate quickly, so it’s important to establish an agile culture within your team.

Adopting a DevOps philosophy often will be the most successful approach, as it enables your team to test and troubleshoot quickly and enact change across the platform. This approach also assists the rest of the organization in adopting DX practices, delivering a more seamless experience and universal data-sharing. Developer teams must be wary of traditional quarterly or annual planning cycles that create silos, slow agile processes and hinder successful implementations. By breaking down these silos, your team will gain better insight into what is and isn’t working and enable swifter improvements, creating a culture that embraces the changes that come with DX.

Modular Software Architecture

Software architecture is incredibly important, as it directly impacts the team’s ability to react to rapid change. A more loosely coupled, modular architecture puts the developer team in the best position to evolve quickly with fewer dependencies, enabling them to make updates and replace components over time to meet business objectives and customer demands. The ability to reconfigure or replace components without having to recode the entire system also assists in build-versus-buy decisions, with developer teams purchasing add-ons to incorporate into a system and solve problems quickly.

DX Outside of Organizational Barriers

We work and collaborate in a digital ecosystem. External APIs, third-party data-sharing and interoperability are all requirements as organizations roll out new tools as part of a DX initiative. DX comes down to building a digital ecosystem that flows outside of the organization, whether it is employees working remotely or customers integrating your tools into their existing solutions. Your company’s software needs to accommodate these capabilities to enable a more seamless and well-rounded DX approach.

DX is a Journey, Not a Destination

A successful DX initiative should be seen as a culture shift, not an end result. The digital world is not static, and DX is a practice that enables an organization to learn fast and be lean and nimble. As soon as you’ve reached one milestone, there’s a whole new set of rules to play by to get to the next, requiring the developer team to recalibrate. By taking a realistic, process-oriented approach, the developer team will have the mindset and tools necessary to make DX successful.

— Jeff Fried

June 10, 2019
Successful DevOps Initiatives Start With Company Culture
What initially drove the need for embarking on the DevOps journey in your team or at your company in the first place? Was it:
- Market shift?
- New leadership or an acquisition?
- New product or service idea?
- Cost savings or consolidation?
- All of the above?
Whatever drove the need, my guess is there were pre-sales demos, reorganizations and training on new tools that were promised to solve all your DevOps problems along the way. Now, I must break your heart just a little: Buying new tools or apps will not, on their own, ensure positive DevOps outcomes.

A tool-first approach is ineffective. In fact, it may actually generate backlash from the individuals or groups who are invested in protecting the status quo and result in a wasted implementation effort. Imposing new methodologies or processes across teams through new tools can cause people to dig in, generating responses ranging from passive-aggressive to overtly destructive—both contributing to failure.

It Starts With Culture

Your success on the DevOps journey starts with culture. Culture transcends tools, methodologies and processes, making use of all but not relying on any. Culture was, and always will be, present, and much like continuous development—routinely referenced in DevOps—it is continuously influenced by everyone and everything in its environment.

The successful implementation of DevOps must begin with a conscious effort to reassess and evolve a company’s culture, supported by the tools. For example, continuous deployment as an initiative will only find traction when members of the team all believe, philosophically, it is best for the organization. It requires a certain kind of individual.

A culture of rapidly evolving and adapting teams focused on continuously discovering, developing and delivering demands a commitment to evolving toward a more contemporary integral DevOps toolset, not the other way around.

Culture Alignment as a Competitive Advantage

Cultural alignment is not a buzzword bingo box that gets checked off. One’s sense of alignment with a clearly articulated mission and set of values, coupled with a way of working in a team and supported by the right tools, generates velocity and efficiency. This alignment becomes a competitive advantage.

But, doing so demands all participants to be more conscious of how what they do affects everyone and everything else, in real time.

Culture Change is Difficult but Achievable

It can be very daunting or even scary if your company culture has a long history, producing images of the Borg or Hive, depending on your age bracket. Changing a culture is difficult. Here are some thoughts on where you might start.

Learning agility: Focus on learning to dance with VUCA (Volatility, Uncertainty, Complexity and Ambiguity) instead of being consumed by it.

Diversity: Commit to working with people with wide-ranging intellect, backgrounds, titles, CVs, life experiences, ways of learning, gender and energy, instead of working with your mirror.

Trust: Build a work environment based on psychological safety—a sense of confidence that the team will not embarrass, reject or punish someone for speaking up. Knowing takes time and deliberate effort.

Leadership: Adapt and promote a leadership style such as the 3 C’s of change leadership–communicate, collaborate and commit.

Coaching Culture: Consider championing a coaching subculture by applying a methodology such as LACE to work through difficult conversations:
- Listen to understand.
- Ask powerful questions.
- Challenge and support with feedback.
- Establish next steps and accountability.
Worth It

We started with a little heartbreak. But I have had enough conversations about DevOps success and failure to believe that you already knew it was not just about tools. We have all felt the weight of culture when it is not in alignment. Employing some or all of these recommendations will set you down the path of creating your own language that is a requirement for building a culture. Now stop looking at the next great messaging protocol and start working on building an agile, aligned culture.

— Joshua Platt
May 24, 2019
Promoting Purpose in Agile Environments

Agile environments increasingly are becoming a popular option for organizations large and small. Although initially created as a solution for small software development teams with short budgets and complex scopes, it’s been adopted (and refashioned) for all industries and team sizes.

Agile Methodologies: Why They Work

The agile approach seems obvious to us now, but back in 2001 when the idea was incepted, it was a revolutionary one: Give employees the room they need to get the job done and let them do it. Throw out extensive documentation and overbearing technical documents for constantly moving, constantly changing, constantly reassessing and growing workplaces.

“In 2001, a group of experienced software developers got together and realized that they were collectively practicing software development differently from the classical waterfall methodology,” wrote Isaac Sacolick for InfoWorld’s “What is Agile Methodologies?”

“This group came up with the Agile Manifesto that documented their shared beliefs in how a modern software development process should operate,” he continued. “They stressed collaboration over documentation, self-organization rather than rigid management practices and the ability to manage to constant change rather than lock yourself to a rigid waterfall development process. From those principles was born the agile methodology for software development.”

How the Framework Works: Higher Purpose

An agile approach pursues the production of top-tier software. Without an agile framework (or something like it), there is often a distinct lack of purpose-driven principles. From an agile framework, companies can create strong cultures.

Why is higher purpose so important? After the great recession hit in 2008, we were left with some very important questions amid a financial disaster, the likes of which hadn’t been seen in 80 years. When the economic foundations of our world were rattled, many firms were forced to answer what their higher purpose really was.

Without the promise of a steady paycheck or a fat margin, there is all too often an absence of purpose. Even when the economy is performing in a spectacular manner, a lack of higher meaning pervades many mediocre organizations.

“Although a higher purpose does not guarantee economic benefits, we have seen impressive results in many organizations,” reported Harvard Business Review writer Robert E. Quinn and Anjan V. Thakor. “And other research—particularly the Gartenberg study, which included 500,000 people across 429 firms and involved 917 firm-year observations from 2006 to 2011—suggests a positive impact on both operating financial performance (return on assets) and forward-looking measures of performance (Tobin’s Q and stock returns) when the purpose is communicated with clarity. So, the purpose is not just a lofty ideal; it has practical implications for your company’s financial health and competitiveness.”

How to Create Purpose With Agile Principles

Joe Robles, the former CEO of USAA, found this utter lack of meaning to be of immense concern for every level of his organization. Concerned about his employees, he visited them to discern where the company culture could improve. He was surprised to find that his call center employees were happy to collaborate on every level.

It became his mission to imbue this type of mission-driven attitude to every employee and everyone in leadership, through major cultural education. How can other organizations emulate USAA’s successful purpose-driven culture? There are a few steps to achieving this goal.

The first step is to imagine the workforce you wish to have. In agile environments, there is a focus on efficiency. There is no unnecessary research, documentation or meetings; there are only results. Successful outcomes, however, only come from motivated, purpose-driven individuals. That means we must ascend above the employer-employee relationship and, instead, swap it with an inspiring mentorship program.

The next step is to make this dream a reality. Craft an authentic message, promote that message, then promote the supplementation of that message with continual learning, training and dialogue.

Conclusion

Agile environments foster meaning and cooperation. Instead of employees that mindlessly listen to the autocratic directives of their superiors, they are part of a task force who shoulder the responsibility of reaching a higher goal together. This means some critical and divergent thinking must be fostered, which can be frightening to traditionalists of all forms.

In agile environments, you will need to start asking questions that help expand how the team thinks and operates. In addition, listening, analysis and reflection skills must be a primary focus for a higher meaning to be divined.

— Anthony Coggine

May 10, 2019