staging-devopsy.kinsta.cloud

Tag: success

Beware False DevOps Metrics
Metrics are important for any manager seeking to continuously improve critical work processes and the resulting work-product.

That’s why DevOps leaders need DevOps metrics. With the right ones, those leaders can guide their organization’s adoption of DevOps best practices—progressively optimizing staff productivity, business agility and customer experience.

But, what are the right metrics for DevOps success? And, what are the wrong ones?

These next few blogs will offer field-proven guidance on DevOps metrics. Much of the material in these upcoming blogs can be found in the book, “DevOps for Digital Leaders,” which I co-wrote with Kieran Taylor and Peter Waterhouse. And I’d love for you to comment below so we can all share lessons learned about how to effectively measure DevOps maturity—and, just as important, how not to measure it.

Change Your Metrics, Change Your Culture

DevOps leaders tend to struggle with metrics because DevOps entails changes that are both operational and cultural—and span different teams or functional areas, including development, test and operations. So inexperience may cause leaders to adopt new ones that are counterproductive—or, as is often the case, continue using traditional ones that don’t align well with the cross-functional nature of DevOps objectives.

Three pitfalls have proven to be especially common in the transition to DevOps:
- Vanity metrics. These appeal to the “hero” mentality of individual coders, rather than the collaborative process goals of cross-disciplinary DevOps and continuous delivery teams. They include total lines of code produced and total function points created. If incentives are linked to these metrics, developers can focus too much on volume at the expense of other essential activities such as refactoring and design simplification.
- Those that promote interteam conflicts. Metrics that pit teams against each other undermine critical DevOps behaviors—such as code-sharing, mentoring and constructive peer reviews. So, while gamification may be useful in other areas of the business, Agile leaderboards that rank teams based on the prevention of extraneous deployments and changes can actually work against DevOps culture.
- Traditional metrics. Many DevOps leaders persist in utilizing traditional/incumbent ones such as mean time between failures (MTBF) and the ratio of full-time equivalents (FTEs) to servers. But while these may have been useful in the past, they can work at cross-purposes with DevOps transformation. After all, with faster delivery of services, some failure is to be expected. And as IT improves its responsiveness to the business, it must look past costs alone to total economic impact.
What Makes a DevOps Metric Useful?

While future blogs will propose some specific metrics that DevOps leaders should find useful in their efforts to bring about cultural transformation, here are a few general guidelines to consider:

They must be obtainable.

A metric won’t do you any good if you can’t actually capture it. So you need DevOps tools that help you capture the metrics you need. You may also have to measure some attributes indirectly. For example, rather than measuring employee morale directly, it may make sense to use staff retention rates—which you can readily capture—as your performance indicator.

They must be reviewable.

Any metric you choose to employ as part of your DevOps leadership effort must be able to stand up to rigorous scrutiny in a business context. Your credibility as a leader depends on your ability to communicate its relevance to the stated values and mission of the team.

They must be incorruptible.

It’s never a good idea to promote metrics that can be influenced by individual team members or any group as a whole. You should also be on guard against metrics remaining entrenched—despite the fact that they may inhibit change—because bonuses are linked to SLAs associated with them.

Metrics must be actionable.

Useful metrics must enable DevOps leaders to make better decisions about workflows, incentives, policies, training, tools or some other “lever” of transformation. Not every such decision will be a game-changing one—but incremental gains in knowledge lead to incremental improvements in process, which collectively do change the game.

In my next blog, I’ll discuss the metrics that DevOps leaders are using today to successfully drive the digital transformation of their businesses. In the meantime, if this is a topic that interests you, be sure to request a free copy of my book, “DevOps for Digital Leaders.”

— Aruna Ravichandran
March 21, 2017
Best DevOps Practices for 2017

Because the idea of DevOps is still so new, we’re continually having to hone what we view as best practices. At the start of the new year, many people make their own personal goals clear for the year (regardless of whether they intend to keep them), but we tend to head back to our work desks without reassessing how our projects are going. We just jump back in unquestioningly and continue down the path we were on before the holiday.

Mindless plodding away at a goal that had been set too far in the past is perhaps the biggest business mistake we can make. Re-evaluating our approach is often the difference between stagnation and real innovation. A willingness to change tacks and the agility to do so speaks volumes about an organization—that flexibility is rewarded by a market that demands responsiveness from its providers, and it can be a big differentiator between a company and its competition. With that in mind, there are six big goals that we can adopt as DevOps practitioners that will have enormous results on our ability to answer the demands of our users.

Make paying off debt a priority

Most companies are so saddled with technical debt that they hire more people just to cope with it. This is like putting more hoses on a forest fire. When fighting a forest fire, a portion of the team creates a firebreak to deprive the fire of fuel. Likewise, organizations need to dedicate a portion of their workforce to do nothing but eliminate the technical debt that is fueling their operational fires.

Set ambitious goals, but don’t sweat the details

Have goals and objectives, but allow the minutiae to be developed over the course of short intervals. We need to set business-level objectives for our DevOps teams, but we have to be careful to not overprescribe the details. There are many DevOps tools and methods and more arrive every day. Plan to work in two- to four-week sprints with measurable outcomes, instead of six-month project plans. Use the feedback and lessons learned from those short sprints to inform the next sprint’s work.

Don’t leap, but get moving

DevOps is meant to be about quickly moving product from left to right. A common mistake is for companies to wait for “the perfect moment” and then jump headlong into DevOps, creating a lot of disruption at once. This is a recipe for disaster. Identify workstreams that are ripe for improvement from DevOps and start by moving one new benefit from concept to production. Remember, single-piece flow is your friend.

Identify the ‘credit hawks’ and neutralize them

I once heard the saying, “Just because you run out in front of a parade doesn’t mean they are actually following you.” One of the critical pieces that makes DevOps work is a culture of sharing. That means sharing in knowledge, work, credit and blame. A “credit hawk” is someone who likes to jump in front of work already being done and claim he or she is orchestrating it. This seems to be commonplace in situations where DevOps teams exist under mid-to-upper managers with “old guard” mentality. If they take the credit, that leaves the DevOps team with the blame. Neutralize the credit hawks at all cost; they will undermine your culture.

Plan for failure, success through learning

Planning for failure does not equate to “expect failure,” but because we want to move faster so we can try more things, the law of averages tell us that we will also fail more, too. Planning to fail means we know how to conduct a blameless post-mortem, understand lessons learned and incorporate that feedback cycle to increase the likelihood of success.

Promise to break the rules

Your DevOps team needs to be trusted to find the best path, even if that means ignoring a 70-year-old process. This statement might invoke a knee-jerk reaction, but this does not imply “anything goes.” Your objective is to find more productive ways to get product to market and to create safe systems of work. Part of your lease to your DevOps teams also should be to explore new processes that eliminate red tape, bureaucracy and waste. What has worked for the last 70 years may be what is holding you back today.

2016 rewarded those who were able to move fast, and 2017 promises to require us to move even faster. By resolving to make these changes in your company or organization, you are making a commitment to shed the shackles of yesteryear. When freed of these fetters, your application teams will be able to focus and deliver on the one thing we are all trying to do: deliver value directly into the hands of our customers. Is 2017 the year your company will triple its release cadence? Is this the year you deliver every new product into all markets simultaneously? Or perhaps this is the year when your applications suffer zero outages. The goals and the stories are yours to tell, but one thing is for sure: Resolutions without action are just wishes.

About the Author / Adam Bowen

Adam Bowen is an information technology leader with more than 15 years of experience in technical, sales and senior leadership roles. As the Worldwide Innovation Lead at Delphix, Adam works with thought leaders of the Global Fortune 100 to eliminate key business constraints through innovative new processes, offerings, and technologies. Connect with him on Twitter and LinkedIn.

January 6, 2017
Social Skills for DevOps: Whose responsibility?

In his post “DevOps developers; don´t be a DevGoof” on staging-devopsy.kinsta.cloud Parker Yates pointed out, that developers have to become more social. Devs should better realize that they need to become a normal part of the business social structure. That is really true and extremely necessary to make DevOps more efficient.

But is this the whole truth? And who is responsible for the social structures and the relationships?

First let´s have a look at the devs. For me as a consultant working with people from IT I always get the impression that developers are creating a cult in being a “nerd”. They use being “nerds” as an excuse for not being compatible with the “others”! To be honest, this is a very cheap way of remaining within their own comfort zones! But perhaps we should take some time to ask for the “why?”! Developers are human beings, too. As is the case for all human beings, there is always a reason, why someone acts and behaves the way they do! So what could the “why?” be? Often experiences in our past are the reasons for our behavior and our actions. But perhaps it is a little bit different with the devs. Most of the devs start sitting in front of PC´s and producing code mostly at the age of puberty, at a time when their own personality is being shaped. This time in front of PC´s is not used to improve their own social skills and interaction with other people. So why do they sit in front of the PC at that age? This could be simply because they are really thrilled by the tech stuff or because they like to deal with PC´s much more than interacting with other kids, perhaps because of experience. Additionally, along with the possibility that they do not like to interact with others they also have a lack of time in practicing social skills and communication. But this lack will have the effect that when “contact happens” the result could be disappointing on both sides. And for the later developers a formative experience is made. All that stuff about being the only smart person in the room could be some kind of self-protective mechanism for not being responsible!

And now, what about the “others”? They call themselves “the experts in social skills” in comparison with the “nerds”. One very important part of social skills is empathy. But empathy doesn´t mean to blame other people for a bad relationship. Rather, it means to change the point of view for a better understanding! To point a finger at the developers and make jokes about them is not the way, somebody with good social skills will act! The reason for their ways of acting and behaving would also lay in experiences and preferences. A relationship always depends on both parts!

When people choose their profession they look for jobs, which fit with their interests and personalities. And with bringing different professions together, different types of personalities are brought together, so of course there could be a gap between them. And this gap often is filled up with stereotypical thinking leading to prejudices!

One important requirement to bridge this gap is, that all parts are made to feel responsible for building up that bridge. The attitude of “I am okay – you are okay” is the only useful way! It is a process of a personal change, which has to start!

When I once started my work on IT and DevOps I was awestruck that all people were talking about tools, but nearly no one was speaking about how to train people to improve communication and social skills! When someone has a backlog in such important personal spaces, how can we expect more of this person without giving support? And why do we expect that a team full of different personalities will grow together and will reach its full potential that easily without any support from an expert?

I have made the observation that developers especially are very interested in ways they can improve their social and communication skills and would really enjoy it if their companies would offer them, for example, workshops or team supervisions.

All parts of stakeholders are responsible for their success; and in particular the company which wants to run DevOps! So do not always think about technical tools; think of the human contribution!

May 5, 2015