devopsy.kinsta.cloud

Tag: agile

  • Culture Comes First in Bringing DevOps to the Mainframe

    Culture Comes First in Bringing DevOps to the Mainframe

    One of the most difficult challenges in engineering, oddly enough, isn’t technical: the challenge is culture transition management. In my 20-plus years of managing engineering teams worldwide, I’ve led teams through countless organizational adjustments and process improvements toward high-performance and quality, beginning with QA segregation to CMMI to ITIL, AGILE and SAFe.

    Today, mainframe organizations have emerged as the focal point for enabling DevOps capabilities and practices. Why the mainframe? Well for starters, business critical applications rely on mainframe data and business components. These applications are mission-essential and that sustained innovation requires solution sets that deliver continuous testing, continuous delivery and continuous feedback on the mainframe platform.

    But culture comes first.

    Understanding Your Key Players

    In conversations with our customers we’ve observed an interesting dynamic emerging within mainframe application development teams. Within these teams are experienced developers who were instrumental in creating the applications that helped make their companies so successful. Over time, many have become set in their ways, adopting a motto of, “If it’s not broken, why fix it?” Such developers are not interested in trying out new things, including programming languages and tools used by the modern-day programmer.

    New to the scene are the millennials who have also taken up the mantle of enterprise software engineer. They are a bit more open-minded and bring a different programming language profile, including Java, .NET and C. These developers might be learning how to code APIs with the support of management, and have likely dabbled the basics of how to code iOS apps. Millennial developers are typically much more active online and, as a result, prefer to leverage Twitter and other social channels to stay informed with the development community.

    United We Stand

    Who, then, should be involved in the journey to realizing DevOps? The answer, of course, is both. Because we’ve heard it reinforced among our users we talk with in the CA Communities every day, at user groups and at prominent mainframe community events such as CA World and SHARE.

    You know it, because you probably see it in your organization as well. There are experienced developers: people who have deep knowledge of the applications in place, business intelligence, database tables, cross-application dependencies, batch execution windows and the general experience of how things work on the z/OS platform.

    Most importantly, they also know how to avoid breaking what’s working.

    And there are the millennial developers: people who are curious to learn about new programming languages, platforms, people who, with the advent of Agile development, and open source have played with things, tested them and are using it to enhance their skill sets.

    These people prefer to use modern user interfaces and tools to increase their productivity. Sometimes they might be tentative about making mainframe changes, not willing to risk their careers by breaking poorly documented code.

    Culture – Have it Both Ways

    While the interests of millennial and experienced developers may at times seem conflicting, both have pivotal roles to play in application development and will benefit greatly from the common sense practices of DevOps and agility that are coming to the mainframe platform. To survive and thrive, teams must unify to facilitate the change process. Most importantly:

    • Code must be accessed and modernized at the speed of business. Enterprise developers, testers and architects cannot be afraid to go talk to the “black box” that is the mainframe team.
    • Project managers can’t worry that a six-week turnaround for small changes will kill their hopes of meeting their delivery windows.
    • The delivery team—QA, release management and operations—can’t afford to sit around waiting for simple deployment steps to happen: when we can automate and integrate to increase deployment frequency.

    The promise of DevOps and agility on the mainframe is to fix this, and that’s why our engineering teams are actively building out solution sets that extend DevOps practices to the mainframe, including continuous testing, continuous delivery and continuous feedback.

    Curious about what it will take to bring DevOps to the mainframe? Catch some tips and best practices from Forrester Research principal analyst Rob Stroud, or hear from the leaders driving change in their organization in our CA World 2016 Mainframe DevOps panel.

    — Aline Gerew

  • 5 Ways DevOps Can Help Improve IT Security

    5 Ways DevOps Can Help Improve IT Security

    You already know DevOps can make software delivery faster and more efficient. But did you know it can help to keep software more secure, too? Here’s how.

    DevOps refers to a set of practices and cultural priorities related to the way software is designed, produced and deployed. It emphasizes collaboration between developers (the people who write code), IT Ops (the folks who manage software in production) and everyone in between—such as software testers and designers.

    When done properly, DevOps greatly reduces the time it takes to bring software from idea to implementation to end user delivery. It also adds efficiency to the software delivery process in many ways. It allows different team members to work in parallel, for example. It also ensures that coding problems are found early in the delivery pipeline, when fixing them requires much less time and effort than it does once a bug has been pushed into production.

    DevOps and Security

    But making software delivery faster and less costly isn’t the only thing DevOps does. DevOps also helps make software more secure.

    It does this in several ways. Consider the following:

    • Visibility. DevOps encourages constant communication between all members of the IT organization. That maximizes each team member’s visibility into the software being developed. In so doing, it places as many eyeballs as possible on the code, at all stages of delivery—which maximizes opportunities for your staff to find security flaws before code is released into production.
    • Automation. In the DevOps world, software delivery tasks are automated as much as possible. With automation comes consistency and predictability—and a much lower chance that human error during a manual process could introduce a security vulnerability.
    • Fast updates. DevOps enables a much faster pace of software delivery. That means that security bugs (and bugs of all kinds, for that matter) can be squashed very quickly by rolling out a fix.
    • Tool-agnosticism. With DevOps, you can use whichever tools or programming frameworks you like. You’re not bound to particular platforms or vendors. That’s important from a security perspective because it empowers you to adopt the tools that are most secure for your needs—not the ones you’re locked into because you have an outdated, inflexible software release process.
    • Agile technology. While DevOps doesn’t require you to use any specific type of tool, DevOps teams tend to favor next-generation architectures and technologies, like microservices and containers. These help to make apps more secure by reducing attack surfaces and enabling quicker reaction. If you deploy your app using containerized microservices, it becomes harder for attackers to compromise your entire app, because an attack against one microservice doesn’t give them control of the other ones.

    DevOps isn’t a silver bullet when it comes to cybersecurity, of course. Keeping your systems and data secure requires careful planning on a number of fronts and implementing a variety of tools.

    But DevOps—especially a highly automated, DevOps-based release process—should be one important weapon in your cybersecurity arsenal.

    — Chris Tozzi

  • Puppet Launches 2017 State of DevOps Survey

    Puppet Launches 2017 State of DevOps Survey

    It’s that time of year again!

    We at Puppet have kicked off the 2017 annual State of DevOps. survey. Now in its sixth year, we have once again teamed up with DevOps Research and Assessment (DORA), founded by our dear friends Gene Kim, Jez Humble and Nicole Forsgren, to survey technology professionals worldwide in an effort to better understand the health and habits of organizations adopting DevOps. We’re pleased to see that the report now serves as the de facto gauge for the DevOps community to find out how IT organizations are doing and how they can improve.

    One of the most critical aspects of the survey is that it manages to translate the processes between technical practices and choices into actual business outcomes and helps organizations understand the real benefits of DevOps adoption. Through analysis of each year’s survey responses, we’ve been able to quantify IT performance. From last year’s report, we know that high-performing IT teams are pulling away from the pack in terms of throughput. They deploy 200 times more frequently, have 2,555 times faster lead times, have a three times lower change failure rate and recover from failures 24 times faster.

    Survey Says …

    This year, we’re interested in learning more about infrastructure architecture patterns within organizations. We’re not just asking how the services are designed, but we also are curious to see if teams are free to move at their own pace and if they are largely self-sufficient. Can they easily make large-scale changes to their architectural design?

    We’re asking questions about team experimentation and whether teams are able to evolve the design of their architecture as they work and if they are required to interact with a lot of people across the organization. One of the things to emerge from the agile and DevOps movements is that the more we can enable teams to work quickly and self-sufficiently, and increase speed without reducing quality, the better it is for everyone.

    This year, we expect to see proof that high-performing IT teams are those who have been enabled to operate with a much higher degree of autonomy, and that their quality metrics remain stable or even exceed those of high-performing IT organizations. We also expect the findings to confirm that early DevOps adopters are still seeing exponential benefits compared to their colleagues who haven’t yet embraced DevOps. The longer your organization has been adopting DevOps practices, the more it becomes muscle memory and reinforces positive behavior within them, which has unparalleled benefits. As any IT professional working in a large company knows, there’s an awful lot of waste and inefficiency and we’re not anywhere near peak DevOps penetration. With each passing year, survey results show DevOps adoption is a key contributor to enhanced productivity and efficiency. We expect this year’s results to be no different.

    We’ll be publishing the results and our analysis in June, and have no doubt it’ll be worth the wait. Stay tuned!

    About the Author / Nigel Kersten

    Nigel Kersten is CIO of Puppet. He came to Puppet from Google, where he was responsible for the design and implementation of one of the largest Puppet deployments in the world. At Puppet, Nigel was responsible for development of the initial versions of Puppet Enterprise, and has since served in a variety of roles, including head of product, CTO and CIO. He has been deeply involved in Puppet’s DevOps initiatives, and regularly speaks around the world about adoption of DevOps in the enterprise and IT organizational transformation.

  • Predictable Progress: Tracking DevOps Maturity Metrics

    Predictable Progress: Tracking DevOps Maturity Metrics

    As DevOps methodologies continue to evolve, we’re naturally seeing an increased emphasis on the cultivation of related maturity metrics.

    For instance, in the 2016 State of DevOps Report, researchers with DORA took an initial stab at creating relevant ROI measurements.

    Similarly, a new report issued by researchers Coleman Parkes, sponsored by CA Technologies, offers additional evidence that as agile and DevOps processes continue to expand, today’s practitioners are increasingly employing metrics to optimize their efforts.

    The report, titled, “Accelerating Velocity and Customer Value with Agile and DevOps,” finds some form of adoption among nearly every enterprise, with 87 percent having adopted agile to some degree and 73 percent leveraging DevOps.

    Related to the overall maturity of these practices, those organizations that are moving to embrace the techniques most broadly are predictably seeing greater returns. Yet, despite the widespread adoption, only a third have deployed either practice widely, according to the research.

    Percentage of Advanced Adopters Reporting Improvements in Customer Experience

     

    Based on a survey of 1,770 senior business and IT executives, the study also closely investigates the specific KPIs that organizations are using to gauge how agile and DevOps initiatives are translating into customer interactions.

    Most notably, “advanced” agile and DevOps adopters have observed more than an 87 percent improvement in overall customer experience, compared to “basic” adopters.

    In terms of how those efforts are affecting business drivers, Coleman Parkes finds:

    • Advanced agile practitioners are experiencing a 40 percent improvement in time-to-decision, compared to 33 percent for basic users.
    • Advanced DevOps adopters have noted a 42 percent improvement in speed-to-market, compared to only 24 percent for basic practitioners.

    Key Performance-Invoking Indicators

    To that end, the research highlights specific KPIs that organizations are using to measure the impact the agile and DevOps practices are having on customers. In fact, the study finds that between two thirds and three quarters of all the organizations surveyed have established such measurements.

    At least half of these focus on business or customer-related metrics, reflecting how “critical software has become to businesses’ ability to achieve their core mission,” Coleman Parkes researchers note.

    Among the mostly widely invoked metrics, include:

    • Business growth (specifically revenue): over 73 percent
    • Operational or process efficiency: over 73 percent
    • Employee productivity: over 73 percent
    • Customer experience: over 71 percent
    • IT-related costs: over 71 percent
    • Speed-to-market: over 71 percent
    • Customer satisfaction (via NPS): over 70 percent
    • Time-to-decision: over 70 percent
    • Quality of development: over 70 percent
    • Employee retention: over 64 percent

    If increasing applications delivery speed and overall organizational velocity are, in fact, the primary goals of engaging agile and DevOps, the research bears out that the techniques are having the desired effect. After all, the survey finds that time-to-decision and speed-to-market are being accelerated among approximately a third of the organizations studied.

    Related to other notable KPIs, Coleman Parkes highlights that a full three-quarters of adopters have moved the needle on overall customer experience, along with employee recruitment and retention, a significant benefit that was also highlighted in the State of DevOps Report.

    Along with positively impacting customers, the reality is clearly that agile and DevOps are also making a big difference in allowing companies to improve the atmosphere for their workers—a huge benefit when you consider the shortage of talent in IT today, and how much it typically costs to attract new employees, just as DORA’s researchers noted.

    Other key findings by Coleman Parkes include “before and after” metrics that many organizations are observing related to their continued adoption and advancement of the involved methodologies themselves.

    I encourage you to download the entire report, and leverage it to measure how far you’ve come with Agile and DevOps transformation—and where you may need to re-examine your efforts.

    — Aruna Ravichandran

  • Forecasting Culture: Sunny with Accumulating Collaboration

    Forecasting Culture: Sunny with Accumulating Collaboration

    Bryson Koehler believes the most important enabling factor for DevOps success is culture.

    Koehler is CTO of IBM’s newly formed Watson and Cloud Platform group. Prior to this role, he served as executive vice president, distinguished engineer and CIO/CTO of The Weather Company (TWC), an IBM business since 2016. He has a record of successfully leading significant business transformations and underlying cultural transformations, which he maintains in tech companies must be incited first at the developer level. As such, while at TWC Koehler built a DevOps culture and practice that encourages transparency, accountability and collaboration, and it is his mission to replicate the successful model in the transformation of IBM’s culture.

    Since I experienced some of the TWC culture firsthand, I asked if he would be willing to share his thoughts on enabling a high-performing culture as well as maintaining that culture during periods of rapid growth or change.

    He started the interview with a theme clearly central to his core ideology as a transformational leader, and one of TWC’s key factors for success:

    Culturally, the goal is to find people who really love what they do. I want people to wake up in the morning and love what they do—not tolerate it, not like it, but love it. We work very hard to find people who love what we do and love the mission we are on. If you work very hard to assemble a team that loves what they do, the culture will take care of itself as long as you enable it … it’s about enabling them, with as much freedom and flexibility as possible, while still maintaining some level of consistency and control. It’s a balancing act and at TWC we worked very hard to give the right tools that enable people to work on any device, anywhere, at any time. The tools were an enabler; it was the culture that really invented itself based on the fact that we hired people who love what they do.

    Koehler’s commitment to finding the right people with the skills and passion consistent with his company’s mission put the base focus of enabling DevOps practices where it needs to be—with the people.

    For those that have read some of my other blogs, one of the things I’ve written about before is the mistake of choosing tools without first addressing the critical underlying aspects of DevOps including, a solid agile foundation and the cultural changes required to facilitate DevOps practices. Needless to say, Koehler’s comments about tools being an enabler really resonated with me because it was clear he still views the tooling as very important but puts the real emphasis on having the right people. The other key message that really resonated with me during the interview was his commitment to accountability and transparency:

    … from a leadership perspective, it’s around making sure there is clear accountability. There is single-person accountability for work. If you walk into a meeting and you don’t know who the single decision maker is in the meeting, my recommendation to the team is to leave. Don’t have the meeting, because it’s a waste of time. There should be one person that everyone knows is the decision maker, whatever the topic. If we don’t know that, then it’s my job to make sure I make that crystal clear. You can’t walk into a meeting with five people all thinking they own the decision when also working to create a culture with high velocity, high throughput and high passion towards meeting objectives and getting stuff done. You hire people who love what they do, you enable them with great tools, you have crystal-clear accountability and decision-making so that things can get decided quickly and that we know who is accountable for making sure that decision was successful, and then constantly work against the goals of the business. You also have to be very willing to adjust your tools, very willing to adjust your people, and very willing to adjust your decision-making. We must be constantly willing to look at ourselves and figure out how we improve.

    Koehler’s willingness to continuously look inward and adjust what is not working demonstrates another key success factor for high-performing DevOps teams. Having an executive driving that culture of continuous improvement is critical for DevOps success.

    He also is dedicated to core agile principles that allow for flexibility and responsiveness while maintaining some degree of focus and clear prioritization. With the rapid TWC growth, we also discussed how he maintained and adapted the existing culture in response to that growth:

    It’s really critical for me as a leader to stay very in tune with how these teams work and function, calling out any bad behavior and correcting it quickly. I’m just as willing to roll up my sleeves and get dirty as the next guy, and I expect everyone else to do the same. Kingdom building is not something that will get you very far in how we work. If you do that [roll up your sleeves], then as part of your culture, everyone puts down their guard and realizes that nobody is any more or less important than anyone else. We are all here to accomplish the same thing.

    Common goals and people that love what they do! It’s a great mix and Koehler has some fascinating perspectives on driving cultural transformation in support of DevOps practices, not only for the efforts he successfully led at TWC but for the efforts he will continue to lead within IBM. His commitment to culture can best be wrapped up by one of his final comments:

    None of our great technical ideas has any chance of seeing the light of day if we don’t get the culture right.

    Thank you again to @brysonkoehler for the interview and insight into TWC’s amazing culture and your vision for IBM!

    About the Author / Bryson Koehler and Shelbee Smith-Eigenbrode

    Bryson Koehler is CTO, IBM Watson & IBM Cloud – GM & Distinguished Engineer at IBM Connect with Bryson on LinkedIn and Twitter

     

    Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM and has been in IT for 19 years.  She has worked across varying roles spanning the software development lifecycle.  Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices.  She is a member of the IBM Academy of Technology as well as an IBM Master Inventor committed to driving innovation and technical advancement. Connect with me on Twitter @Shelbee_SE.

     

     

  • Are You Paying a ‘Wait-Time Tax’ on Your Global DevOps?

    Are You Paying a ‘Wait-Time Tax’ on Your Global DevOps?

    Business increasingly is global, so DevOps has become global as well. In fact, for many enterprises, DevOps entails collaboration between development, test/QA and ops teams across multiple continents.

    This is in part due to the economics of IT labor and in part because applications for global enterprises have to be deployed globally.

    Unfortunately, enterprises executing DevOps globally must confront the physical realities of global code distribution. And those physical realities impose a “wait-time tax” that fatally undermines Agile processes and culture.

    But they don’t have to. There’s a tax-free way to share large volumes of code across globally dispersed DevOps teams.

    The Wait of the World

    Every time you ship a massive build worldwide, you have to wait. Assume, for example, that you’re sending a 10GB build to five different locations over a 10Mbps MPLS connection. If a couple of your remote locations have 5Mbps connections, it will take them five hours to get each build. But if you have three locations with only 2Mbps connections (as is likely the case in Asia), they will have to wait 12.5 hours.

    That wasn’t a problem when you iterated your builds with limited frequency. But as you try to become more aggressive about highly iterative Agile development and testing, this “time tax” becomes punishing.

    For one thing, you lose productivity as your overseas developers and test teams wait idly for new artifacts. And these chronic wait times fundamentally undermine the Agile culture you’re trying so hard to build across your organization.

    In fact, if your current model for distributing code globally remains as-is, you’ll never achieve the speed and iterative frequency your business needs. And you’ll certainly never come anywhere close to continuous delivery.

    Faster Cycles from Dublin to Dubai

    Fortunately, you can eliminate DevOps wait times, regardless of how globally dispersed your teams are and how thin their connections to your enterprise network may be.

    The solution entails a hub-and-spoke model that:

    • Lets you maintain a “gold copy” of your current codebase(s) in the cloud;
    • Provides all your remote locations with their own local codebase copies that get continuously and automatically updated with any incremental changes as they occur; and
    • Leverages each location’s high-throughput internet connection.

    The combination of small, incremental code updates and high internet bandwidth dramatically changes the rules of the global DevOps game, allowing even the most geographically dispersed teams to work with even the largest codebases extremely iteratively and without delay.

    It’s difficult enough to sync dev and test teams on different continents. And the pressures on your organization to respond immediately to ever-changing market and regulatory demands will only intensify. So now’s the time to consider abandoning your obsolete approach to global code distribution and adopt a model that better enables you to be fast, super-iterative and global.

    — Barry Phillips

  • Assembling the Key Components of Continuous Delivery

    Assembling the Key Components of Continuous Delivery

    As agile methodology was popularized at the start of last decade, engineering teams gained the opportunity to begin producing software in shorter cycles, while releasing it reliably at more frequent intervals.

    This concept garnered greater attention in 2009, when Tim Fitz published his thoughts on continuous deployment. By the time Jez Humble authored his seminal book, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation,” in 2010, the approach started to get significant mindshare. In the book, Humble advanced the three building blocks of continuous delivery: configuration management, continuous integration and continuous testing.

    Thereafter, Agile Operations—the practice of using end-to-end monitoring, fueled by analytics, to increase operational agility—appeared. This complemented continuous delivery, with the goal of increasing the quality and velocity of software delivery while minimizing overhead.

    Since then, and particularly over the last six years as DevOps adoption has exploded, there’s been significant discussion (and confusion) over the opportunity to embrace “continuous everything” across the software development life cycle (SDLC) to deliver functionality continuously and optimize end-user experience.

    Today, having spoken to hundreds of organizations employing agile and DevOps, it’s possible to expand on these concepts to better define the key components of continuous delivery.

    In this blog, I’ll detail the precepts of “CD” that CA’s customers recognize as critical in reducing the time, risk and expense of software delivery by frequently releasing smaller batches of code with extensive visibility and traceability.

    These building blocks of continuous delivery are:

    • Continuous development & integration,
    • Continuous testing. and
    • Continuous release.

    Continuous Development and Integration

    When it comes to delivering quality apps faster, every second counts.

    That’s why it’s important to automate the planning, development, unit testing and integration of code with different inter-dependent components, all while packaging it for quality assurance. We categorize these activities under continuous development and integration, as shown in Fig 1.

    This all starts with sprint planning and modeling of requirements in agile management software. Unit tests can be created automatically, based on requirements and use case stories. These unit tests then can be executed automatically based on pre-defined criterion, using automatically generated synthetic data.

    Fig 1: Continuous Development and Integration

    Next, virtual service interfaces can be generated automatically by simulating unavailable systems across the SDLC, allowing developers, testers, integration and performance monitoring teams to work in parallel—driving faster delivery, along with higher quality and reliability.

    The integrated code can be built and tested automatically against validation criterion, and upon passing, made available for continuous testing. This later phase, after code development and before QA, is also commonly referred to as continuous integration.

    Continuous Testing

    Continuous testing across app delivery not only enables enterprises to shift testing left, engaging it earlier in the SDLC, but it also helps them shift right, leveraging the same processes throughout staging and production.

    After the unit tests are passed and integrated builds are made available for QA, functional and performance tests can be completed—before the build is made available for staging and production. Various activities during continuous testing are shown in Fig 2.

    Before the functional and performance tests are performed, the build promotion criterion and configuration also need to be validated. Testers require provisioning of QA environments to deploy the build, along with virtual services and test data. Using test data management to create a subset of production data and mask sensitive information is another continuous testing requirement.

    Fig 2: Continuous Testing

    It’s also important to engage application performance monitoring in the QA environment before running automated tests, providing feedback about any problems back to developers.

    After the automated tests are executed and promotion criterion are met, the build is ready for deployment in staging or production environments.

    Continuous Release

    Continuous release matches release velocity to development velocity through controlled and scalable deployments.

    The goal of continuous release (sometimes referred to as continuous deployment) is to continually and automatically deploy the build into production; similar activities also can be performed in a staging environment.

    As shown in Fig 3, build configuration needs to be validated, with the production environment configuration updated before being sent to production. As with application code, configuration is also maintained in the version control system and can be automated for deployment.

    Fig 3: Continuous Release

    After the build is deployed into production, application monitoring should be initiated to track performance and customer experience. Feedback from the production environment can be passed back to developers to guide enhancements or sprint backlogs.

    This blog aims to outline core CD activities, and in subsequent articles I’ll provide additional details on entry and exit criterion, as well as metrics useful in tracking continuous development & integration, continuous testing and continuous release.

    In the meantime, check out, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory,” a new book authored by my colleagues Aruna Ravichandran, Kieran Taylor and Pete Waterhouse.

    Based on learnings gained from numerous customers who have already embraced CD and DevOps, it highlights key practices for starting this journey, related ROI metrics and other useful tips.

    — Anand Akela

  • Don’t Cancel the Retrospective

    Don’t Cancel the Retrospective

    Not too long ago, I noticed a lot of teams rescheduling or cancelling retrospectives. Sometimes it was because key people were going to be out of office. Sometimes it was because a major deliverable was due and everyone was crazy stressed. Sometimes it was because the project wasn’t as far along as they thought it would be, and they wanted to wait for more data. In each case, the retrospective was cancelled only because of something deemed completely logical and understandable.

    But it bothered me a lot.

    I turned to the internet to back me up—to give me some context as to why retros never should be moved or cancelled that I could then send out triumphantly to our teams—but instead I found a dearth of thinking on retro cadence and scheduling. Denied the collective wisdom of the internet, I was forced to look inward to better understand why these scheduling changes bothered me so much. Is it just that I’m a compulsive rule follower who can’t handle change? That’s always a possibility worth examining. Were there things I wanted out of these retrospectives and was annoyed to have delayed? Not exactly, since I wasn’t actually participating in any of them, but that was a bit closer to the reason.

    As a manager, one of the things I read over and over is to never cancel a one-on-one meeting with a direct report. If you have to reschedule, it should be as close as possible to the original time. Rescheduling and cancelling one-on-ones is a sign to your reports that spending time with them is not important to you, and should be avoided if you actually respect your colleagues.

    The retrospective feels the same way to me. The person who reschedules it is probably a product manager or a tech lead, dutifully reviewing the schedule for the team and realizing there might be a problem. He or she invariably sends a message to the effect of, “Hey guys, this seems like a really bad time—anyone mind if we move it to next week?”

    Which of you would raise your hand and say it’s not OK? I’m a pretty forceful person, and I’m not sure I would. It’s a tall order to demand the time of the whole team.

    So, what’s the big deal about retrospectives anyway? Are we all beholden to the Agile Manifesto, following the pattern just because it says to? I really hope not, and I can say from my experience some of the best innovations on my team have come from retros. To me, a retrospective is like a one-on-one for the whole team, and can serve the same purpose.

    These are my favorite things about the retrospective format:

    • Enforced thinking time. We all spend our days running at top speed, and taking 15 minutes at the start of a meeting just to think about a topic is incredibly valuable. Taking time before the meeting would be even more impactful, but, baby steps.
    • Individual contributions. The format encourages every single member to contribute to the discussion. The mix of written and verbal discussion affords avenues for people with different communication styles to all have their feedback heard.
    • Venting. In the same way that sometimes a one-on-one needs to be a blow-off-steam session, group venting in a retro can be cathartic—and much healthier than silent stewing.
    • Pulse-taking. Teams are most healthy when every member has things to say, positive or negative, and is willing to discuss them out loud with the group.

    While it’s helpful to understand why retrospectives are so vital for the health of your team, it still doesn’t explain why it’s such a big deal to reschedule. Well, maybe it isn’t. You are not likely to get great thoughtful ideas out of people who are stressed out and are staring at their laptops the entire time. On the other hand, if it happens a lot, it can send a message that the team doesn’t value retrospecting (and probably also is oversubscribed).

    I found that just reminding teams that retrospectives are a first-class calendar system was enough to effect positive change. When push came to shove, my team wasn’t deprioritizing retros, but we realized that we were actually just in a format rut, so we decided to try the sailboat retrospective. Pro tip: It’s more fun if you add pirates.

    About the Author/ Cat Miller

    catmillerCat Miller is senior software engineer at Flatiron Health. She received her Bachelor of Science degree in Mathematics and Master of Engineering degree in Computer Science, both from MIT. Connect with her on LinkedIn.

     

     

  • Mainframe Apps and the Long View of DevOps Strategy

    Mainframe Apps and the Long View of DevOps Strategy

    IT is constantly under intense short-term pressures. Line of business (LOB) executives demand a competitive advantage in digital customer engagement now. Marketing leaders demand better customer analytics now. Legal demands better audit reporting now.

    In fact, much of the investment that companies are making in Agile, DevOps and continuous delivery is due to the urgent, short-term demands of the business.

    But short-term actions alone are insufficient for business success. IT leaders must also strategically navigate the vagaries of the digital economy over the long term—or, as Wayne Gretzky’s father taught him, to “skate to where the puck is going to be.” Otherwise, today’s small wins inevitably will lead to tomorrow’s egregious failures and inefficiencies.

    And integration of your mainframe apps and data into your enterprise DevOps tool chain is central to that long-term digital strategy.

    Here’s why.

    The Mainframe: Big, Nimble Iron

    A DevOps tool chain is only as fast as its slowest link. For most large enterprises, that slow link is the mainframe.

    Slow, waterfall-bound and underautomated mainframe dev/test processes are non-trivial—because mainframe applications and data are non-trivial. They typically are an organization’s most important apps and data. So if you can’t modify your mainframe application logic quickly or leverage your mainframe data in new ways easily, you’re uncompetitive toast in today’s fast-moving markets.

    Also, mainframe applications and data typically serve as the back-end systems of record for front-end mobile and web-based systems of engagement. Your ability to innovate and remain competitive when it comes to digital engagement and digital perceived value is, therefore, almost universally contingent on lessons learned from frequent and timely mainframe code drops.

    In other words, everything IT is under pressure to deliver—new mobile apps, better analytics, fulfillment of increasingly stringent compliance mandates, etc.—depends on bringing Agile, DevOps and (ultimately) continuous delivery to the mainframe.

    Just about everyone realizes this. Sure, there are some holdouts who still advocate something they call “bimodal IT”—which prescribes allowing the mainframe to languish in obsolete waterfall and dev/test practices while the rest of the enterprise moves forward. But bimodal lT has proven to be a mistake. An Oct. 31, 2016, Forrester Research report titled, “Predictions 2017: CIOs Push For Speed Amid Volatility,” shines a light on the fatal realities of bimodal IT:

    “In early 2016, many CIOs fell for the false promise of a bimodal strategy. They only pushed part of their team to adopt an accelerated pace — and left others unchanged. But those CIOs are already experiencing the shortcomings of operating at two speeds. Business peer frustration, polarizing and deteriorating cultures, and unsustainable operational complexities will continue, ultimately spurring most of these CIOs to course correct in 2017.”

    Given the explosion of mainframe-related innovation that has taken place in the past couple of years, enterprise IT leaders and industry analysts agree that “mainstreaming” it into enterprise DevOps is the right and necessary strategy (see as examples here and here).

    Some Good Things Take Time

    While instant gratification may be the order of the day—and gain without pain may be an all-too-frequent vendor promise—the reality is that great IT achievements all require effort, investment and time.

    Inclusion of the mainframe into your cross-platform DevOps tool chain is no exception. No CIO can achieve mainframe agility and cross-platform DevOps orchestration by simply waving a magic wand. But there is a clear, practical path to these goals for those with the requisite foresight and leadership.

    That path includes:

    • Modernizing the developer workspace. Most mainframe development is still performed in “green screen” TSO/ISPF environments that require specialized knowledge and limit staff productivity. A modernized, graphical workspace as part of a preferred DevOps tool chain will allow staff at all experience levels to perform dev/test tasks on both mainframe and non-mainframe applications.
    • Graphical visibility into existing code and data structures. Mainframe applications typically are large, complex and poorly documented. These attributes are a major impediment to mainframe transformation. The right tools enable new participants in mainframe DevOps to quickly and easily “read” existing application logic, program interdependencies and data relationships.
    • QA “shift left.” Early detection and correction of quality issues is a central principle of modern programming—and it’s particularly important on the mainframe, where there’s an especially low tolerance for error.
    • Initial Agile training and adoption. Once you put the right development environment in place, you can start shifting your process from a traditional waterfall model with large sets of requirements and long project timelines to a more incremental model that allows teams to quickly collaborate on user “stories” and “epics.”
    • Use operational data throughout the dev/test life cycle. By using operational data in the dev/test life cycle, your DevOps team can ensure that applications perform optimally in production. They also can significantly reduce your MIPS/MSU-related costs by avoiding excessive CPU consumption caused by inefficient code.
    • Agile-enable source code management (SCM) functions. Traditional mainframe SCM environments are inherently designed for waterfall development and thus are incapable of supporting Agile requirements such as parallel development on user stories. The shift to Agile-enabled SCM is, therefore, absolutely essential for mainframe transformation.
    • Automated release management. To keep pace with today’s fast-moving markets, you must be able to quickly get new code into production. That means automating and coordinating deployment of all related development artifacts across all targeted environments.
    • Cross-platform DevOps. Ultimately, you need to fully de-silo your enterprise environment so the mainframe becomes “just another platform”—albeit an especially scalable, reliable, high-performing, cost-efficient and secure one—that can be modified quickly as needed to meet the relentlessly evolving needs of the business.

    ‘What’s My Motivation?’

    With as much as IT departments have on their plates, it’s easy to continue putting off mainframe DevOps integration. But, ultimately, there are only two alternatives to doing so:

    • Re-platform your mainframe applications. This alternative has proven to be a costly and extremely risky undertaking that delivers zero benefits while it consumes resources and potentially disrupts IT operations, or
    • Continue doing nothing. This alternative puts your company at further competitive disadvantage and hastens the day when you’ll experience total mainframe paralysis due to the loss by attrition of all your veteran mainframe developers, QA specialists and operations staff.

    Viewed in this context, genuine investment in the mainframe—whether you call it modernization, mainstreaming or “Millennializing”—is the only reasonable course of action. Such investment starts improving your digital competitiveness immediately, while paving the way for a future where you can make the most of all your resources and confidently transfer platform responsibilities to your next generation of IT professionals. Including the mainframe in your broader DevOps efforts (while extremely valuable) does require commitment, and there are resources available to help. Just be wary of those who may talk a good game, but whose actions don’t really convey a strong commitment to users’ best interests. Fortunately, there are truly dedicated experts who can help every step of the way, and have direct experience modernizing on platform within their own organizations.

    It’s the smart, viable long-term DevOps strategy every CIO of a mainframe-enabled enterprise needs to adopt ASAP.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • To DevOps Or Not To DevOps

    To DevOps Or Not To DevOps

    Although enterprises today all claim to be software companies, there remain four distinct groups of organizations: the technology leaders, the technology followers, the technology hopefuls and the technology laggards.

    The first group are the industry leaders who are paving the way. These are the organizations coming up with new technologies, processes and cultural shifts. They write articles and books and present at conferences, and despite perhaps working at smaller companies, they are the names you may recognize. These are the companies the rest of us aspire to be—the Googles, the Amazons and the Microsofts that keep the rest of the industry hanging on to every word.

    The technology followers typically are smaller organizations that tend to adopt the latest and the greatest technologies. They are the leaders’ first wave of followers who are not afraid to try new things, nor afraid to fail. They have cultures that allow them to experiment and adapt and are given a lot of free time to invest in learning and implementation, after they watch the big guys successfully implement.

    However, the first two groups are the minority of software organizations, since not everyone can lead the way, nor can everyone have the luxury of spending a significant portion of their time experimenting with new methods. After all, most of the new technologies do not have a long lifespan. They appear, generate some attention and then disappear.  Front-end frameworks provide a great example of this: new ones pop up and exist for a few months before being superseded by other frameworks.

    Another example of technology followers is containers—few doubt their usefulness and most of us are convinced they are the best solution. The only question is which cluster orchestration framework to choose. These frameworks are evolving so rapidly, with new ones introduced on a weekly basis, that it’s almost certain most will be defunct within a year. So, if you are into experimenting with the latest offerings, chances are you could make a wrong choice. Will it be Kubernetes? Docker Swarm? Mesosphere Marathon? Rancher OS? Cloud Foundry’s Diego? CoreOS Fleet? The question is not whether to adopt one of those tools, but rather, which one has the best shelf life.

    Most of us fall under the third group, the technology hopefuls. We don’t have the ability to lead the way, nor do we have the luxury to explore the latest and greatest technologies. Yet, we cannot allow ourselves to become obsolete. The industry is moving so fast that just a few years can leave you at the back of the pack where no effort or investment can get you back in the game.

    The technology laggards are the software companies that have fallen behind. This group includes businesses that are struggling to remain intact and run the risk of disappearing. These are the organizations that do not innovate, do not adapt, do not invest (enough) in improvements and do not even understand the current industry trends. They are the organizations that do not comprehend that becoming obsolete doesn’t take decades, but years—sometimes even months.

    Based on the definitions of these groups, chances are, unless you are Google or Microsoft, you are not in the first or even second groups. By reading this article you are making the effort to be informed so you don’t lack the self-awareness that places you in the fourth group. Like most software organizations, you fall into the third group of technology hopefuls.

    As part of this group, you have to balance between the latest and the greatest technologies and the chance of becoming obsolete. You cannot try every new solution that comes along, nor you can let years pass by until you jump on the train. The big questions you have to ask are, How can I distinguish what will stay and what will disappear? How do I make a choice between what to adopt and what to ignore?

    There may not be a one-size-fits-all answer, but one process you absolutely cannot ignore is DevOps. If you’re asking yourself whether your organization should adopt DevOps, the answer is a resounding “yes.” And I encourage you to adopt it now, before you are replaced by other companies that are already living and breathing DevOps. Otherwise, you’ll be unable to adapt to the speed needed to keep up in today’s market and understand the cloud and scale accordingly when an avalanche of users come to your site after a successful marketing campaign. Lacking preparedness could cost you your business, especially in a competitive market.

    DevOps is here to stay, evolving similarly to Agile by providing value and answering many of today’s challenges. The only problem is that adopting DevOps can be difficult. To implement DevOps, you might have to change your company’s culture; you might need to adopt new tools; you might need to change processes; and, you might need to change your software architecture. Changing any of those aspects is hard, but changing all of them is very hard.

    Your culture and company structure need to be agile (in the literal meaning of the word). The old, monolithic tools need to be replaced with smaller, much more dynamic ones that will work well with the ever-changing nature of cloud infrastructure. Processes need to be automated, since there is no time to pause for manual intervention. To accommodate the needs of automation and frequent deployments, your applications and services will need to be relatively small for continuous delivery or deployment to become a standard process. Your teams need to be highly specialized and fully capable of working on all aspects of the software development life cycle, from requirements to post-production support.

    It’s a harsh and challenging road ahead, but at the end of it lies success. You’ll experience faster time to market, greater reliability, high availability and faster adaptability to market changes. Some are already there, while others already embarked on the journey. Don’t be left out—the alternative will leave you obsolete.

    To DevOps or not to DevOps is not the question. For most organizations, adopting DevOps is the answer.

    About the Author / Viktor Farcic

    viktorfarcicViktor Farcic is a Senior Consultant at CloudBees, a member of the Docker Captains group, and books author. He coded using a plethora of languages starting with Pascal (yes, he is old), Basic (before it got Visual prefix), ASP (before it got .Net suffix), C, C++, Perl, Python,ASP.Net, Visual Basic, C#, JavaScript, Java, Scala, etc. His big passions are Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD). He published “The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices,” and  “Test-Driven Java Development.” He is currently working on his third book, “The DevOps 2.1 Toolkit: Docker Swarm.” Connect with him on Twitter.