devopsy.kinsta.cloud

Tag: learning

  • Fostering ‘The Third Way’ via Learning

    Fostering ‘The Third Way’ via Learning

    Learning is an integral part of the DevOps process. Dojos can be critical in transforming the process.

    With so many new and evolving technologies, practices and approaches to product delivery, how can organizations possibly keep up? From infrastructure as code to cloud-native and microservices through product thinking (and don’t forget testing!) as well as chaos engineering, how can teams possibly adopt and benefit?

    Courses and training are fine but rarely result in the impact that today’s enterprise organizations had hoped for. Sometimes what is practiced and learned in courses doesn’t quite work in our organizations. Other times, people come back from courses with great ideas that are not shared and spread across their various teams. And in most cases, the learning is a special event, and when the people come back to work, there is no time or space to try and apply those learnings.

    Traditional approaches to training are weak and never transformational.

    So what is an enterprise organization to do?  The answer is simple: Embrace learning. Make it part of what we do every day. Gene Kim, one of the authors of “The DevOps Handbook,” mentions embracing “The Third Way”—the path of continual learning and improvement. In this book, Kim explains how The Third Way is about creating a culture that fosters two things: continual experimentation, which involves taking risks, and learning from failure. Being able to recognize that and practice are prerequisites to mastering DevOps practices.

    It all sounds great, but are any companies actually doing this? And if so, how?

    This is where an approach like the Dojo, an immersive environment where whole teams come to learn a variety of skills all while delivering their real work, can play a critical role. In this dojo environment, teams “learn by doing” and are guided by dojo coaches. These coaches aren’t the typical drive-by, tell-you-something-and-leave-materials type; these coaches sit with each individual, teach when needed and help teams learn by doing. These coaches need to be from within the organization.

    Teams leave this type of learning environment with not just new skills and better code, but also with an approach to move their learning forward. They can also share this knowledge with others as well as a way to continue learning as a team. This dojo-type of environment doesn’t have a standard curriculum—it is pragmatic by nature and meets teams where they are. For example, one team may learn TDD and product thinking along with a pipeline to production while another may learn how to migrate batch work to the cloud. Another team might learn DDD and microservices. But the teams all learn in the context of their work.

    Learning isn’t only for the team, though. Organizations learn by having their teams in the dojo. All of the friction that team members are experiencing becomes very visible. The dojo works with leadership to help resolve organizational friction that is frustrating teams and impeding their delivery flow.

    Today’s digital markets are moving so quickly that traditional course-based training does not scale both in terms of time and cost. Certification programs do not always provide enough information and can be very costly. Additionally, these types of programs are not always attuned to your company’s specific product development needs. To increase the effectiveness of your digital development teams, today’s enterprise organizations need to deliver high-quality, hands-on learning that takes place within the context of your own company. Further, this environment must be able to focus on your products, geared to your processes and driven by your market imperatives. The payoff includes shorter cycle times, reduction of production incidents, better overall products and a happier, more engaged team. It’s great to see more and more companies continuing to invest in continual learning through dojos as a way to achieve these outcomes.

    — Joel Tosi

  • Education in the Age of Automation

    Education in the Age of Automation

    Automation is changing the nature of education and the ways people learn. More schools are using online learning to supplement in-class activities. In fact, some schools are completely online. Distributed computing on the internet and the automation that drives it makes this possible.

    Everything changes when the formal education process becomes embedded in the internet. Courseware delivery becomes asynchronous; people learn what they want, when they want to. Test administration becomes more about the efficient acquisition of data and evaluation thereof. Human-to-human interaction as a basis for a meaningful educational experience becomes optional. Today, it’s entirely possible to learn all you need to know to make a good living in the modern world without ever needing to sit in a classroom or interact with a human directly. Let’s face it: You can do a lot of learning from YouTube.

    As a result, more people are beginning to question the conventional wisdom of spending four years and thousands of dollars to get a bachelor’s degree—particularly now that companies including IBM, Google and Apple no longer require one to get hired.

    Coincidentally, as companies eliminate the college degree requirement for new hires, we’re seeing significant growth in technical bootcamps. One study reports that this year, 20,000 students will complete a course of study at a coding boot camp and be “job ready.” Considering that the number of students who graduated with a computer science degree from a typical college in 2017 numbered about 93,000, there’s a good case to be made that boot camps are siphoning off a number of students that otherwise would be headed to academia.

    Going to boot camp instead of college is an upward trend: The study projects that the number of boot camps are expected to grow 20 percent this year. The career path for a technical professional does not necessarily involve going college. Going to a boot camp for a year—if not less—will suffice.

    Is this a problem? I’m not sure. On the plus side, I am reminded of the scene in the film, “Good Will Hunting,” when Matt Damon’s character Will Hunting, a genius with a photographic memory who walked the halls of MIT working as a janitor, makes the profound remark:

    “… you dropped a hundred and fifty grand on a f****** education you coulda got for a dollar fifty in late charges at the public library.”

    There’s a good argument to be made that when it comes to getting a good paying job, the $15,000 median price tag for attending a coding boot camp has a better much better ROI than spending  ~$200,000, the cost of a four-year degree from MIT.

    But then, I am reminded of Aldous Huxley.

    In his book, “Brave New World,” people are grown in test tubes according to a specific formulas, the result of which is a biological caste system. Those in the Epsilon caste are grown to be 3 feet tall and abhor the outdoors. Their job is to work their way underneath the machines on the factory floor to do simple maintenance. Deltas, the next caste up in the hierarchy, do the menial chores—janitors, for example. Gammas are the bookkeepers and data entry clerks. Then you get to the higher levels, Alphas and Beta. Betas are technicians who do very sophisticated jobs, such as mixing dangerous chemical together. One mishap can result in an explosion, killing all. Finally, at the top of hierarchy are the Alphas. Alphas possess advanced analytical skills and a broad knowledge base. They are able to plan and strategize. They have a high degree of creativity. Their role is to run the society.

    Thus, I have a concern about the increasing role of technology and  automation education, and the emergence of tech-focused boot camps as the prime post-secondary educational experience for many.

    As more of those entering the workforce forgo a formal college education, we run the risk of creating a society in which most of the technical workforce is Betas. They’re able to do highly complex tasks, yet have no idea why they’re doing them.

    Let me be specific. Let’s talk about Kubernetes: It takes a lot of knowledge and experience to be good at getting Kubernetes to work. It’s a complex, evolving technology that you need to keep your eye on. Companies are spending a good deal of money making sure their IT staff are competent with Kubernetes—as well they should be. One little misstep can result in the digital equivalent of a chemical explosion. Yet, I wonder how many of those “working Kubernetes” are thinking about the bigger picture—for example, the purpose and value of the enterprise using Kubernetes. Are these engineers questioning if the technology they’re working is doing good or harm?

    Or, let’s turn the dials down a bit and ask a question that’s less loaded philosophically. How many of those working Kubernetes today wonder if an alternative orchestration technology such as Docker Swarm might be a better choice to meet the need at hand. Or are they so concerned with getting Kubernetes to run that they don’t have the bandwidth to think about anything else? Do they just defer such critical thinking to “the system architects”?

    Critical thinking, although an acquired skill, is not one that’s new on the cognitive landscape. It’s been taught for thousands of years, since the time Socrates sat under an olive tree asking simple questions that forced his students to transform their assumptions and allusions into thoughts based on reason and reflection.

    Developing the ability to think critically traditionally has been one the aims of a college education. The romantic ideal is that college is the place where students are exposed to a variety of ideas from a variety of viewpoints. The hope is that such exposure, along with instruction aimed at developing one’s ability to engage in higher-order thinking, will create graduates who will contribute to making a better-functioning, more prosperous and more humane society.

    But, that’s the traditional perception of college. The reality is changing. Maybe college is just the place you go to get the skills required to get a good job. If that’s the case, given that a college education is becoming less affordable to more people, maybe the boot camp approach is best. Yet, there is a risk.

    A good while back when I was considering enrolling in a doctoral program, I attended a required orientation at Harvard University. I sat in an auditorium composed of about 50 aspiring doctoral students. One of the department heads on stage said the following, “The objective of our doctoral programs is simple. We want to train you to run the world.”

    Yep, that’s right. And, I can say with a good deal of confidence that this objective is the same today—to create thinkers who have the skills and knowledge necessary to run the world. The Alphas, if you will.

    So, we’re at a crossroads. Automation is a liberating force in education in that it makes infinite knowledge available to anyone who wants it at a fraction of a cost of a traditional college education. All that’s required is the time and desire to take advantage of the opportunity at hand. However, if the result of such education is a workforce in which the concern of most is to ensure that the technology works and does not blow up, then the risk we run is that bigger decisions will be made by those who had the time and money for an increasingly elite education. In other words, as more people spend time focused on turning the dials and setting the levels to make the technology go, a very small minority actually will be determining the purpose and direction of the machine the technology supports.

    Still, the fact is, most of us need to make a buck to survive. This means being good at getting the tech to work. Yet, we will do well to understand that there is a Big Picture and if don’t pay attention to it, someone else who has been educated to run the world will.

    — Bob Reselman

  • Testing and Certification in the Age of Automation

    Testing and Certification in the Age of Automation

    If we do not change the way we teach, 30 years from now we will be in trouble. Because the way we teach, the thing we teach our kids are the things from the past 200 years. It is knowledge based. And, we cannot teach out kids to compete with machines, they [machines] are smarter.

    We have to teach something unique so that a machine can never catch up with us.

    —Jack Ma, CEO Alibaba

    tl;dr synopsis

    Given the complexity of modern DevOps, technical certification is becoming more granular. Also, its use is exploding as a requirement for employment. Most technical certification is awarded by passing a test composed of multiple choice questions. Passing a test with multiple choice questions requires the test-taker to absorb a significant volume of knowledge for a short period of time. This acquired knowledge does not need to be retained. Hence, the certification can only attest to the bearer’s knowledge of a technology at the time the test was taken. And, essentially the test measures only the bearer’s ability to take the certification examine. Finally, testing by multiple choice does not ensure the certification bearer’s qualification in terms of required experience or higher-level thinking capabilities.

    Technical certification is valuable in the current commercial landscape. However, at some point, as machine intelligence is able to perform more of the activities presently done by humans, the format and methods by which certification testing is administered will need to change. Future certification testing methods will need to put greater emphasis on analysis and creative problem-solving rather than the current focus on knowledge acquisition and rote application. Also, what and how we teach humans will need to be unique, beyond the capabilities of artificial intelligence.

    Over the last 10 years, DevOps has become a much more complicated landscape. Regardless of the service provider of choice—Amazon Web Service, Microsoft Azure, Google Cloud, OpenStack, IBM, Joe’s Homegrown Cloud Service—you gotta know a lot to play.

    At a high level, service providers offer products that are surprisingly similar. For example, they all provide some sort of machine virtualization, storage services, database services, queuing technology, authorization service, provisioning technology and API management. But the way you manipulate the conceptual knobs and switches to get any of these products to work can vary dramatically between providers. There’s a lot of minutiae involved. Absorbing the amount of detail required to be productive in a provider’s product line takes time. And, ensuring that someone can actually work competently with a service provider’s products is a crapshoot. For example, a deployment engineer may understand the concepts behind dynamic provisioning, but getting a Kubernetes orchestration to work in Google Cloud is where the rubber meets the road. Doing is always much more difficult. As I said, there’s a lot of detail involved.

    So, how do companies ensure that the people they hire to fiddle with their multimillion dollar, mission-critical technology stack will deliver the goods without blowing things up? Most have an extensive technical interview process accompanied by a stringent reference check. Some just hope. Others require certification.

    The Rise of Micro Certification

    The notion of certifying that a person has the skills and experience required to be competent in a profession has been around since 1885, if not before. That was the year Massachusetts implemented the first written bar exam. Before that time, all a person needed to do lawyering was to get a note from a court saying the person could be a lawyer. That’s how it went for Abe Lincoln. Eventually the profession matured. Professional qualification was determined through a test-based approach. Early bar exams used essay questions. In 1972, with the addition of the Multistate Bar Exam, multiple choice questions were included.

    Going to multiple choice questions may seem like a trivial change, but it’s not. Whereas a knowledgeable professional is required to grade an essay question, multiple choice answers can be evaluated by anybody with the answer key. Hence, the popularity of multiple choice questions on the SAT. It’s the most efficient way to grade millions of high school test-takers each year. Evaluation is fast, cheap and a machine can do it.

    As I mentioned at the beginning of this piece, IT in general and DevOps in particular has become a place of increasingly granular complexity. There are a lot of technologies on the landscape. Each of those technologies has a significant learning curve to be overcome to achieve mastery. The conventional wisdom is that the best way to determine mastery is to test a person’s knowledge of the given technology and then measure the results of the test—high score, good; low score, bad. As with early testing practices, the fastest, cheapest way to make an evaluation is to administer a test made up of questions with multiple choice answers. This is sort of like the SATs, except most technical certification is geared to a particular vendor’s product line, not a general body of knowledge. (You can view a sample of test for AWS Certification as a DevOps Engineer Professional here).

    This type of professional testing paradigm is exploding. It’s infiltrating every corner of the technology landscape. And, more employers are requiring certification as conditions of employment, both for prospective employees and those already on staff. This would be OK, except for one thing: After you scrape away all the preconceptions and assumptions about the value of test-based certification, when it comes down to the bare-bones validity of test measurement, the only thing a test really measures is the ability to take the test. For example, a deployment engineer might be sitting for a certification test after having been up all night working to get the company back online after a system failure. The taker, who is exhausted, ends up failing miserably. Yet, some slacker just out of high school who has never seen in inside of a data center can take the test using stolen answers and pass with flying colors. Tell me, please: Who is really the most qualified professional?

    Testing by Regurgitation

    Certification is not the problem. After all, I really do feel more comfortable knowing that the surgeon about to open up my wrist to alleviate my carpal tunnel syndrome is certified by the American Board of Surgery. Rather, the problem is the way that certification testing is conducted. In my opinion, a certification testing process that emphasizes the multiple choice question-and-answer format is flawed. Even when questions are answered correctly, the test format does not really verify the competence of the taker, only that some facts are known. It’s just testing by regurgitation.

    Such testing requires the taker to absorb a lot of knowledge and then dump it out according to the test requirement at hand. There is no guarantee of long-term retention. It’s the age-old process of cramming for the test. Once the “time’s up!” bell rings, the chances are that the test taker will forget most of what she absorbed. Those with photographic memories might remember it all, but for most of us mere mortals, it’s a one-shot deal.

    Few people in tech work using the cram-it-in method. Most of us just use this thing called the internet to get the answers we need, when we need them. It’s what Bill Gates calls “information at your fingertips.” Yet, we still test for the knowledge in your head at the moment.

    There is a better way.

    A Better Way

    Certification is good provided it ensures that the bearer knows what he or she is doing. When certification is about nothing more than checking the right checkbox on an online test, there’s a problem. Put a monkey in front of a multiple choice test for eternity and eventually the animal will score 100 percent.

    So what do we do?  We do the following:

    Support Open Book Testing

    If the purpose of the test is to ensure that a person has a certain body of knowledge at the time he or she takes the test, make the body of knowledge required available at test time. It’s called open book testing. That’s how it works in real life. For example, you need a NodeJS package to provide mock objects. Do you rely upon your existing knowledge about the packages you know? Great, but what if you don’t know? Does work come to a grinding halt? No. You go to NPM to find one that meets your need. That’s how it is in real life. A competent professional is expected to have a baseline, high-level knowledge of his or her professional domain. For the day-to-day details, a pro has the ability to find accurate answers to questions quickly.

    Instead of having a certification testing process based on cramming, maybe we should eat the dog food we make in real life and go open book. There is little downside to researching what you need, when you need it. Besides, the test question created a week ago might be best answered by a new technology created today.

    Put the Emphasis on Essay Questions

    The actual mechanics of testing vary according to the level of cognition being examined. I wrote an article about this a few years back. The best way to test higher-order thinking—analysis, synthesis, evaluation—is by using essay questions. After all, what is a Ph.D. dissertation if not a very big essay question? Essays require a level of thinking that is hard to capture using lower-order test methods such as multiple choice. Essays reveal not only what the test taker thinks, but also how the test taker thinks. There’s a reason why your high school math teacher wanted you to show your work when taking an algebra test. Sometimes how you get the answer is just as valuable as the answer itself.

    A good certification test will provide a question format that allows test takers to illustrate their thinking along with the way they arrived at an answer. Thus, the need for a bias toward essay questions. Again, how you think is just as important as what you think.

    Put a Human Back in the Examination Process

    I’ll share an intimacy with you: I’m not very good at answering multiple choice questions. When confronted with one, I spend a lot of time trying to figure out what the question is really asking. You’d be surprised at the number of test questions out there that are vague and confusing.

    This was a real problem for me back when it was time to go to college and do the SAT dance. Fortunately, my alma mater focused more on my essays than my SAT score. Also, a lot the exams during my collegiate years were administered as essays or conducted as interviews with a professor. Later, when it was my time to be the Guy Awarding the Grade, my process was to evaluate students by interviewing them about one or many of the projects they did. I based my grade on the quality of the project itself and the thinking that went into the work. I tested my students by talking to them and reviewing their work. I like to think that I got a pretty accurate idea of a person’s competence, more than a multiple choice test could ever provide.

    Providing the opportunity for human interaction in the examination process can go a long way to providing the information required for making an accurate evaluation of a person’s competence.

    Require Testimony of a Candidate’s Experience, Character and Competence

    Think about this: It’s possible to be an AWS Certified Solutions Architect Professional without ever having done a day’s worth of paid, real-world work. All you need to have done is pass the certification exam. Yes, of course passing the exam is meaningful. It’s a grueling test. At the least, the test might prove that should be able to work the conceptual dials and switches that go with a given AWS service. But, as far as having the real-world experience, competence and character to play a critical path role in a mission-critical enterprise, some other instrument of certification is required. This instrument is sometimes called a reference—or, as the Wizard said to the Tin Man in “The Wizard of Oz,” a testimonial.

    As you read above, back in Abe Lincoln’s day, a letter from a court attesting the good moral character of the bearer was all that was required to practice law. You can think of good moral character as the ability to show up on time, do reliable work, demonstrate a commitment to excellence and get along with others. Such a description might sound melodramatic, but it counts.

    While it’s true that some certifications require that bearer to have a modern version of “good moral character,”  in addition to good test scores, many do not, particularly in tech. An employer wants to hire people who know what they’re doing and have the wherewithal to work effectively in an organization. Potential candidates want to provide evidence that they have what it takes to be a good employee. Building a testimonial of the bearer’s experience, character and competence into a technical certification will add a great deal of value for all involved. Also, the testimonial needs to affirm the bearer’s ability to adapt to change. In the not too distant future, your commercial value will not be about what you know today, but rather how fast you can work with technologies that will appear tomorrow.

    How to Win the Race

    For better or worse, we’re in a race with machines to keep our jobs. They don’t really want our job. They’re incapable of desire. But, that’s not to say they can’t have our job should the machine prove to be able to do it. Sadly, the current practice of technical certification is focused on passing tests concerned with the acquisition of knowledge.

    Right now, we’re winning the race. Machines still have problems with knowledge-based tasks involving advanced image recognition and reading comprehension. We still know how to differentiate between a dog, cat and an apple tree better than a machine can.

    But, it’s not always going to be this way. Keep in mind that talking machines were very primitive 20 years ago. Their voice had an artificial, staccato rhythm that was distinctly robotic. Today, it’s hard to tell the difference between a human or machine when a robocall disturbs your evening meal. It’s only a matter of time before the machine can do mid- to high-level knowledge-based work better than any human. Jack Ma’s quote at the beginning of this article supports this assertion.

    We need to change. The commercial value we’ll bring to the workplace in the future will be about analyzing, synthesizing and evaluating. Machines will be able to to the lower-level thinking faster and more accurately than we ever can. The realm of human excellence will be about better understanding the world around us and bringing new things into that world. The way we start is by teaching something so unique that the machines can never catch up. This thing is creativity. The paradox is that creativity can always be learned, but rarely be taught. Still, we must try. We have little choice not to.

    — Bob Reselman

  • In Building Communities, Our Preferred Pronoun is ‘We’

    In Building Communities, Our Preferred Pronoun is ‘We’

    It has been about 18 months since my last post. Toward the end of 2015 I started digging deeper into cybernetics and systems analysis, which led me to construct a model and write a paper. I haven’t posted it before now because it isn’t perfect. The funny thing is, I know it will never be perfect but I still have a list of edits to make. I always will.

    I would describe the paper as a form of hermeneutical phenomenology. The TL;DR on the model: it provides a basis to qualify systems for further analysis. Writing is a mechanism for me to study the model, but as my investigation varies so does my interpretation of what the paper should say. At the moment I’d like to add some observations around four-color mapping, thresholds and compactness. It’s a more rigorous argument than what I said about the continuum hypothesis, but I may leave that bit in anyway.

    Ultimately, the paper is my interpretation of the work I’ve studied. More than read my paper, I’d encourage anyone to review the sources themselves. It goes without saying that I couldn’t have written it in the first place if I weren’t standing on the shoulders of the giants that came before me.

    Self-Inflicted Othering

    I strongly identify as a technologist and a mathematician, but I would be neither of those things if it weren’t for the broader scientific community. Where I keep seeing people get stuck is celebrating our individual differences along with what we have in common. Humans have a tendency to form tribes and wage war. While I’m always glad to see the sense of belonging communities provide for their members, it’s the tendency to direct hostility toward other groups we should resist. J. Paul Reed wrote a post about this last year. We all have circles we run in where our faces are more familiar than others and it’s easy to get “othered” when we step outside of those environments.

    I meet a lot of really smart people at tech conferences who haven’t taken any trig or calculus. If I’m at a math conference I typically get a lot of beginner tech questions from people who are a different kind of brilliant. One conclusion from my paper is the operating environment is the ultimate constraint on a system. We can be local experts on whatever experience we have that’s not the focus of the event. We should also be able to find people that can teach us more about the event’s main topic while we’re there. If you find your experience in a field is making it difficult to learn, try spending more time with newer community members. Their challenges and experiences stand a good chance of providing a fresh perspective.

    We Rise

    This past week I spoke at We RISE Women in Tech Conference, which was hosted by Women Who Code Atlanta. I’ve been among the organizers for devopsdays Atlanta for the past two years and have been making an effort to engage the local community more.

    I spent most of my time at We RISE on the tools track. G. Ann Campbell gave a great talk on code quality called, “Refactoring with Cognitive Complexity: The New Option for Measuring Understandability.” I’ve used sonarqube for years and have been studying complexity science as part of my cybernetics journey. I felt like I was the target audience for her talk. I really liked Meera Subbarao’s talk, “Know Your Enemy, and Yourself: Demystifying Threat Modeling,” too. I enjoy any talk with maps and Sun Tzu quotes, but the highlights of Meera’s talk were the personal stories she shared about trust and failsafe experiments. Experimental methods are playing an increasingly important sociotechnical role in security as our systems become more complex and adaptive. I’m currently convinced all sociotechnical systems are cybernetic as a byproduct of their complexity and all cybernetic systems are sociotechnical at a coarse enough scale.

    Other Kinds of Othering

    It’s that kind of talk that got me grouped in with the “complexerati.” The first time I heard the word I knew they were talking about me (among others) and it wasn’t intended as a compliment. Nevertheless, I couldn’t deny it is who I am. I’ve also been called an insight junkie and street academic and I can’t deny those, either. I can get hooked on a phenomena and dig until I’m completely exhausted. I also never finished my undergraduate degree, which leaves me to perform my research in the street, like a busker. I’m not sure busting my chops over the part of my degree I’m missing is constructive feedback, but we can’t expect everyone to be nice to us all the time, either.

    I know we can catch people on a bad day so I try to be forgiving when someone gets a bit brisk with me. The complexerati comment led to some helpful advice after a diplomatic conversation. If I’m going to use language that’s specific but unconventional, I should make an effort to translate as I go along. People are comfortable with expanding their vocabulary but we shouldn’t introduce too much new material at once. What I said about cybernetics and sociotechnical systems translates into plainer English as, “any system with people in it is self-steering and any self-steering system will have people in it if we zoom out far enough.” The language isn’t quite as precise but it’s still accurate. Negative feedback can be helpful but we have to keep it constructive.fours

    Diplomatic Relations

    Churchill said, “Diplomacy is the art of telling people to go to hell in such a way that they ask for directions.” Communication is vital to trust and learning. Our human tendency to zoom in and steer toward our own familiar shores keeps us divided. This is an excerpt of my last post from December of 2015. It would seem my position has not changed.

    Instead of focusing on processes we should focus on enabling people to improve themselves. We improve when we learn and we learn when we communicate. If your culture does not foster communication can if foster learning? If you’re not open and honest with yourself, how does that effect your environment?

    I could go into more detail about my intentions for next year and may do so at a later date, but my plans are of no use to you as we are different people. I would encourage you to gain awareness of your own situation by challenging the assumptions that have bounded your operation.

    We can stay true to ourselves and our own identities while interacting with other communities. We’re members of some and just allies of others. It’s important to respect those boundaries and understand when our experience is welcomed and appreciated, when it’s time to listen and learn, and when it’s just not the time or place for us and we need to move onto something else for a while.

    We RISE was about technology and culture, which I believe are at the heart of what I’ve been studying for the past few years. The talks about DevOps and security couldn’t have been more relevant to my work. I felt some of the advice I heard in the keynotes from Jen Bonnett, Safia Abdalla and Estelle Weyl that was specifically targeted toward women was probably good advice for anyone, including me. Both Melanie Crissey and Sandra Persing shared their takeaways from the conference here and here, respectfully. Their posts should help shed some light on how I fit in and what I took away from this women’s tech conference more convincingly than I’ll be able to explain.

    I felt very welcomed and included at We RISE. Erica Stanley, Alicia Carr and Beth Laing threw a terrific event. We’re lucky to have them and Women Who Code as members of our Atlanta tech community.

    A Group Effort

    I think this slide I tweeted from Ashley Sun’s talk is the best I can do at summing it up. Ashley gave an awesome talk, during which she showed us how she’s using neo4j for cloud monitoring that gave developers in her organization the ability to manage more of their own infrastructure.

    Ashley shared Kelsey’s tweet in an effort to convince us that just because this solution was a good fit for her organization, it didn’t necessarily mean it would work for anyone else. Adrian Cockcroft had made the point that not everyone can be Netflix. Adrian used to work for them, so he might be a little biased. When Kelsey Hightower quoted him, it provided some external validation to the idea. Kelsey works for Google and they aren’t trying to be Netflix, either. They’re too busy being Google.

    Greg Poirier pointed out that not everyone can be Kelsey Hightower in his talk at devopsdays Silicon Valley a while back. I felt the point Adrian had about Netflix applies to us as individuals, too. Copying Kelsey’s results won’t give us the experience of walking Kelsey’s path. Some experience with Kubernetes may help you on your own journey, but it will never make you Kelsey Hightower. The same applies for Ashley Sun, Adrian Cockcroft and anyone who’s still reading this. We all have some experience others can learn from because we’re each on our own path. As things change over time and our memories fade, not all of what we remember remains how it was today. This is how the perspective of a novice can give fresh eyes to someone with more experience.

    One Step at a Time

    This is why Taiichi Ohno was unconcerned when people came from the United States and wanted to study TPS. By the time they had implemented what they had observed, the process at Toyota would have already adapted into something different (if you’d like to read more about it you should check out this book). The game we’re in has no finish line we can cross. The only successful move we can make is to try to support each other as individuals and communities as we’re able, sharing what we have in common.

    I had a great time at We RISE Women in Tech Conference and will look forward to it returning to Atlanta again next year.

    — Chris Corriere

  • Visibility Drives Data-Driven Decision-Making

    Visibility Drives Data-Driven Decision-Making

    One of the biggest challenges of DevOps today is lack of visibility—especially shared visibility—into application delivery process and outcomes. A common data fabric allows all stakeholders to share visibility into DevOps processes, so they can more easily collaborate and communicate, use objective data to make decisions, and deliver better code faster.

    The DevOps Visibility Challenge

    A typical DevOps process relies on a loosely coupled tool chain. It includes separate tools for discrete functions including project management, source code control, provisioning and configuration, test execution and workflow automation. A tool chain approach adds much value, but becomes complex quickly. Also, it makes it difficult for stakeholders to get accurate insight into application delivery.

    This challenge is especially endemic to large and distributed enterprises. It’s even more difficult when there are thousands of developers and dozens of data centers across multiple geographies. Having duplicate tools, specialized teams, varying processes, distributed locations and multiple business units makes it even harder.

    As a result of this poor visibility into application delivery, stakeholders from business and IT:

    • Cannot manage the velocity of feature delivery. They cannot detect and fix slowdowns or bottlenecks in the process or allocate and prioritize resources. They also cannot plan for downstream activities or triage slowdowns and stoppages in the software development life cycle.
    • Cannot make objective decisions on quality. They risk releasing error-ridden software, slowing down response times, introducing security vulnerabilities, oversaturating infrastructure, damaging reputation and adding unnecessary costs.
    • Cannot properly collaborate on detection, diagnosis and remediation of production problems. They also cannot share an understanding of the impact of code changes on business key performance indicators. Customer satisfaction, customer signups, cart fulfillment rates and revenue all could be affected.

    Data Mining Enables Visibility

    To overcome these obstacles, successful DevOps teams are using objective metrics mined from machine data. That helps them gain insight into the end-to-end delivery cycle, from idea to release.

    Collecting, correlating and analyzing machine data from multiple sources gives dev and ops (and others) continuous insight. They can see the velocity, quality and business impact of application delivery. It provides individual contributors the data they need to be responsible for their own work, accountable to each other and aligned with business objectives. It enables managers to make data-driven decisions about workload prioritization, resourcing, scheduling, performance and value delivery.

    How to Get to Data-Driven DevOps

    Some of the key actions you can take to start on a journey of data-driven DevOps include:

    Measure your speed of application delivery: The machine data generated by your DevOps tool chain provides a wealth of information about all phases of the development cycle. It shows what is in development, close to release, in backlog and slowing you down. It shows which stages in the process are failing and what teams are most efficient. Consider mining and sharing velocity-related measures such as commit rates, sprint times and “idea to cash” time, to name a few.

    Measure the quality of your application code: Even if you are already using testing tools to understand release quality, there is more to quality than test coverage. Again, choosing the right KPIs is critical, as is sharing those measurements throughout your team(s). Some other key metrics may include the number and importance of defects, defect variance from release to release (or from team to team) and build/integration/deployment failures.

    Measure the business impact of application code: All too often organizations measure activity, but fail to align application delivery with business goals. As one customer recently told me, “Shipping crappy releases faster won’t help.” Business stakeholders especially are looking for business KPIs such as:

    • user signups or cancellations
    • customer satisfaction
    • cart fulfillment or abandonment
    • time on site
    • transaction failure rate
    • sales volume
    • application revenue
    • app downloads
    • offer open rates
    • customer satisfaction; and
    • customer acquisition costs

    Measure the human impact of DevOps: DevOps is mainly about people, so you must find ways to measure culture change, too. You can mine various applications for objective metrics such as number of sick days, “work from home” days and variance in team and individual productivity. However, machine data will not provide all the relevant KPIs; you will need subjective measures too, such as from “stay interviews,” feedback forms or surveys.

    Data-Driven DevOps with a Common Data Fabric

    A data-driven DevOps approach more effectively drives continuous improvement and higher levels of agility. It also helps achieve greater collaboration, improved security and compliance, and better alignment with business KPIs. These all occur while enabling rapid iteration and innovation.

    A common data fabric provides the objective measurement and shared visibility critical for a data-driven DevOps approach. With comprehensive and continuous visibility into key performance measures, provided through a shared data fabric, DevOps teams can:

    • Isolate “waste,” detect and correct slowdowns, and deliver applications faster
    • Correlate test and QA outcomes to find more problems sooner and improve code quality
    • React faster to detect and address problems that do get through to production; and
    • Use real-time insight to measure business impact and iterate faster on good change

     

  • Welcome to the New DevOps Institute Neighborhood

    Welcome to the New DevOps Institute Neighborhood

    The DevOps Institute (DOI) was founded in March 2015 as a global learning community for emerging DevOps practices. DOI’s goal is to establish the standard for DevOps training and certification at the enterprise scale based on the most current guidance from the most respected resources. We are guided by a Board of Regents comprised of thought leaders from the DevOps, Agile and ITSM spaces. We are establishing strong alliances with global leaders such as PEOPLECERT and devopsy.kinsta.cloud.

    DOI is not a training organization; all education and certification is delivered through our worldwide network of Registered Education Partners (REPs) and PEOPLECERT as our examination institute. Since our launch, hundreds of candidates have sat the DevOps Foundation and Certified Agile Service Manager courses and exams with positive feedback and results.

    Why do we need a DevOps Institute?

    DevOps does not have a single body of knowledge. It literally touches almost every aspect of IT, from culture to automation to metrics and beyond. While the lack of a single body of knowledge may be frustrating to some, the evolution of an inclusive and collective body of knowledge allows DevOps to continue to grow and adapt organically.

    On a higher plane, that’s great. However, enterprises wanting to transform their environments to be faster, more collaborative and more automated are seeking a more formal approach to training and certification to ensure their teams are fully equipped with holistic knowledge, skills and competencies. That’s where DOI comes in.

    DOI strives to capture emerging DevOps guidance into meaningful and sustainable training and certification. We do this by relentlessly studying the wide DevOps’ collective body of knowledge, engaging subject matter experts, attending conferences, interviewing case studies and just plain paying attention to the evolution of DevOps at scale.  We track and trend innovations that are delivering real value in real organizations. Our working groups and subject matter experts then encapsulate all of the knowledge on a topic into practical and tangible training. Where appropriate, a certification exam will accompany the training to demonstrate an individual’s skill and qualification in a specific topic area. Successful candidates will become members of the DevOps Institute.

    What are the benefits of formal training and certification courses?

    • Creates a common mindset and vocabulary
    • Encourages dialogue, sharing and collaboration
    • Sparks ideas and innovation
    • Provides sustainable and actionable steps
    • Teaches something that can help teams, organizations and individuals to improve
    • Creates holistic expertise
    • Gives individuals a sense of pride and accomplishment when achieving certification

    Did you notice that DOI is focusing more on “emerging practices” over “best practices”? We believe that DevOps is an emerging space where new practices are being discovered, proven and promoted frequently. We also believe in the DevOps spirit of sharing and collaboration, and will never designate candidates as “masters” or “experts.”   DOI’s training and qualifications instead will support a more modern role approach that embraces DevOps’ cultural focus on adaptability, transparency and organizational agility.

    In the DevOps Institute neighborhood, we hope to provide:

    • Just-in-time knowledge articles from our REPs and others that focus on an emerging DevOps practice or related framework
    • Information about current and upcoming training courses and qualifications
    • Access to a calendar of available classes from worldwide Registered Education Partners
    • Video interviews, templates and other assets to help along your DevOps journey

    So, welcome to our neighborhood.   We hope you find value in our sharing and come back often.