devopsy.kinsta.cloud

Category: DevOps Institute

REP SPOTLIGHT: TaUB Solutions
DevOps Institute: Tell us about your organization.

TaUB Solutions: TaUB Solutions is a consulting-cum-training organization based in Bangalore India. Our vision is to take the customers beyond the existing state of maturity to envisioned business outcomes.

We serve a lot of customers in southeast Asian region by delivering consulting assignments on ITSM, IT governance, project and program management and business relationship management. This also includes delivering business simulations on the respective domains and make our customers gain benefit from learning by doing.

DOI: What other topics do you teach or consult?

TaUB Solutions: ITSM, IT governance, agile, DevOps, business relationship management, cybersecurity, project and program management and ISO standards (20000,27001, 22301)

DOI: What type of interest in DevOps are you seeing in your region?

TaUB Solutions: At the moment, we have successfully delivered around 11 batches of DevOps Foundation and Certified Agile Service Manager courses. We appeal to our customers because of the practitioner focus that we bring to the table and take them through case studies to understand the end-to-end value chain. Our current run rate indicates a strong pipeline of interest in southeast Asian countries who want to apply the DevOps principles and philosophy in their workplace. We also see great traction from Indian corporates to plunge in to the DevOps journey to serve their respective customers better.

DOI: How do you think DevOps contributes to the business’ value stream?

TaUB Solutions: One of the things that appeal most to me is the ability to articulate the end-to-end value chain. Business today does not care about which framework or methodology you adopt for the customers. All that matters is to deliver an end-to-end value chain and get a common understanding among different functions and leverage the best across the enterprise. I see tremendous value of leveraging agile, ITSM and lean principles with culture and tool chain to demonstrate key business value.

DOI: What topic area in DevOps excites you the most?

TaUB Solutions: There are three things:
- Culture change
- Power of automation using tool chain
- Business KPIs and Common Metrics across the organization
DOI: Why should enterprises and individuals consider formal DevOps Training?

TaUB Solutions: Today, DevOps is still at its infant stage and has not yet been codified. So people have their own perspectives, thoughts and misconceptions. So in order to be certain with the path they traverse, it is increasingly important to step in the right direction. This is where a formal DevOps training from DOI can help people to understand fundamentals and DevOps trends from practitioners.
June 22, 2016
MTTR: The Magic Metric
How do you improve with one metric quality, cost, performance, employee and, most importantly, customer satisfaction? I think MTTR is one to consider, but with a DevOps twist (agile+lean+ITSM). The thing I love about DevOps is that it allows for people to think differently. DevOps is the movement driving organizations to find new ways of collaborating, communicating, cooperating and improving the way they use technology to create and support services.

While many agree that MTT stands for “Mean Time To,” there is no common agreement on the R. I like using 5 Rs, as they cover the life cycle of idea to realization (in the hands of the customers in a way they like).

So what are the 5 Rs? Well, let’s work backward (shift-left thinking):
- Review: What happened? How can we stop this in the future? How can we shorten the cycle?
- Return: Do customers agree that all is well? How satisfied are they with not only our performance but the fact the event occurred?
- Restore: The time and effort to get servers, network, applications, data, passwords back as they should be.
- Repair: The time and effort to resolve the issue.
- Respond: The time to notice, decide if we can fix or get others involved, and their reactions to begin getting things sorted.
MTTR is a cycle of events. Breaking them down and understanding the value of each step enables you to reduce time, effort, waste and cost. How often do things break and why? Are they self-inflicted because we test poorly? How can you apply automation or self-healing? How good is your monitoring and alerting and response mechanisms? How great is your documentation? Do you rely on a certain person to fix things or can anyone? Knowing the answers to these questions can make issues become less frequent—or, at least, reduce the effort to address them when they do occur, as things will break.

Knowing these answers also helps clarify priority of issues. Working back from the customer drives the flow of work to highlight faults. Why treat all issues as P1 all month? For example, payroll is only a P1 when you are getting paid, but the rest of the month it can be a P2. Working with customers will help ensure you are fixing the important things, not something someone wrote in a service level agreement that is rarely updated.

MTTR is also a fabulous learning measure. DevOps is all about collaboration and that begins when people talk to each other, repair things or introduce a better test or monitor or alert to capture issues and customers are minimally impacted. Let your service desk own MTTR and see how issues get resolved better, faster and more safely.

MTTR helps drive movement to virtual or cloud. MTTR can also help you improve your A/B use of infrastructure or services. Have an issue? We’ll flip a switch.

But the overall goal of any metric is to drive actions, decisions and improvement. MTTR is such a measure. Be brave, throw away your SLAs, get people involved for issues and use MTTR to make things better across the life cycle. Then celebrate the success of your journey!

Let us know. Do you use MTTR? Can you measure each step and perform a retrospective?

About the Author / Daniel Breston

Daniel Breston is the Chief of DevOps Transformation for Ranger4. Daniel has 30+years leading IT Service, Operations, Applications, Data Center and service partners in management of technology enabling business processes and functions. He has also spent 15 years of consulting and coaching leadership teams across the EU and UK in developing their people, processes and use of technology to deliver technology services better, faster, safer. Daniel has qualifications in IT Service Management (ITIL, COBIT,etc.), Lean and DevOPS.
June 17, 2016
Rep Spotlight: Global Lynx

DevOps Institute: Tell us a little about your organization:

Global Lynx: Global Lynx is a leading and fast-growing IT consulting and training company that assists companies and government agencies improve the competence and skills of their IT organization, enhance the maturity of their IT governance and improve the quality and effectiveness of their IT operations, services and processes.

Since 1996, Global Lynx experts have helped organizations in five different countries, improving—and often transforming—their IT operations through the implementation of effective frameworks for IT governance, ITSM (IT services management), PMO (project management office) and information security.

As an Accredited Training Organization (ATO), Global Lynx also offers a wide variety of IT courseware covering different areas, standards, frameworks and methodologies, and at various levels of expertise.

Global Lynx trainers are experienced consultants, certified in multiple IT disciplines. They have actual firsthand experience in their areas of IT expertise, as well as experience in delivering training programs.

DOI: What other topics do you teach or consult on?

Global Lynx: IT service management, IT corporate governance, IT audit, information security, cyber resilience, IT risk management, cloud computing, project management, SCRUM, business continuity, process design and implementation, and enterprise value creation.

DOI: What type of interest in DevOps are you seeing in your region?

Global Lynx: Companies are interested in obtaining a common understanding of DevOps concepts and best practices, and they are focusing on deploying these practices organization-wide.

DOI: How do you think that DevOps contributes to the business’s value stream?

Global Lynx: The digital disruption all industries are experiencing, has created the need for IT to be embedded in every single business unit. Solid DevOps practices will help IT organizations deliver higher value to their customers, as value is delivered through operations, but it is defined and enabled in the development stages. Value should be managed not only in operations, but rather from the early stages of the service life cycle. A mature IT organization cannot have a poor collaboration and communication culture; without this, value creation will be limited to technical value instead of real business value.

DOI: What topic area in DevOps excites you the most?

Global Lynx: How DevOps interfaces other frameworks and how all of them can work together toward creating value to the customer.

DOI: Why should enterprises and individuals consider formal DevOps training?

Global Lynx: DevOps is all about people, and it is enabled by people. If a person is not committed, that person will do little to support the DevOps initiative. People need to go through formal DevOps training to learn what DevOps is, and how their role impacts the initiative and how they contribute to value creation. Certification is a plus, as it gives people a personal benefit. People will naturally react positively to something they own, because they will believe in it.

June 3, 2016
What is a DevOps ‘Best Practice’?
In IT, we love our frameworks. Whether agile, ITIL, lean, cobit, six sigma or others, our thirst for “best practice” guidance seems to be unquenchable.

The concept of a “best practice” is an enigma. Who decides if a practice is actually the best? And best for whom? While an “adopt and adapt” mentality is advocated in most frameworks, there is still a tendency to benchmark efforts against and conform to published best practices. Whether promoting “best in breed,” “world-class,” or “best practices,” many organizations swing these terms around as some form of competitive advantage.

Is it really? Shouldn’t business outcomes be the real competitive advantage and measure whether IT’s practices are really the “best” to meet customer requirements?

The DevOps Institute was founded in 2015 as a global learning community for emerging DevOps practices. Since our launch, we have intentionally avoided any reference to DevOps “best practices.”

We believe that DevOps practices are constantly emerging and, in many cases, being proven in the wild.

Through research, interviews, conferences and the experience of our Regents and partners, DOI’s goal is to identify, capture and share emerging DevOps practices through knowledge, education and certification models that best serve the learning community and enterprise IT. We feel it is premature to certify an individual as an “Expert” or “Master” when the expertise and mastery needed for successful DevOps is not clear and may not be appropriate in a single person.

DevOps is fairly young. It does not have a single body of knowledge. There is disagreement on whether it is a philosophy, movement or framework. Despite that, DevOps is crossing the chasm from innovators to the early majority faster than any other IT framework. Why? Perhaps it is because DevOps speaks to many of the cultural and technical challenges that IT has been amassing for years.

So instead of focusing on best practices, let’s agree on DevOps’ core principles:
- Go faster
- Shorten feedback loops
- Experiment and learn
- Cultural transformation
- Deliver business and customer value constantly and consistently
No doubt, some practices have clearly risen as being critical to the realization of DevOps’ core principles:
- Agile software development
- Continuous integration
- Continuous delivery pipelines
- Automated and continuous testing
- Proactive monitoring
- Improved communication and collaboration
Still, over the past year, DOI has seen additional practices gain interest
- DevSecOps/rugged DevOps
- ChatOps
- Agile service management
- Lean
- Immersion practices (Garage, Lofts, Dojos)
- DevOps teams
What will emerge next year? Who knows—but that’s the exciting part of DevOps. As time passes, there is less contradiction and more supplementation. Each emerging practice seems to complement and fine tune what came before.

Even without a standard definition, DevOps is already encouraging organizations to examine their proprietary practices, identify gaps, assess their automation and, most importantly, engage in collaborative discussions. Transformations have taken seed without defined best practices. That’s awesome! Let’s not quell the momentum by attaching a static set of best practices.

Will DevOps’ best practices eventually be agreed? Maybe. DevOps touches almost every aspect of IT management—people, practices and automation. That’s a tall order for a set best practices. Certainly some will try to publish their version of a “definitive” DevOps body of knowledge. Even “The DevOps Handbook,” an important book publishing later this year, was built as a collaborative effort between many of the early founders of the DevOps movement. Their perspective and insight will be awesome but not finite.

I understand the frustration by the lack of a single body of knowledge and prescribed best practices. In past frameworks, the body of knowledge was both a enabling tool and constraining limitation. Bodies of knowledge are difficult to keep current. For DevOps, let’s embrace the concepts of spirit of sharing, collaboration and continuous innovation by promoting an inclusive and collective body of knowledge of emerging practices.

If we settle on a set of DevOps best practices, are we actually inhibiting the very values that we are trying to instill? I hope not.
May 27, 2016
Simulation: The ‘Aha’ Moment for DevOps Adoption

Every IT transformation requires that people, process and technology align and work together to achieve success. As organizations begin to appreciate the benefits of a DevOps approach and look to change to a DevOps model of software development and release, there will be significant pressure on people, process and technology to support that change properly.

The technology and process changes required to enable DevOps to work efficiently shouldn’t be underestimated. Considerable time and investment is required in embracing the automation technologies that support a proper DevOps environment, and in developing the processes that make best use of that technology.

But DevOps cannot work unless your people are ready to change. Development teams and IT operations—who traditionally have worked in silos—must work together, integrate seamlessly and understand not only their roles and responsibilities within the new environment but also the roles and responsibilities of those around them.

And therefore, like every change, the real key to success is your people.

Creating Successful Change

The benefits of taking a DevOps approach are numerous: By moving toward more frequent delivery with reduced elements of change, you lower risk and increase system stability. Although automation is costly to implement, it allows teams to work far more efficiently, increases reuse, reduces errors and brings development teams closer to the customer. New functionality released continually and rapidly can be validated in the market, feedback can be received, lessons can be learned and improvements implemented quickly.

But in making such a radical cultural shift, how do you ensure you change the mindset of people who have been used to working in a certain way? How do you provide your people with the helicopter view of what that future state will be, instill in them your fervor for change and provide them with the understanding and motivation necessary to embrace new ways of working? How do you ensure everyone is rowing in the same direction? Because without that, your change—already difficult and challenging—will become impossible.

The Key to Change

The key to any successful change is communicating your vision to your people. But providing your staff with a clear vision of what that future state could be is enormously difficult. You can outline the benefits of change, explain to them what good will look like, tell them what is in it for them, and all of these are hugely important.

But there is no substitute for allowing people to actually feel what your future state will be like.

Nothing compares to parachuting them into a situation where they can work through the changes required in a risk-free environment, experience the pitfalls and live the successes. As you move them to a fully functioning and productive DevOps environment, you will accelerate buy-in from your team rapidly, and give them a much more profound understanding of your vision and future state.

The Power of Simulation

Simulation training is one of the most effective tools to explain complex concepts and operating models quickly and convincingly. A presentation on DevOps—or almost any other topic—is not a productive method of showing someone the difference it can make to their work or their business. It’s the difference between reading a script and performing a play. More and more, companies are using simulation training as a shortcut to inform, educate and convince their teams of the value of large-scale organizational change—and DevOps is a prime example.

One of the key benefits of the simulation model is that people learn together. Your team learns at the same pace, working toward the same goals—and, as a result, they collectively show each other the value of change. With a traditional change program you need each employee to go on his or her own journey to recognize and adopt your vision. With a group simulation you take everyone present down the road toward a collective “aha” moment. Once that moment has happened you have an instant group of advocates who can go out to the business together and begin to effect change on a much more fundamental level.

Simulation Brings Agility to Adoption

Providing a simulated environment in which to train is not new; it has been used extensively and successfully by the military for decades. Commercial pilots train on simulators to provide them with as close to a real-world experience as possible of some of the life and death decisions they may need to make in an emergency. They understand the power of experiential learning.

Simulating a DevOps model brings that power of experiential learning to your business, allowing you to immerse your people in a concentrated and deeply focused environment where they face the same challenges as they will in the real world.

In one short morning they get to experience building a culture of DevOps themselves, making mistakes, understanding them and learning from them. It demonstrates the business value and positive impact of a DevOps approach in only a few hours, and can accelerate the adoption of DevOps across the enterprise, successfully turning DevOps opponents into advocates.

In a world where the quality of your software can make or break your organization, it is critical to create an environment where developers and operations are not only aligned and more efficient, but also empowered and able to concentrate on developing and releasing products that add the most value to the business.

Rome wasn’t built in a day, and you can’t effect convincing organizational change in a single morning. However, by immersing your team in a simulation, you can take a giant step forward and create a team of advocates who will go out and sell your vision for you.

About the Author/Andrew Macintosh

Andrew Macintosh is a Creative Solutions Director for G2G3. He works with clients across the globe, helping to understand requirements and craft technology based solutions to engage staff and customers, internally and externally. Prior to joining G2G3 Andrew ran a production company and worked within the TV industry for 12 years.

May 23, 2016
DevOps is ITSM Best Practice!
What boggles the mind is that opponents of DevOps use risk as an excuse why DevOps would not work in their environments and why using the “traditional ITSM” approach is better and safer.

When I start asking them about their transition practices, specifically the alignment between transition, change, test and release models, I soon find that these models are either very skimpy or, most of the time, non-existent.

So here are the facts: You don’t want to do DevOps because you don’t want to do what ITSM best practice dictates!

ITSM best practice recommends building and aligning change, test, release, deployment and transition models that clearly define transition/change boundaries, practices, artifacts, acceptance criteria, roles, responsibilities and authorities, making transition practices repeatable, less risky and more reliable.

Is this not exactly what you need to do in DevOps automation? If you have not built the models and made sure they are tried and tested, you can’t automate them—and if you have built these models and made sure they are tried and tested (repeatable), then why not automate them? It’s a no-brainer.

The reality is that by using DevOps practices, organizations have far better control and manage risk far better than what opponents and detractors of DevOps have in their non-DevOps environments.

This may not be best practice, but we have for years recommended that during a post-incident review the following questions should be added to the agenda:
- Will we do this again? If so,
- Will we do it in the same way?
- Can we define an implementation approach based on the change just completed and the lessons learned, and can we reuse this approach safely in future (build change, release and test models)?
- If we can,
  - Build the models
  - Define this type of change as a standard change
Some say that this is not best practice, as “standard changes” are low risk. This, in fact, is not true!

ITIL® defines a standard change as follows (ST 4.2.4.7): “A standard change is a change to a service or other CI for which the approach is pre-authorized by change management, and this approach follows an accepted and established procedure … Every standard change should have a change model that defines the steps to follow … Authorization for each occurrence will be granted by a delegated authority … The crucial elements of a standard change are defined triggers, tasks are well-known, documented and proven, authority is given in advance … The risk is usually low and always well-understood.”

We have for years argued that standard changes are ideal candidates for automation. By extending the post implementation reviews, you identified safe candidates for DevOps automation!

About the Author/ Johann Botha

Johann Botha is the CEO of getITright, a DevOps Institute Registered Education Provider that will run its first African DevOps course May 23 in Johannesburg. Visit www.get-it-right.com for more info.
May 19, 2016
Introducing PEOPLECERT, DOI’s Examination Partner

The DevOps Institute (DOI) is proud to introduce you to PEOPLECERT, our strategic examination and accreditation partner. Since DOI’s inception in 2015, PEOPLECERT has been supporting our Registered Education Partners and administering DOI’s certification exams worldwide. To date, these certifications include DevOps Foundation®, Certified Agile Service Manager (CASM)® and Certified Agile Process Owner (CAPO)®. Going forward, PEOPLECERT will help DOI create additional DevOps qualifications as emerging practices highlight the need for the assessment of specific knowledge, skills and expertise.

For the past 15 years, PEOPLECERT has been the global leader in the assessment and certification of professional skills by developing and delivering leading qualifications around the world.  In fact, you may already be familiar with PEOPLECERT – it currently offers certification schemes in several IT frameworks including ITIL®, COBIT 5®, PRINCE2®, PRINCE2 Agile® and Lean Six Sigma. PEOPLECERT focuses on both the individual candidate and the business organization. It helps IT professionals reach their full potential by achieving certification that demonstrates proficiency. PEOPLECERT also helps organizations achieve their goals by certifying that staff have the skills and knowledge to contribute to the business value stream.

The DevOps Institute chose PEOPLECERT as our strategic partner because of its unwavering commitment to continual improvement and innovation. The organization has demonstrated these values by meeting the rigorous requirements several ISO standards. Working together, DOI and PEOPLECERT will ensure that all DOI certifications meet the highest levels of quality, integrity and relevance. In addition, PEOPLECERT’s state-of-the-art assessment system provides candidate support from exam registration to exam delivery and the issuance of the certificate. Its award-winning online proctoring services provide flexible solutions for REPs and candidates while addressing the growing trend of virtual training. It has worked hard to ensure that the candidate experience is positive and professional.

DOI is so confident in PEOPLECERT’s capabilities that we have expanded our partnership to include the accreditation of training organizations and instructors. Not only does PEOPLECERT’s global presence extend DOI’s learning community, its accreditation processes are thorough, expedient and conform to internationally accepted standards. This ability will allow us to be more responsive to the needs of the learning community.

Coupled with DOI’s go-to-market training materials, our Registered Education Partners are able to stand up DevOps certification courses quickly and often to enable more individuals and organizations to gain access to the latest training,certification and knowledge about emerging DevOps practices.

DevOps Foundation®, Certified Agile Service Manager (CASM)®, Certified Agile Process Owner (CAPO)® & Agile Service Management® are registered marks of the DevOps Institute.
ITIL®/PRINCE2®/ PRINCE2 Agile® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
COBIT® 5 is a registered trademark of ISACA in United States and other countries.

May 12, 2016
DevOps by Osmosis — Is That Even Possible?

“We don’t do DevOps. We can’t, as our development plans are agreed so far in advance and our priority from a production point of view is to keep our systems available 24/7.”

I heard this comment from a pal of mine as we had a quiet beer over the weekend, but I’m sure this comment, or a variation on it, has been uttered many times in many places. Here’s the irony: I had met my pal, who works as a developer for a major financial services company, after he had had the week from hell. His group tried—and succeeded—to fix a major system issue that had come out of the blue. He had certainly earned the beer that week.

So, I asked him: “How did you get the problem sorted in the end?”

“Well, we had to form a Tiger Team,” he replied. “Pulled together some of the DBA team, the key developers and the Ops guys, worked throughout the night and managed to keep the systems up and running the next day, while we used that time to address the root cause.”

“How did you get around the Governance guys?” I asked.

“Well, we brought one of them into the team for a few hours, and she was able to get us past some of the key bottlenecks,” he said.

“And how about QA?” I asked.

“Oh, they knew this was a major issue and so we cut out a lot of the QA and just went ahead,” he replied. “It was a bit risky, but we had all the right guys in the room to fix anything that cropped up.”

“So, you manged to get a major change through in a couple days, kept your systems up and running, kept your customers happy, and earned that beer,” I said.

“Yep, that’s about it, alright,” he said.

“So, that’s pretty much what DevOps is all about—minus the emergency element,” I pointed out. “Seems to me like you guys are already on the DevOps road.”

It was about then that the penny dropped with my pal. He suddenly realized that yes, they could do changes quickly, yes, they could do them in an orderly manner and yes, they could keep their systems up and running while all that happened. But, as quickly as the penny dropped and the realization dawned on him, the light went out again.

“There’s still no way we can do DevOps in our place,” he said. “There’s too many hurdles to overcome, too many guys used to doing things the existing way, which to be fair, has worked well for us. To be honest, there’s too many guys who would feel under threat if we suddenly changed how we do things.”

And that, in a nutshell, sums up the major challenge facing people promoting a DevOps approach. I have spent many years in the IT industry; I go so far back that I wrote my first code using punch cards (look them up) so I’ve seen change come and go, and change has been the one constant. I think many people in the IT industry have become too focused, whether it’s on the latest tools in their area of expertise, or on the newest piece of kit that has been bought, or indeed on the latest problem the business has put in front of them. The industry has become mature—if we compare the IT world to a field such as medicine, you pay passing attention—if you even notice at all—to things outside your specialty field.

Now that’s right and proper. I don’t want an orthopedic surgeon trying to fix the problem with my eye, and I don’t want a DBA to write me some code. But when something comes along that affects the whole industry, I want them to pay attention and not ignore it.

Daysha ran a lunchtime seminar last week, and we titled it “BizDevOps – DevOps isn’t compulsory but neither is survival.” We wanted to use this seminar to engage business people who, let’s face it, are the people we support and who need to understand how IT can make things better. Somewhat disappointingly, while we attracted a great crowd, they were all IT people. No one from the business attended. Now maybe we advertised this event in the wrong places, or maybe we held it in the wrong place, but here’s the thing: We attracted IT people from major companies, and none of those IT guys said to their business people, “You need to hear about this, come along for lunch.” I hope that after our seminar they went back to their business people and said just that, and maybe the next lunch will have the business people in the majority.

When PRINCE came out into the project management world, it was not bought into by a majority of project managers. The same happened with ITIL. And the same will happen with DevOps. It is fair to say that PRINCE and ITIL are pretty much standard on a worldwide basis. I am old enough to remember the time I first heard of them, and the time I did my first course and passed my first tests, but nowadays, they’re part of the furniture—taken for granted, and rightly so.

I think people are a little bit afraid of DevOps, and I can see why this is the case. Think about it for a second: Someone is now saying that the way we have done things for years has to change. That we can do things better, faster, with higher quality, but we just can’t do the massive 12-month long project in the same way. We might need some new tools, primarily on the Ops side. We might need some new skills—again, primarily on the Ops side. But, by the way, we’re not going to do away with the Ops guys (so don’t expect to make major budget savings there). But here’s the thing: Our end customers will notice the difference, and so will not be tempted by the new kid on the block—who, as it happens, is probably using a DevOps approach to develop his application, which is threatening our business.

Change is scary, it’s not easy, and making a major change while you’re still having to churn out the new business requirements, and keep the current systems running … now that’s really scary. But, like my pal whom I shared the beer with last weekend, maybe you’re not as far away from that change as you think you are, maybe it’s not as scary as you think it is, maybe it will affect people positively, maybe you just have to do it.

About the Author/John Brophy

John Brophy is currently Head of Professional Services at Daysha Consulting in Ireland, where he leads a team of 25 project managers and business analysts working on projects in blue-chip clients. He is a 35-year veteran of the IT industry, starting out as a database systems programmer, moving onto leading a team of systems programmers looking after what were then called midrange systems. He then became a senior project manager with a global IT company and followed that up by running his own IT infrastructure support company for 6 years. His background is Ops – and he is proud of that!

May 3, 2016
DevOps: Metrics Do Matter
One of my favorite quotes about metrics or KPIs is from Jim Fowler, CIO of GE Capital: “Don’t measure me on cost or traditional IT metrics, but on the metrics of the business.”

It’s a perfect tee-up for me to talk about metrics in the context of DevOps.

DevOps is the movement of enabling a business via technology or the ability to look at business processes and issues to mitigate them or achieve a goal.

The Importance of Metrics

DevOps has as one if its five major principles the concept of measuring (CLAMS: culture, lean, automation, measurement and sharing). DevOps helps the business understand how it uses and benefits from its second major resource after people: technology. This is where key performance indicators (KPIs) come in, though hopefully not KPIs such as this:

This specific KPI was created to show the productivity of developers, using lines of code written as the measure. Could you use or explain this? It’s a great example of metrics or KPIs that are based on bygone times of being complicated, disconnected from business goals, or driving the wrong behaviors by placing quantity ahead of quality.

Catch the Ball

DevOps enables everyone to work together toward a common goal. The DevOps lifecycle approach of creating a strategy, figuring out how to do it, introducing those steps, checking the results and, via feedback (people or tools), improving that strategy or product aids in improving the use and proving the benefit of IT.

DevOps can use a trick from lean (Hoshin Kanri), where the strategy from senior management is passed down to each level (“catchball”) such that each team can create its own way of supporting that strategy. Hoshin Kanri allows every person to set their own way of working to meet the goal. How DevOps is that?

By permission Steve Bell: LeanIT @All rights reserved worldwide

KPIs should be designed to help answer these questions:
- Did we improve or decline?
- Are we on course?
- Does the impact effect our organization?
- Do we need help?
KPIs provoke a Yes/No response and force an immediate action/decision. If not, they are simply metrics that probably support a KPI but do not key to help fulfill a strategy or request.

How Do You Create a KPI?

First, look at a business target. Can you see what’s required to help achieve the goal or remove the obstacle to achieving the goal? Then could you determine how you would know this was happening and whether you could you prove it? All answers have to be Yes/No.

I like making a tree, which also acts as a dashboard to quickly show at the various levels the indicators of performance and their status.

This helps make KPIs such as Cost of Delay, Mean Time between Repair, Defects2Incidents and others relevant to the right people at the right time. You could even be brave and flash the status using red and green: Red = we have a problem and need help to overcome or improve and green = all ok. Don’t hide behind amber—see how using just two colors helps guide easier, faster, better and safer.

KPIs should be collaboration and communication tools. Create and use them wisely to keep your organization in business and on course.

About the Author/Daniel Breston

Daniel Breston is the Chief of DevOps Transformation for Ranger4. Daniel has 30+years leading IT Service, Operations, Applications, Data Center and service partners in management of technology enabling business processes and functions. He has also spent 15 years of consulting and coaching leadership teams across the EU and UK in developing their people, processes and use of technology to deliver technology services better, faster, safer. Daniel has qualifications in IT Service Management (ITIL, COBIT,etc.), Lean and DevOPS.
April 28, 2016
The DevOps Institute, What a Difference a Year Makes

It was just about a year ago that we announced the formation of the DevOps Institute (DOI) here on devopsy.kinsta.cloud. Wow, what a difference a year makes! Some folks thought that formal training and testing for DevOps knowledge was sacrilegious, others thought it a joke, others that it was pre-mature. But here we are a year later and the idea of DevOps training seems to have taken root. So much so that even some of the old warlords of the traditional IT training space are trying to muscle their way into DevOps training as well.

We are launching a DOI neighborhood here on devopsy.kinsta.cloud to feature content related to DevOps training, the DevOps Institute, their partners, reps and students. We welcome your input. If you would like to contribute you can write me at editor@devops.com.

I wanted to take a moment though and return to this past year and the state of DevOps training. I think much of the initial resistance we encountered in some quarters was to the idea of certifications of DevOps training. In fact, I would say much of it was resistance to the idea of certification in IT period. Over time the market and certainly we here at the DevOps Institute realized that while certification is something that is important for some employers or career paths, it shouldn’t take away from the real aim of the DOI’s mission.

The DOI’s mission is to gather information, evangelize and educate the market about the emerging practices in DevOps. Notice I did not say best practices. This is because we believe that we have not had really recognized or perfected best practices. We are seeing emerging practices and watching closely to see which ones continue to emerge and offer the best state-of-the-art in DevOps training and education.

In the meantime, we are seeing DevOps training offerings coming out of the woodwork. Many of the tools vendors are developing and putting out training and certification specific to their tools. I think this is essential for employers to be confident that an employee has the expertise with a given tool set. Practitioners are going to want this training and certification to prove their proficiency on a given tool. I would like to see us incorporate some of these tool classes as part of the DOI offerings in the coming months.

Some of the traditional IT training folks are taking matters into their own hands and developing one-off DevOps classes. As with everything else, some are better than others. In digging in you will find some are a quick money grab and some are actually pretty good.

As I mentioned earlier, some of the older stakeholders behind ITSM, ITIL and Scrum training are trying to jump on the DevOps bandwagon. They promise openness, but their business models are all but open for the most part. There is more to DevOps training then putting logos on a website. In the meantime, one thing we have learned for sure is lets not repeat the mistakes of the past with some other types of IT training.

The IT industry and IT training are well evolved global industries. It is a for profit industry obviously. My advice is, buyer beware, your mileage may vary when choosing a DevOps training provider. DevOps is not ITIL, not ITSM and while Agile is tangential, it is not exactly the same either. In fact while Scrum Agile training is pretty well developed, it is not the same as DevOps training per se. Their are Agile methods and lessons that DevOps classes can take, especially the DevOps for Ops type of classes. But lumping DevOps and Agile together is not the right path either.

At the DevOps Institute we have a world-wide network of registered education partners who are offering our tried and vetted DevOps Foundation class, as well as our other two classes. If testing and certification are important to you, our global partner PeopleCert will administer and deliver it for you.

We are also hard at work to deliver the next generation of DevOps training classes. I don’t want to talk out of school, but we have spent the last year listening to the hundreds of people who have taken our classes, our partners, speaking with the leading lights in the DevOps world, I think what we have in store will once again set the bar in DevOps training and education.

In the meantime, check here at the DOI neighborhood often. There will be a steady stream of good content related to DevOps education from many different sources. You may just learn something 😉

Indeed the first year of the DOI has been quite a ride, but buckle in because things are really going to pick up now.

April 19, 2016