devopsy.kinsta.cloud

Tag: DevOps Success

  • 9 Ways DevOps Success or Failure Is Like Baseball

    9 Ways DevOps Success or Failure Is Like Baseball

    The baseball season is in full swing. There are 30 major league teams competing for a playoff spot, but, as I write this, only five of them—or 16.67 percent—qualify as elite performers with a winning percentage over .600.

    The number is strikingly similar in DevOps, where, according to one survey, just 17 percent of organizations say they have fully embraced it. Most of the rest have only scattershot teams immersed in DevOps or only recently began adopting it company wide. Fifteen percent are saying, “Wait ’til next year” and have yet to undertake this agile methodology.

    In baseball, teams struggle because of weak hitting, lousy pitching, poor defense, inept managing or all of the above. But why do some DevOps initiatives fail, who is at fault and what can be done to right the ship?

    Baseball and DevOps: More Similarities Than Differences

    Let’s dissect the differences between a DevOps program that hits the ball out of the park with a truly collaborative effort to build, test and release software faster and more reliably, and one that swings and misses.

    Is It Understood There’s No “I” in Team?

    Most DevOps initiatives fail because they are undertaken by a single practitioner within a single team. This is a strong personality who bulldozes the team to DevOps success, either out of career growth ambitions or genuine belief in DevOps tenets, only to have the team revert to their old ways when the practitioner leaves.

    Ironically, many if not most successful DevOps initiatives also begin with a practitioner on a single team. The difference in the latter case is that the leader doesn’t operate in a vacuum but shares lessons and best practices across the organization. They understand that if you are going to do something transformational, you cannot do it in the shadows or within a silo. They consider the long term. They lead by example and demonstrate the way forward to others.

    Are the Top Leaders Onboard?

    Just as the best baseball teams tend to have smart, supportive, quality-minded owners, the most successful and sustainable DevOps initiatives have top-down leadership support or mandates.

    Clear, consistent direction from the C-suite is necessary to motivate and incentivize people across the company and move DevOps initiatives from a patchwork of projects to an organizationwide philosophy.

    “Without executive support,” a Forrester report warns, “agile transformation is limited to grassroots initiatives—a very slow and difficult road.”

    Are the Danger Signs Recognized?

    There are two telltale signs that a companywide program is floundering. One, success is occurring only in a single team. Two, no one outside the team knows much or anything about that success. DevOps can’t grow within an organization if it’s an isolated black box.

    Starting DevOps is kind of like an entrepreneurial act. Startups become something bigger when the entrepreneur is successfully able to extend their vision. DevOps is the same: You need to infect other teams with your success. Winning begets winning.

    Another indicator of failure is if a company claims to be adopting DevOps but clings to traditionally organized and siloed teams. You can’t have it both ways. DevOps personnel need to be aligned by product, outcome or value stream—not by specialized work function.

    Is Success Measured?

    How does a baseball team know it’s winning the game if no one is keeping score? Same in DevOps. If you can’t objectively measure success, you don’t know if your program is meeting its goal of accelerating the software life cycle.

    Figure out how to measure the value of what is being done and delivered now so you can demonstrate its impact objectively. Examples could be application deployment frequency and time, error rates and mean time to detection.

    Is Seeking Outside Help a No-No?

    The DevOps community isn’t especially fond of vendors and consultants, but outside experts can bring fresh perspectives. No one tries to cure an infection or solve marriage issues by themselves, and solving DevOps challenges should be no different. Don’t be afraid to ask for help and if you have the budget pay of it.

    Can the DevOps Advocates Speak Business Language?

    DevOps folks often stumble when pitching for leadership support because they are unable to articulate their proposals in the dollars and cents language that business leaders understand. But if they can talk that way, practitioners may find leaders are much more willing to play ball than they realize.

    Is the Blame Game in Fashion?

    The biggest mistake organizations can make is bearing the classic IT coat of arms: arms crossed and fingers pointing. Don’t fall into the blaming trap. DevOps, after all, espouses the concept of learning from failure. So instead of pointing fingers, evaluate, consider, learn and move on with the lessons learned.

    As legendary New York Yankess manager Casey Stengall said, “All blame is a waste of time. No matter how much fault you find with another, and regardless of how much you blame him, it will not change you.”

    Does Failure Breed Success?

    Not to sound harsh, but if you start an initiative and it fails, it is your fault. Sure, many company cultures aren’t ready for DevOps, but others are succeeding where you have failed. If your team lost the World Series, another team won it. Why? There is always something that can be done differently. Determine what went wrong, accept responsibility and learn from it.

    Do People Bounce Back?

    If your initiative wasn’t successful, don’t be discouraged. Pick yourself up and try again. Being a DevOps leader requires courage and persistence. You’ll get ‘em next time.

    “Every day is a new opportunity,” Hall of Fame pitcher Bob Feller said. “You can build on yesterday’s success or put its failures behind and start over again.”

    — Scott Willson

  • TechRepublic’s Bombshell Survey: A DevOps Fiasco?

    TechRepublic’s Bombshell Survey: A DevOps Fiasco?

    This month, I chose to share the findings of a TechRepublic’s recent survey on DevOps not only because it’s a bombshell within the IT community, but because it brings out two eye-opening facts:

    1. Seventy-eight percent of organizations haven’t fully implemented DevOps because “they don’t get it”
    2. Only 22 percent of organizations have merged their teams for managing infrastructure, operations and development

    In other words, the message underneath is, “You must consider most DevOps success stories with a pinch of salt.”

    The big question is, Why are all these DevOps implementation failures happening? That’s where I bring the answers most experts, including renowned thought leaders, for some reason won’t give you.

    The findings of this vital survey shouldn’t leave you indifferent. Your company’s survival and growth depend on them. They’re recurrently raised in all the conferences and workshops I give. “We deployed the automation toolchain; honestly, I don’t see the business value,” or “Making the business, development, testing and operations work together is an impossible challenge,” is all I hear all the time. The last time I had to address these complaints was at the Econocom’s DevOps Seminar in Toulouse, France.

    The answers I provide result in the same reactions: Companies successfully change their DevOps vision and implementation approach.

    Believe it or not, that’s my six-year experience advising on DevOps worldwide, as well as the observations of an increasing number of reliable IT industry analysts including Joe McKendrick and Jason Bloomberg. The three fundamental failure factors of DevOps implementation are:

    1. Either a lack of or unclear business objectives.
    2. Widespread misconceptions of DevOps including among thought leaders.
    3. Conflicting interests of the DevOps tools business.

    Let me give you a few ideas that will either help you monetize your organization’s transition to DevOps or adjust your existing DevOps capability and make it profitable.

    Unclear Business Objectives Result in Irrelevant DevOps Capabilities

    Again, that’s my experience and the observations of many IT industry analysts, most DevOps initiatives are disconnected from any business objectives.

    In all the workshops I conduct, the question, “What’s your business goal?” gets the same blurry answers: “Adopting DevOps is a must,”  “We must automate our IT processes,”  “Making our IT agile will make our business competitive,” “Speeding up delivery is a competitive advantage our business lines will like,” and “Automating our IT processes will do good to the business.”

    What you must know is, these goals range from vague and fake to inappropriate and nonexistent. They primarily serve the IT department’s interests. Not the business.

    The fact is, there’s a significant gap between business line expectations and the DevOps benefits as imagined by your IT leader peers and their associated vendors. The business looks to meet the challenges of the disrupted markets created by Google, Amazon, Facebook and Apple (GAFA, in the rest of the article)—competition which includes continuous innovation, accelerated time-to-revenue, cost reduction, low prices and market responsiveness. And the only help DevOps experts offer is the acceleration of applications delivery and the automation of IT operations. Is it enough? The answer is clearly no; it’s a drop in the ocean.

    The GAFA are disrupting your company’s markets. The only chance to resist them is to adjust your business model to the new competitive constraints. Because they didn’t transform as their disrupted markets required, Nine West Holdings, the Bon-Ton Stores, Toys R Us, Remington, Southeastern Grocers and Tops Markets were all kicked out of business. Read what Business Insider’s Hailey Peterson said about it in a recent article.

    I encourage you to involve your business lines in your DevOps project and agree with them on a clear business objective. Then, implement DevOps to enable that objective. Otherwise, that’s wasted time and more importantly, wasted investment!

    The Secret of DevOps Has Always Been About How Well You Work, not Technology

    This is something I hope you won’t doubt: Most experts including renowned thought leaders play on words to present DevOps as close to either an agile software development framework or a continuous delivery infrastructure (CDI). Let’s say it straight: That vision, now adopted by CIOs, is erroneous and has been taking thousands of businesses into the wall.

    Adam Jacob’s article, “The Secret of DevOps, It’s Always Been About People, Not Technology,” provides from my perspective, the best definition of DevOps. It presents it primarily as, “… fundamentally about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.” But he makes it clear, “Tools matter. Make no mistake, trying to change the way you work without changing the mechanisms by which you do that work is a futile exercise in excruciating failure. But tools exist in service of the prime directive: building highly functioning, highly effective cross-functional teams, that attack your thorniest business problems as a unit, rather than as lone individuals or silos with competing incentives.”

    What’s interesting with Jacob’s big picture is, it’s definitely business-oriented and takes into account value creation drivers such as the human factor, values and behaviors, processes and practices, cross-functional collaboration and, of course, technology. Every qualified IT leader should understand these drivers as the fundamentals of their company’s survival and growth.

    So, shrinking DevOps to agile software development and Jenkins, Puppet and Docker, and thinking it will result in revenue doesn’t make sense. That’s the reason why the 78 percent of organizations in the TechRepublic’s survey failed!

    Would you agree that to set up a profitable business, the most important thing is to deploy Jenkins, Chef, Docker? I hope not!

    DevOps is about how well you mobilize your company’s assets— staff and skills, values and behaviors, processes and practices, tools and infrastructure—to make it competitive and wealthy. Adopting DevOps, particularly in today’s disrupted industry context, is primarily a business transformation effort. Nothing else!

    If you don’t want to be part of the 88 percent of organizations that proved unable to merge their team for managing infrastructure, operations and development, like Adam Jacob’s article suggests it, tackle DevOps primarily as an agile business operational model. Otherwise, get ready to be among the next GAFA victims!

    Preventing the Next DevOps Fiasco

    I’m afraid the conditions for the next DevOps fiasco are in place. They have a name: The incredible power of IT vendors.

    The incredible power of IT vendors relates to what Harvard’s strategist Michael Porter calls the “bargaining power of suppliers.” It’s the market or industry configuration where the domination of one company or a group of companies reaches a point where they can impose their views, products and services. IT vendors are exactly in that situation.

    IT tools have improved productivity so much over the last 30 years that companies have come to believe that they can fix every business problem including innovation, agility and profitability. IT vendors, using massive marketing hypes, are taking advantage of the situation to make millions of dollars. Dollars aren’t the problem; it’s the poor ROI their clients get.

    Will this TechRepublic’s survey help to prevent the next DevOps fiasco? Time will tell.

    Key Takeaways

    Your company’s priority is to survive the disrupted markets created by the GAFA. You won’t make it happen unless you definitely acknowledge that revenue, the essence of your business, is created as part of complex process that mobilizes across your company’s value chain, your staff and skills, values and behaviors, processes and practices and, of course, tools and infrastructure.

    If DevOps can’t help businesses with what matters right now—survive their industry disruptions— it’s definitely useless!

    As Chris Tozzi, suggests it, “The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.”

    Here’s a resource that tells you all about how to implement DevOps as the catalyst of your business competitiveness: “How to Yield Business Benefits with DevOps.”

    — Philippe Abdoulaye

  • Top 5 Considerations for DevOps Success in 2018

    Top 5 Considerations for DevOps Success in 2018

    Top tips for maximizing DevOps effectiveness

    Whether you are well into your DevOps journey or still thinking about getting started, there’s always room for improvement and an opportunity to learn from each other. Perhaps at the top of your to-do list this year is to implement DevOps as part of your product strategy. You can picture it in your mind: Increased software velocity fueled by frequent releases, better team collaboration and visibility, improved testing procedures and more robust and reliable products.

    But picturing something in your mind and making it a reality are two very different things. Which is why I’m offering what I consider to be the Top 5 Considerations for DevOps Success in 2018. Keeping these five items in mind as you make DevOps part of your organization will help increase your chances of having a successful implementation.

    However, before diving right into the top five, let’s take a minute to define what success looks like in this landscape. DevOps means releasing software every second of every day, right? No! While that may be a reality at companies such as Amazon and Netflix, it’s a common misconception that to be successful in DevOps you have to fire off releases constantly. In reality, what works fantastically for one company (say, Netflix) may not work at all for your organization. DevOps is a personal journey and realizing success is about being flexible and understanding your organizational requirements.

    With all that said, across organizations and industries of all kinds, one constant about DevOps that remains is that it should focus on making continuous improvement through changes, both big and small. In doing so, you will create the ability to improve the flow of work through your value stream to change how you deliver value to your customers. The only way to realize that improvement in value is through change, and if DevOps is designed to do one thing, it’s to make change easier.

    Top 5 Considerations for DevOps Success

    With a loose definition of what success looks like in this context, let’s take a look at the top five considerations for DevOps success to drive your business forward in 2018.

    Make the Work Visible

    The goal of every company in the software development space is to deliver value to your users. It’s often incremental improvements over time, but ultimately, your focus is to deliver a better product and a better user experience. The challenge is that it is not always (or even rarely) straightforward, and that’s because the work is not visible. When work is not visible—which means progress is not visible—not only can the work take longer, but also there may be misalignment within the company. This can lead to more mistakes along the way, as issues don’t get properly addressed in a timely fashion.

    Part of this issue of visibility stems from the fact that many companies don’t use tools or methods to visualize their entire value stream or the value flowing through it. While some companies use physical means to address this problem, there are modern platforms that are able to aggregate data from all the different sources, provide a digital representation of the value stream and help identify any value that is falling through it.

    Using a Common Currency for Value Across the Enterprise

    There are several parts of the software delivery life cycle teams might use to measure value for development—releases, versions, packages, binary artifacts, etc. When an organization is fundamentally measuring teams using different value currencies, it becomes very difficult to accurately understand whether it is successful. What it needs to do is find a common currency that can span the organization and give stakeholders and developers a real apples-to-apples way of comparing and looking at value-add. In DevOps implementations this common currency is work items. Then, when code commits are actually occurring, those code commits can be affiliated to those stories and work items, which is basically the business value. In that way, the business can use a common currency to track and measure progress.

    Measurement

    Over the past couple of years, we’ve seen many companies buying tools and changing processes and spending a lot of money in their DevOps initiatives. While these tools are great and can provide incredible insight into your workflow, it is necessary to dig deeper into the measurement to get a bigger picture of the entire pipeline.

    So, while measurement is important, what will really drive increased value for an organization is to measure the entire flow of value across the full value stream, not only in one phase or in one area. This means measuring from the very beginning—when an idea is created—all the way until end-of-life.

    Along this same line, it is absolutely imperative for a company to establish real baselines for its data. Even if the numbers aren’t pretty, the company must have truthful baselines not only to measure against future performance increases, but also to help identify bottlenecks and other areas of weakness that are opportunities to improve.

    Configuration as Code

    The goal here is to leverage version control in such a way that a company is creating ultimate efficiency in its build cycle. Versioning everything touched in the software development process will allow for speedier deployments. When there is an error, the team can roll back without much effort. Fundamentally, a company must establish the practice such that every code push becomes a snapshot of the configuration of the entire stack.

    Doing this effectively lowers computing code and it becomes trivial to stand up entire environments for the sake of a single user story or a single feature. Having configuration as code will allow a company to perform rollbacks much easier and will enable faster and more frequent deployments.

    Compliance

    Compliance used to take place after the software was done. When it had gone through development and testing, and prior to going into production, it was passed to a compliance team or officer who was responsible for making sure everything checked out. Not only does this slow things down, it creates a single point of failure and puts the organization at greater risk for not realizing ever-increasing and changing compliance requirements.

    In modern practices, teams are embedding the compliance aspect of software development into their value stream and that allows them to avoid rework and waste. Compliance activities should occur in parallel to the development and testing work, rather than when the release is marked done or code complete. Modern DevOps platforms allow builds of all the activities of the software development process into the different phases. The goal here is to have confidence that every software release that comes out of a company’s value stream will be fully compliant and can be deployed into production at any time.

    Conclusion

    Whether you are already knee-deep in DevOps or are just starting to consider it as a strategy to drive your business results forward and improve your software development, keeping these five considerations in mind will help you stay focused, generate better results and realize success in 2018. If your ultimate goal is to improve value for your customers through incremental and on-going change, it’s a great time to be part of the DevOps culture.

    Want more? Check out this webinar for a more in-depth look into what drives DevOps success.

    — Eric Robertson

  • DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

    In this DevOps Chat we speak with Steve Boone, product owner and development manager for Urban Code Deploy. Now that DevOps is in practice at more organizations, measuring DevOps success is a question many are asking. Steve has helped hundreds of companies adopt, implement and scale their agile and DevOps practices as part of their digital transformation. Steve gives us some insights into how can you measure your DevOps success.

    As usual the streaming audio of our chat is below. Following that is a transcript of our conversation to follow along.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 117787″ width=”100″ height=”100″] Steve Boone
    Steve Boone is a DevOps SME at IBM. He has helped hundreds of companies adopt, implement, and scale their agile best practices including CI, CD, Environment Provisioning, and Application Release Automation. Steve is currently the Product Owner & Development Manager for IBM UrbanCode Deploy.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to be joined today by Steve Boone. Steve is the Product Owner and Development Manager for IBM UrbanCode Deploy, one of the leading CI/CD solutions in the market. Steve, welcome to DevOps Chat—how are you?

    Steve Boone: Doing great, Alan. Thank you so much for having me today.

    Shimel: Great. Steve, I wanted to talk to you—well, about a couple of things today. But let’s focus in first on, I’m just back from another major conference, and once again I’m—not amazed, because by this point, it’s expected. But still, you know, going strong, the biggest thing we get, or the biggest feedback that I hear from organizations looking to do DevOps transformation is—hey, this all sounds great, it sounds really good, but how do we know, you know, first of all, how do we get started with our DevOps transformation, and then once we’re doing it, how do we know it’s working? Right? How do we measure the ROI, or even if we can’t get to a real ROI, how do we measure progress? What does success look like?

    And I would imagine, you know, the guys at UrbanCode, the team at UrbanCode has been dealing with this for some time. What do you tell people?

    Boone: Yeah, that’s a great question, and it’s—you know, I think it’s a little different for everyone. And when we start looking at measuring success and first finding out, you know, where do we start, a lot of times we’ll work with customers to identify, you know, what are your problematic areas? There’s a lot of aspects to DevOps, it’s not all CI/CD, there could be aspects of agile planning, there could be release management. There’s a number of different things that come into play.

    So, we usually sit down and try to focus on, you know, where do you think your bottlenecks exist today, and then start to address those. But when we went to measure—and you know, you’re right, the allure of DevOps comes with all of this ROI promise, right, where if we do these things and we change our people and our process and our tools, we’re gonna be better off for it, the business is gonna be better off for it.

    So, how do we then make sure that’s actually happening, right? That the time and energy that I’m putting into changing my processes are actually showing me that ROI.

    So, what we’ve seen a shift in the industry towards is really starting to gather the different sets of metrics that are coming from, really, the end to end products that we’re dealing with in DevOps whether it’s your build tools, your testing tools to understand what I’ll all our key metrics. So, you know, if in fact we are capable of speeding up our delivery to our pipeline, we should be getting to market faster, right? So, we look at statistics like cycle time—how long does it take for an application or a release of application to go from dev to prod? And then we look at that data over time. Is it, in fact, improving? And if not, we want to identify other bottlenecks that are kinda holding that progress up.

    So, if I look at a set of components that make up an application and I see that the majority of those components have a really good cycle time, you know, we’re only as fast as our weakest link. So, if the database component, for example, is routinely slower to get through QA than the rest of the component, that’s going to slow down our time to market and therefore gonna slow down our release.

    And the beauty is, in turning on the flashlight, so to speak, so that you can see that data and actually do something with it, a lot of times we look at it and say, “Well, we know we have automation and therefore we know we’re going faster.” But that just might mean we’re going to QA faster or we’re going to dev faster. We want to make sure that we’re actually getting that ROI, so if we can set baselines with teams and say, “Hey, prior to doing this automation, it took you four months to get from dev to production out the door, right? This past release cycle we did it in three and a half months—great. What is that time savings? What does that time savings mean in cost?”

    And, we’re starting to see a big trend within the industry of many different companies starting to put together products to start to track these. So, I think it’s a whole new area for us to focus on, and in hopes—what we’re trying to share with customers is that, look, not only are the changes in people and process that you’re making working, but the tooling is working, and hey, here are some areas where you can improve those processes.

    Shimel: Yeah. So, Steve, obviously, I want to—you said a mouthful, there. [Laughter] But let me focus in on one thing you said that I want to re-emphasize to our audience, and that is, you know, DevOps is so much more than CI and CD, right? There’s config management, there’s APM—there’s a lot that goes into this umbrella term that we call DevOps, and it seems to be growing every day.

    That being said, though—you know, I once heard someone describe DevOps is the symptom and CD is the cure. So, you know, I don’t want to minimize the importance of CI/CD, but you know, automation—there’s so much that goes into this equation or this term that we call DevOps. And I think that’s—you know, Steve, it’s almost like it’s its greatest asset but it’s also its greatest liability, you know what I’m saying?

    Boone: Yeah, there absolutely is. I think that a lot of times, we definitely see, when people are talking DevOps, their focus tends to be on CI/CD. And I think that’s because, you know, out of the gate, especially if you’re just starting off, it’s kind of your biggest bang for your buck, right? You can get a lot of fast return on investment just by improving your processes and automating them and making them consistent.

    As we see teams mature, and as they transition into a more Enterprise wide DevOps solution, then we start to see—well, where are the real boundaries in my organization, right? Is it, we see a growing trend where app dev teams are focusing on automation, but there’s a whole different silo in infrastructure, you know? So, an app dev team wants to request an environment to do some testing in—they have automation, and the tools that they have for automation could easily provision that environment. But the business dictates that that’s the infrastructure’s just, and they have a completely different set of tools that they use for that, right?

    And so now we get into this challenge of really continuing to try to break down these barriers to make sure that these assets and tools that are out there can work together, and that there’s clear cut guidelines on that.

    So, yeah, I think it is a blessing and a curse, right? Because when we start thinking about DevOps, everybody wants that—you know, we’re a culture of having that instant gratification. So, it’s nice that we can get that with deployment automation and build automation and test automation. But we need to be looking ahead to the future, which is gonna be—hey, I’m gonna provision these things on demand and make these environments available to my teams, and today we use Amazon for that. What happens if, six months from now, we have to change and we need to support Azure or Google or SoftLayer or Bluemix, right? We need portability, we need full stack provisioning and config management on that.

    And that’s—I think that’s something that, a lot of times, people just starting out, they don’t look too far ahead. And my suggestion to folks is—hey, it’s okay to take that first step. You should be cautious about the first step, but keep in mind where you wanna be two years from now, three years from now, five years from now. What’s your DevOps end goal?

    Shimel: Yeah. You know what? So, Steve, I think that might be the first question we need to—especially for consultants out there who may be listening to this. You know, whether you work for an IBM or a small consultancy, I think that has to be the first question. You know, people come and say, “I want to do DevOps.” You gotta ask them, what’s the end goal, here? What’s the end game? Why? And that’s a huge piece of it.

    Steve, if I can, I’d like to turn to a little bit more about UrbanCode and, you know, UrbanCode’s kind of a unique animal, if you will, in that, you know, it was one of the earliest, earliest kinda startups playing in the CICD space, right? And so it had that whole startup culture, if you will, the startup thing going on. And then, of course, you know, acquired by IBM and really become a linchpin of, you know, IBM’s DevOps, and not only DevOps, but you know, in IBM, as you know, DevOps is tied into cloud and hybrid and Bluemix and SoftLayer and all the things you mentioned. You know, it’s such a critical piece of that puzzle.

    What is happening lately with UrbanCode? I saw Gartner give you guys some accolades recently.

    Boone: Gartner gave us some accolades. We scored very well, as well, on the Forrester Wave that just came out.

    Shimel: The Forrester—yes.

    Boone: We were named as a leader in the—yep, in the Forrester Wave. So, that was exciting. It was a great score for us. We’re about as far right in that quadrant as you can be.

    And there’s a lot of really good things coming out. I think the reason we scored so well is that they’re looking at the strategy within UrbanCode and seeing that, you know—as you mentioned, this isn’t our first trip around the block. We’ve been helping customers do this for over 10 years. And for us, you know, we work with companies that are small startups to everything that are enterprise financial institutions and healthcare and government agencies.

    So, there are, at any given time, different, I’ll say, business focuses that are in a different spot of transition. So, I can go to an enterprise and talk to 30 different groups and organizations in that enterprise—they’re all in a different maturity, they’re all in a different level and area of that DevOps transformation. But what we’re able to do is, we have a solution that can help everybody regardless of where they’re at, and as they mature together over time, ultimately help them reach the goal where the company wants them to be.

    You know, some of the new things that we’re focusing on—you know, last year, part of our vision, we had announced at Interconnect our DevOps Insights product as well as our continuous release product that are focused on helping customers one, transition into DevOps, do a lot of that deeper reporting and ROI analysis on where they are in their transformation, but as well as help companies manage to the cloud and for the cloud.

    What I mean by that is, you know, today, we talk about cloud like it’s ours, but for large enterprises, it’s still very much a challenge. You know, it’s hard for a team to just go request access and say, “Hey, I’m gonna push my data to the private cloud.” There’s still a lot of—or even public cloud, whatever it might be. There’s still a lot of hurdles to that.

    So, what we’re trying to do is, as teams embrace this and they’ve got deployments going on-prem and off-prem, how do we organize that? How do we have visibility and traceability and understand as you’re taking large applications and breaking them down, let’s say, into microservices? You know, some of those applications are easy to re-architect, some are not. And sometimes you’re left with applications where you’ve only got maybe three quarters of that application re-architected, or you’ve got databases that are always gonna be on-prem, or you’re using mainframe services.

    And that’s really where the UrbanCode products excel, is allowing you to really deploy anything, anywhere, but also have a cohesive look at, what are the interrelated appendices of those parts? If something on my backend mainframe changes, how is that affecting the things that I’ve deployed into my mobile app? And if something needs to fall out of just release, you know, what’s the impact, even? How is that gonna affect business? And I think those are some of the main reasons why we scored well within the Forrester Wave and why they marked our strategy so high.

    Shimel: Absolutely. You know, Steve, we’re coming up on the end of our allotted time, unfortunately, but I wanted to mention one thing if we can talk about it, and that is that you spoke about Interconnect, which has been the big IBM DevOps related show, as well as other technologies for the last couple years. This year, IBM is kinda consolidating a lot of the shows they do into a pretty big mega-event called Think 2018, and of course, that is gonna be once again at the Mandalay Bay in Vegas, and it’s happening March 19th to the 22nd. I believe the call for speakers has just opened, and I’ll put some links in the show notes so that people can, if they wanna speak or if they want to attend the event would be great.

    But in any event, what’s UrbanCode’s plans around Think 2018?

    Boone: Yeah, thanks. I hope folks do and are able to register and come out. It’s going to be a fantastic show, and it is very much a mega show for us. So, we’ve taken—I believe there’s 11 different topics that really, I’ll call them focal points or even think of them as investments within IBM. Everything from cloud to Watson to mobile to security, internet of things—there’s a number of different topics going on at this.

    UrbanCode will be under the cloud focus, and we’ll—underneath the cloud topic, there’s a section specifically for DevOps. So, if that’s what you’re interested in, come out and check us out—we’ll be there. We’ll be talking about our latest release that we’ll have done at that time, and we’ve got a lot of really cool features that were actually in development and testing right now that we plan to announce at the Think conference, so without be demo-ing those, and we’ll have—as always, have a bunch of UrbanCode customers there sharing their ideas, sharing their experiences, and really helping educate how they’ve transformed their business.

    And I think what a lot of folks will find appealing is that it’s never a one tool solution, right? And that’s one thing I always encourage folks is, when you’re trying to be in a DevOps transformation, a single product, a single methodology—it’s not gonna do it. You really need to embrace the various tools that are in the market, you need to embrace existing tools that are already in your company, and these are gonna be working examples and explanations of how some of the top companies in the world are doing just that using UrbanCode and using a variety of tools that we support.

    Shimel: Absolutely, absolutely. Alright, Steve, we’re actually way over time, I apologize, but I think we got some good information here that people will be interested in. I want to thank you for being our guest this week on DevOps Chat and invite you back soon. We want to hear more about Think 2018 as we get closer as well, but good luck with UrbanCode, Steve, and we’ll speak to you soon.

    Boone: Hey, Alan, thank you. As always, appreciate you having me today.

    Shimel: Alright. Steve Boone, Product Manager, UrbanCode Deploy—or Product Owner, excuse me, UrbanCode Deploy. Thanks for being our guest on this DevOps Chat. This is Alan Shimel, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel

  • Our Sprint to Agile Success

    Our Sprint to Agile Success

    Adoption of the agile methodology is essential to the success of a DevOps culture. This is not revolutionary, but is an important foundation.

    We view agile as the tool for developers to achieve DevOps. Our team, which is developer-centric, is focusing on the agile piece of the equation moving forward.

    But what happens when you think you have a grasp on the agile methodology but it turns out you were completely wrong?

    A change is needed.

    Getting back to the Agile Manifesto is a great starting point. This is our story of DevOps failure to success by implementing the correct agile methodology.

    Our Perception Was Wrong

    When thinking about the agile methodology, and, to a greater extent, DevOps, open communication is at the core. However, it is not the only thing agile and DevOps is.

    At the beginning, we thought as long as there was open communication we were agile. Seeing as we sat in the same room, this was pretty simple. But we quickly learned that this was not agile, and the revelation was painful.

    As we experienced development bottlenecks and difficulty in defining responsibilities, we knew there needed to be an adjustment in how we viewed the agile process. Also, we had begun adopting projects in areas where we did not have a high level of expertise.

    This is what brought us back to the drawing board.

    Getting back to the basics meant looking at the reason for implementing agile in the first place. For us, it was releasing better software, more often, with fewer updates. In detail, it was looking at how long it took the team to identify and define the need. Then, it was looking at how long it took from problem definition to software release. We consider this one software cycle.

    The reason for implementing agile is to decrease the time it takes to move through one of these cycles, as well as to decrease the number of cycles on any one project. Defining this process to the team is how we brought our software development back to the basics.

    Renewed Focus

    Once there was a renewed focus, it was time to implement a set of tools and processes. The concepts we focused on incorporating are the following:

    • Adoption of sprints
    • Open communication
    • Version tracking
    • Environment of continuous testing
    • Responsibility definition

    None of these are particularly revolutionary, but when implemented effectively, it made a world of difference. Once we defined these five areas of focus, we adopted the daily sprint meeting. This implementation was the core of our transformation into a truly agile environment.

    The Daily Sprint Meeting

    In the developer environment, meetings can be against the team culture, especially in a startup. This is why a meeting needs to be strategic. The daily sprint meeting should have both a question constraint and a time constraint. The result is no dragging meetings.

    The two metrics for the daily sprint meeting are: 1) each team member gets two minutes to speak, and 2) four questions need to be answered. Those are:

    1. What did I accomplish yesterday?
    2. What will I achieve today?
    3. What obstacles do I face to accomplish my projects?
    4. How am I feeling today?

    With a team of five people, this meeting should take 10 minutes at the beginning of each day. The adoption of the daily sprint has helped us achieve a level of focus not possible without it. This focus has produced increased productivity, as well as adopting an effective agile environment.

    The daily sprint meeting is how we successfully implemented a DevOps culture. This has made all the difference within our team.

    About the Author/Logan Rivenes

    LRivenes PictureLogan Rivenes is a Marketing Manager with Datapath.io, specializing in decreasing latency through network traffic optimization for DevOps.
    Twitter: @loganrivenes

    LinkedIn: https://www.linkedin.com/in/logan-rivenes-01a8964a

  • Funding Failure by Intent

    Funding Failure by Intent

    Why is it that when we purchase a lotto ticket, every part of our brain tells us we won’t win, yet some portion of it is able to inspire hope where there shouldn’t be any? Could it be the same part of our brain that inspires hope in the face of nearly certain failure has been nurtured by the software development projects we have been exposed to over the years?

    It would appear that the ability to prognosticate has been the foundation of nearly every waterfall project that had a timeline of three years or longer. It is this myth of “certainty” that agile methods are designed to eliminate. In our new approach, we simply break down and digest the scope of work until it is small enough for our risk tolerance, and easy enough to implement in our abbreviated time horizons. We try, we evaluate and we try again.

    But no matter how low we believe the risk to be (and generally the reward we expect from it), risk does remain. And now instead of a three-year project plan well-equipped with milestones, corrective actions and projected costs, agile gives us only the current sprint, based loosely on our historical velocity and a literal “addiction” to continue this process going forward without any real regard for a predictable end-point or total project cost. Continuous delivery infers continuous innovation (emphasis on the word “continuous”). And if done right, why would a business ever choose to end innovation that works?

    Imagine the analogy of Mozart sitting down to compose a quick advertising ditty that your company could play as background music on its website. Mozart begins with a few bars, and notices a theme that is worthy of far more exploration … so he does. He continues exploring this until an epic symphony emerges. This was not the plan and does not meet the original requirements. This could be considered scope-creep in the waterfall world, and thus a failure, as no one stares blankly at a website for the 30 minutes it takes to hear an entire Mozart epic … or do they?

    Every audience grasps the concept of background music we pay little attention to but subconsciously understand it improves our experience. But nearly every audience also realizes the beauty of a Mozart epic, and would gladly buy CDs, MP3s or concert tickets to hear one of those over and over again, relishing every note. The question this analogy begs is simply this: Would Mozart’s employer—more specifically, his development manager—have been free to fund this “failure” or not? What happens when a project changes direction significantly away from the first vision we had of it? Does DevOps enable us to pursue this radical change in direction, or are our legacy financial systems and methods binding us to a waterfall delivery and reporting structure—and, in so doing, limiting what we will ever be able to accomplish through radical innovation?

    The beauty of agile construction and DevOps delivery is that we may deliver “unexpected” innovation. Nearly every time a user “sees” what we have delivered to meet their need, they immediately think of “x” more things we could do to make it even better. This may result in taking a project in a radically different direction within the confines of a single financial year. To further enable our ability to do this, our legacy financial funding and reporting systems must evolve to match this demand. Our new risk profile must include the ability to fund failure on purpose, understanding that failure itself is part of the maturation process of innovation, not the death-knell of the company.

    A more honest approach to funding agile/DevOps efforts would be to determine the annual investment the organization wants to make in certain capabilities, and innovations it expects to see in each thematic area. Overarching themes are funded on an annualized basis; however, great autonomy is granted and expected within the themes to ensure delivery is achieved. Pushing financial responsibility down in the organization to as low a level as possible has the effect of pairing the team leaders with the costs of what they do. Spending too much time on delivery of any given feature or function may cause the team to re-evaluate the approach and propose a better solution. This is more unlikely when budget responsibility is managed several levels above the team doing the work—in that instance, the budget resembles more of an infinite resource they need not be concerned with, until it is too late.

    When proponents of DevOps claim it is changing the culture of a company, they are not limiting this view only to IT. Tertiary services in a company, such as the supporting financial budgeting systems, hiring systems and even contract management systems, may require significant change to match the pace of delivery and innovation DevOps delivers. As an enterprise looks to implement DevOps, it should look broadly at what else may be required to fully enable the pace of innovation it is capable of.

    To continue the conversation, feel free to contact me.

  • 7 Sets Of DevOps Success Metrics From DOES ‘15

    7 Sets Of DevOps Success Metrics From DOES ‘15

    Beyond the moral support, the executive management coaching and the tips on how to build DevOps momentum in the enterprise environment, last week’s DevOps Enterprise Summit 2015 offered a boatload of excellent fodder for those seeking to prove the value of DevOps patterns once they got back home.

    DOES wasn’t just about cheerleading—alongside lessons on the soft, squishy elements of transforming IT, nearly every speaker offered up stone cold numbers to back up why those transformations make business sense. The performance metrics shared by speakers were impressive and could go a long way toward swaying skeptical stakeholders. Here are some of the highlights.

    Ticketmaster

    Ticketmaster CTO Jody Mulkey offered a ton of excellent examples of how an organization-wide commitment to DevOps has fueled innovation and stability at his company. For example, he described how what Ticketmaster calls the ‘Boom Team’ has used a completely integrated team of devs, operations, QA and other staff of about 20 to shift its Ticketmaster.com property—which accounts for 40 percent of the company’s revenue—from a duct-tape and bubblegum affair with 2000 ModPerl at its base into a modernized system continuously delivered by that team. Similarly, its technical operations team has embraced the DevOps ethos in order to deliver what it calls ‘support at the edge’ for WebOps incidents. The success of this approach has resulted in:

    • 90 percent reduction in mean time to repair (MTTR)
    • MTTR from 47 minutes down to 3.8 minutes

    “This was a phenomenal change,” Mulkey says. “The business went crazy over this. These are measurable outcomes that have really helped demonstrate that we are making progress.”

    Target

    Target brought forward speakers to discuss the retailer’s innovation in a number of key areas. Heather Mickman, director at Target, talked about how her API team worked hard to not only easily expose product and store information via its APIs, but to also challenge itself in the way it was delivering its work.

    “We wanted to deliver new capabilities in days and not months,” she explains, saying the team needed to be sure that it could scale its APIs because it new that they would be highly reused—both internally and by partners. Target has:

    • more than 90 APIs
    • monthly volume of calls to these APIs have grown in one year from 1.5 billion to 17 billion
    • deploy 80x per week across stage and production enviornments
    • all that, with fewer than 10 incidents per month
    • this volume helped support in 2014 a 42 percent increase in guest traffic and 280,000 orders fulfilled on Black Friday alone

    HP

    HP CIO Ralph Loura says HP didn’t go for the big bang approach, but through careful pilots and the use of communication afforded by ChatOps infrastructure, his team has been able to drag HP IT slowly into the DevOps fray. That’s a good thing, considering the massive scale of the organization:

    • 7,000 developer and operations staff
    • handling over 20,000 change requests per year
    • supporting 1,400 apps
    • and 1000s of builds per day

    CapitalOne

    After four years of hard work to move toward DevOps and continuous delivery, CapitalOne Product Manager Tapabrata Pal had a number of impressive statistics to share on its its progress:

    • Code commits have moved from random occurrence to hundreds per day for any given product team
    • Integration has moved from 1 per day to every 15 minutes
    • QA performance has shifted from monthly to four times per day
    • Production releases have moved from quarterly to one per sprint
    • Defects have been reduced by approximately 60 percent
    • Feature delivery rate has increased by approximately 50 percent

    CSC

    Paula Thrasher, application delivery lead with CSC, stepped up in front of the DOES audience to show them how it is possible to battle bureaucracy at any organization—coming from the government sector, she has first hand knowledge of what it takes. In one example she shared, her organization helped a client move its cyclew time from automating deployments to staging:

    • from 12 hours down to just 12 minutes and 30 seconds.

    IBM

    IBM’s Angel Diaz, VP of cloud architecture and technology, talked about how enterprises can still innovate at the pace of startups while delivering at scale. The thing with IBM is that it puts its money where its mouth is when it comes to DevOps—the company has doubled down to not only offer a number of products viable for the continuous delivery pipeline but to also completely transform its own business through DevOps practices. Some of the results it has seen by shifting its 2,000-plus developers and 100-plus squads in the Cloud Services division to DevOps:

    • 300 percent increase in “pure coding time” for its Cloud Services developers
    • reduction of deployment time from 32 hours down at first to 6 hours and now to minutes
    • an increase of release frequency from months to every three weeks.

    Disney

    Disney’s Jason Cox, director of systems engineering, got the crowd pumped up with a slick mash-up video of Star devWars and DevOps themes (not to mention a private showing of the most recent Star Wars trailer at the end of his talk!). But he didn’t favor style over substance. In his talk he described how much success Disney has grabbed up through DevOps, including:

    • 75 percent reduction manual steps
    • reduction in deployment time for large online/digital experience systems from 3 hours to 20 minutes
    • ability to provision 300-700 srvers within 15 to 30 minutes
  • Budgeting for DevOps Success

    Budgeting for DevOps Success

    One concept that seems to be universal across all IT departments is the admins lament of “how do I convince my boss that we should spend the money.”  Whether it is security, QA or development tools, technical professionals have a difficult time talking the language of the business to justify the expenditure of always scarce dollars. So why should it be any different with DevOps?

    The good news is that in DevOps unlike some other IT disciplines we can actually show some ROI (sometimes anyway).  Nothing will convince a financial stakeholder that spending money is OK faster than if you can show it will allow the organization to either save money or make more money. But how do you show ROI with DevOps. There is more than one way to skin that cat.

    This coming week I am hosting a webinar that will explore the various ways of showing ROI using DevOps.  We will also be looking at some case studies where ROI was demonstrated successfully. One of these organizations is HM Health Solutions. One of the interesting things in this case is that as a health care related organizations the usual compliance issues such as HIPAA often make things like automation and continuous delivery more complex.

    I will be joined by Valerie Scott, Manager of Shared Services Division, HM Health Solutions who is going to relay first hand what she and her team have done to show their executive team how DevOps delivers a real, tangible and measurable ROI.  Valerie is a seasoned exec and I am sure she will have some great insights.

    In addition to Valerie I will also be joined by Rick Slade of IBM who has lots of experience with different organizations in showing the ROI of DevOps.  I expect this webinar to be very informative.  If you are grappling with how to justify a shift to DevOps in your organization I invite you to join us next Tuesday, June 2nd.

    This webinar is sponsored by IBM. It is the third in the series we are doing on Variable Speed DevOps. Our previous webinars in this series have all been very interesting. You can listen and follow along to those here and here. The series deals with how organizations can do more faster  even though not parts of the stack run at different speeds. It is not how fast they run individually, but how well they work together is the key.

    So join me Tuesday as we discuss DevOps ROI and Variable Speed DevOps.