Tag: agile

  • CloudPassage Named “Most Innovative Cybersecurity Company”

    SAN FRANCISCO, CA–(Marketwired – May 05, 2016) –  CloudPassage today announced it has been recognized as the “Most Innovative Cybersecurity Company” in the 2016 Cybersecurity Excellence Awards, which are voted on by the more than 300,000 security professionals who participate in the LinkedIn Information Security Community. From nearly 200 cybersecurity vendors that were nominated, CloudPassage was selected as the winner of the mid-size company category, focused on the most innovative organization that has between 101 and 1,000 employees.

    “Enterprises are in the middle of a massive transformation of their IT infrastructure designed to let them move faster and stay competitive,” said Robert Thomas, CEO of CloudPassage. “Agile IT delivery models involve lots of automation, high rates of change, mixed environments and on-demand IT services. But traditional security tools don’t work with these modern IT environments. We’re winning recognition as a leader in the space because CloudPassage Halo is now a proven platform that enables this transformation.”

    CloudPassage Halo is an on-demand, security-as-a-service (SaaS) platform that deploys in minutes and automates a comprehensive set of security and compliance controls for servers in any combination of public cloud, private cloud or data center environments. The result is fast, effective security that solves problems of visibility, microsegmentation, compliance and speed of deployment.

    The 2016 Cybersecurity Excellence Awards honored individuals, products and companies that have demonstrated excellence, innovation and leadership in information security. Winners were selected based on the content of their nominations and the popular vote by the Information Security Community on LinkedIn, one of the largest online networks of cybersecurity professionals with over 300,000 members.

    As part of the company’s efforts to remain innovative, CloudPassage was recently awarded three patents that extend the scope of its original, agent-based, agile security model, making it the first company to obtain a U.S. patent for universal cloud infrastructure security.

    About CloudPassage

    CloudPassage® Halo® is the world’s leading agile security platform that provides instant visibility and continuous protection for servers in any combination of data centers, private clouds and public clouds. The Halo platform is delivered as a service, so it deploys in minutes and scales on-demand. Halo uses minimal system resources; so layered security can be deployed where it counts, right at every workload – servers, instances and containers. Leading enterprises like Citrix, Salesforce.com and Adobe use CloudPassage today to enhance their security and compliance posture, while at the same time enabling business agility. Headquartered in San Francisco, California, CloudPassage is backed by Benchmark Capital, Lightspeed Venture Partners, Meritech Capital Partners, Tenaya Capital, Shasta Ventures, Musea Ventures and other leading investors.

  • Does the Future of DevOps Lie in NoOps?

    Does the Future of DevOps Lie in NoOps?

    Why DevOps is more a bi-directional rather than a simple top-down approach

    DevOps is one of those buzzwords that nearly everyone wants to discuss these days. However, it often is interpreted as an extension of Development’s influence to the detriment of Operations teams.

    So much has changed in the past few years that it is conceivable we will see another major shakeup: Could Operations teams disappear altogether? Or to put it another way, is “NoOps” the future of IT? While DevOps promotes faster delivery of new digital services and a blurring of the lines between Dev and Ops, in reality, is Dev consuming Ops entirely?

    Before DevOps was called DevOps, the two disciplines were growing further apart. Agility has been driven by Developers since the turn of the century, with the famous Manifesto for Agile Development. Meanwhile, Operations formalized repositories of good practices into frameworks such as ITIL or COBIT, which were implemented by most large companies in the mid-90s. Those two approaches seem to oppose, as DevOps advocates the acceleration and multiplication of changes and ITIL tends to monitor and control them.

    NoOps, or the End of Operations?

    If you believe everything you read, then Operations is a dying art. But in practice, Development does not want to be involved with infrastructure, while few organizations would trust developers to manage their data centers, whether physical, virtual or cloud. So breathe easy: DevOps does not mean the end of Operations teams.

    On the contrary, Operations remains essential throughout the DevOps approach. Production infrastructure is a complex and delicate stack of technologies, often with a discreet mix of modern architecture and historical applications. It often is impossible for Development to replicate these types of environments. And that is why an application successfully tested in a qualification environment often does not work properly in production. However, it is crucial to validate new developments in a representative replica of the production environment.

    So is DevOps doomed to constant failure because of lack of continuity between qualification platforms and production systems? Well, this is probably the case if we merely consider DevOps as a simple top-down approach from Development to Operations. Focusing on producing changes at a higher frequency only shifts and grows a bottleneck that sits in production, without producing the added value expected by the company. As a consequence, DevOps must also be seen as a bottom-up process. In other words, if we consider DevOps, we must also take very serious look at “OpsDev” (OK, it doesn’t flow off the tongue, but you see my point!).

    DevOps or OpsDev?

    For a successful DevOps approach in practice, Development must position itself as a consumer of turnkey infrastructure environments. Operations then adopts an OpsDev approach and provides infrastructure on demand for all steps of continuous integration, from compilation to qualification, through unit testing.

    If DevOps is a radical change in how Development works, OpsDev would also revolutionizing common Operations practices. It comes with more agile “declarative” infrastructures (described and built from source code), an even more sophisticated level of automation and the ability to provide self-service infrastructure for developers.

    The adoption of DevOps does not mean that Operations will disappear or will be replaced by Development, but rather the emergence of bi-directional agility that needs to be supported by more sophisticated automation. In fact, DevOps implies OpsDev rather than NoOps. Finally, whatever you consider your release process under the ITIL or DevOps angle, isn’t the end goal exactly the same: delivering zero-default service to customers?

  • DevOps Chat: Software Lifecycle Management with Michael Azoff, Ovum

    DevOps Chat: Software Lifecycle Management with Michael Azoff, Ovum

    I had a chance to sit down with Michael Azoff, principal analyst for Ovum. Ovum just released a set of matrices that Michael was the author of on ALM, DevOps release management and one on Agile project management. Taken together they provide some great insight into the entire software lifecycle management space.

    I had a chance to view the reports before speaking with Michael and you can too courtesy of IBM. Here are the links:

    1. Ovum Decision Matrix: Selecting a DevOps Release Management Solution, 2016-17
    2. Ovum Decision Matrix: Selecting an Application Lifecycle Management Solution, 2016-17
    3. Ovum Decision Matrix: Selecting an Agile Project Management Solution, 2016-17

    Here is my conversation with Michael. Below is a transcript so you can follow along if you like as well.

    Here is the transcript of our conversation:

    Alan Shimel:                Hi, this is Alan Shimel of devopsy.kinsta.cloud.  Very happy to be joined today by Michael Azoff, principal analyst at Ovum.  Michael, welcome to DevOps Chats.

    Michael Azoff:             Thank you very much, Alan.  Pleased to be here.

    Alan Shimel:                Thank you.  Michael, you – well, Ovum, but you as the author, just published several Ovum decision matrices – I guess plural of “matrix” – in the last day or two, one of which was on DevOps, Agile, et cetera.  For our audience who may not be familiar with the Ovum decision matrix, can you explain kind of what they are, who the audience is, what they’re about?

    Michael Azoff:             Sure.  Yeah, absolutely.  So the Ovum decision matrix is Ovum’s product comparison methodology, where we compare products side by side, across three dimensions – one is the technology; the other is enterprise fit; and then we use the matrixes – the result is displayed as a bubble chart, so the size of the bubble is the marketing, so those are the three dimensions.  And I cover the software lifecycle management at Ovum, and we published three Ovum decision matrices covering the whole life cycle, so one was on application lifecycle management, one was on Agile project management, and the other, DevOps release management.

    Alan Shimel:                Fantastic –

    Michael Azoff:             The ALM – sorry, do you wanna ask a question?

    Alan Shimel:                No, no, I said that’s fantastic.

    Michael Azoff:             Yeah.  It’s not common for us to – for one analyst to do three at the same time – I think I’m the first to do that – but it made logical sense because I’m covering the lifecycle from end to end.  The ALM one we’ve been – we’ve had a cycle of these decision matrices for many years, but this is the first one that spans not just enterprise IT but also engineering manufacturing, where, because of the exponential rise of software content in advanced products, there is a very, very clear need for managing that complexity and a role for ALM.  So this covered, for the first time, the engineering side as well.

    The Agile project management was then a subset of the ALM one and focused purely on enterprise IT, so that’s the original scope for ALM.  Calling it “Agile project management” because it’s very much about the management at a high level, and then using – typically, organizations use a lot of open source tools for code development, so that made logical sense to name it in that fashion, with Agile being now so typical and common, but many of these solutions are generic and allow any kind of process to, from traditional stage-gates through to Agile, allow that coverage.

    And then DevOps release management, which has been around for some time – I think the first report where we looked at products was in 2010, but, this year, we’re seeing the topic has become really, really hot, and it was timely to do an Ovum decision matrix – in fact, the first proper decision matrix on solutions in that sphere.

    Alan Shimel:                Got it.  Let’s talk about some of the companies and what – well, before we do that, Michael, can you give our listeners a little insight into how this was conducted?

    Michael Azoff:             Sure.  So the original matrix terminology, I think, stemmed from the fact that we send the vendors – we invite vendors to participate.  We send them project criteria.  If they fit the criteria, then they’re in.  It’s, essentially, we’re looking at the top players in the market.  I also tend to invite some of the more interesting and innovative smaller companies to participate as well because I think that that’s of interest to the readers.  But, generally, it is the top market leaders who are participants.  So we send them a spreadsheet and that’s their sort of matrix.  It’s – has the 200 to 400, which we’re actually trying to reduce the number of questions, rows, that we have in the matrix, but the vendors fill these out.  We then have a briefing with the vendors.  We have a demo of their product, and we also delve into their marketing approach and we look at their financial numbers.  We look at their approach to customer service.  So it’s very in depth, it’s multi-dimensional, as I mentioned, and, on that basis, we then produce the decision matrix bubble chart.

    Alan Shimel:                Got it.  I don’t know if we wanna name names, Michael, but let’s take the DevOps matrix, to start with.  What were – who – according to the matrix, what were some of the let’s call it “top performers” – is that a good term to use?

    Michael Azoff:             Yeah, it certainly is.  And I think of all the – I’ve been an analyst since 2003 and conducted these type of vendor product comparisons, and I would say this has been the most contentious and the most difficult to, of all of these exercises, in drawing vendors apart.  So I ended up with quite a number of leaders who looked very sort of in that leading category.  Oh, I can – I’ll try and do this alphabetically, so, let’s see, so CA, CloudBees, Automic, Clarive, Microsoft Electric Cloud, IBM, Serena – did I mention CA? –  XebiaLabs, so, yeah.

    Alan Shimel:                Sounds pretty comprehensive.

    Michael Azoff:             [Chuckles] There’re a lot of vendors.  They all did extraordinarily well.  It was very difficult to draw them apart, but they all have rather different approaches to the market, and this is what is sort of delved into in the actual ODM report, so I do encourage people to actually look at the report and read carefully as what – so that’s a strength, weaknesses, opportunities, and threats analysis, which goes into quite a lot of detail and really gives the flavor of each of these solutions, in that leading category.  And then we have some challenger solutions as well, yeah.

    Alan Shimel:                Got it.  And, Michael, I mean, certainly DevOps is on top of everyone’s list of hot topics or near the top of everyone’s list of hot topics.  You know, separating the hype from the reality here, just where’s the ceiling for these things?  I mean, do you see – what do you see down the road in short term – 12 months, 18 months, 24 months?

    Michael Azoff:             Well, we had the first wave of the innovation in this market with support for managing continuous delivery, so, at an open source level, there was activity.  There were vendor startups that provided their own continuous delivery solutions and then, on top of that, management and orchestration.  So all of that was happening around 2011, and the larger vendors made acquisitions.  I mean, IBM acquired UrbanCode; CA acquired Nolio; BMC, StreamStep.  So very much a sort of rationalization and an anticipation of the market.  But we’re still seeing new players come onto the scene, like Clarive, for example, is an interesting one and CloudBees, the open source project – owners of Jenkins have sort of stepped into the enterprise side and expanded their offering with an enterprise-ready release management solution – so still a lot of activity.  And I would say the next step in this market would be ALM and release management tying a lot closer, and I think, from a customer point of view, it would be a useful benefit to have a single ALM solution that included these advanced release management technology in there as well.

    Alan Shimel:                Yeah.  Absolutely.  Michael, where do you see – now one of the questions I always get is, with all due respect, right, these analysts do great reports, but they’re behind firewalls, they’re behind reg-walls.  One of the nice things about these Ovum matrices is I see IBM and some of the other vendors are making the matrices themselves available if you’re willing to fill out their registration form, and what I like about that is it gets this intelligence into the hands of people, whether you wanna take it slanted or whatever because you had to fill out a registration form – that’s up to you – but for people, Michael, who are saying, “How independent – how much stock do we put in these things?”  You’ve already given us a little background into the methodology behind the research, the wide spectrum of companies you’re covering, but talk about independence of Ovum and of your research here, so – I want people to understand that.

    Michael Azoff:             Yeah, absolutely.  So, as analysts, our credibility is our independence, so we’re not aligned with any vendor.  As an analyst firm, we face both ways – we do work for vendors, we work also with end-user customers, and we also provider solutions for vendors and for enterprise customers.  So we face both ways – we work with all parties – but our independence is our credibility in the market, so we take a completely objective view of the responses from the vendor.  And, sometimes, the vendors don’t like what they see, but they actually find it very useful to get a completely unjaundiced and independent view because it helps them understand exactly where they are in the market.

    I think the ALM one, in particular, was a bit of a shock for a number of vendors because of our re-scoping of how we look at ALM.  Some vendors completely ignore the engineering market, and we see that as one of the growth areas in ALM, so I think that caught out a number of vendors by surprise, despite the fact that we’ve been telling them they ought to look at that part of the market, for ALM.

    Alan Shimel:                Absolutely.  Michael, can you give our readers what’s next?  What other matrices related to these subjects or other kind of research might you guys be working on next?

    Michael Azoff:             Sure, sure.  So, personally, so my brief is the software development lifecycle management, and I cycle through three areas – ALM, mobile development platforms, and application performance management – despite the fact that the ALM one was a triplet, but it is, logically, the lifecycle, if you like.  So the next one in the cycle will be Q4 this year, and that’ll be on application performance management.

    Alan Shimel:                Great.  All right.  Michael, we’re just about out of time, unfortunately.  I apologize; maybe we can talk again another time.  It was great chatting with you and I hope our readers have learned something here that can help them.  And thank you for all the research you do – can never have enough information on this stuff.  Micheal Azoff, principal analyst at Ovum, thank you very much.

    Michael Azoff:             Thanks, Alan, for inviting me.

    Alan Shimel:                Thank you, and this is Alan Shimel for devopsy.kinsta.cloud.

  • VersionOne® Spring 2016 Release Helps Organizations Successfully Scale Agility with SAFe® and DevOps

    VersionOne Enables Program Boards, PI Planning, and WSJF Ranking to Align with the Scaled Agile Framework®

    Atlanta, GA (PRWEB) April 22, 2016

    VersionOne, the independent leader in agile lifecycle management, today announced its Spring 2016 Release to help organizations successfully scale agility with SAFe and DevOps. New features in VersionOne Lifecycle that directly support SAFe include: a new Program Board for coordinating across teams and visualizing cross-team dependencies; interactive, multi-team Program Increment (PI) Planning capabilities; and Weighted Shortest Job First (WSJF) Ranking. In addition, VersionOne Continuum™ for DevOps now includes the ability to view a graphical timeline of work item history and a visual depiction of the development, test, and stage phases of a DevOps product workflow.

    VersionOne’s Spring 2016 Release includes the following:

    • Program Board – Coordinate efforts and visualize cross-team dependencies at the portfolio item level across each iteration in a release. These visualizations help teams avoid risks and costly delays that often result from unforeseen dependencies with other teams.
    • PI Planning – Plan complex, multi-team releases on a single screen with flexible, interactive team assignment and context sensitive filtering of backlog items during large-scale planning sessions.
    • WSJF Ranking – Rank portfolio items, epics, features, and capabilities based on the cost of delay. The cost of delay algorithm is based on estimated business value, risk reduction, time criticality, and effort.
    • DeliveryStream – Give teams the ability to trigger pre-configured Continuum actions within Lifecycle work items.
    • Continuum Product Workflow – Define the workflow for any product that is defined in Continuum and visualize the development phases.
    • Continuum Work Item History Visualization – See a visual representation of all the steps and automation a particular work item has participated in, all in a single place.
    • ALM Connect™ – Connect VersionOne to the world’s most popular application lifecycle management (ALM) systems and manage the integrations from one intuitive, web-based interface. ALM Connect ensures visibility and coordination across today’s complex development processes and heterogeneous environments.

    “While agile adoption continues to grow, ensuring successful large-scale agile implementations can be challenging without the right framework, solutions, and services,” said VersionOne CEO and Co-founder Robert Holler. “The Spring Release is further proof of our ongoing commitment to helping our customers successfully scale across the entire software delivery value stream.”

    Learn more about the VersionOne Spring 2016 Release.

    About VersionOne

    VersionOne is a recognized leader and visionary in agile lifecycle management software and services. Our mission is to help companies envision and deliver great software. Our promise is to promote and serve the best interests of the agile software development community with respect and humility. Every day, we work hard to make a difference in our community and with our customers.

    Today, more than 50,000 teams at 1,000 companies, including 33 of the Fortune 100, use our solutions to help scale their agile initiatives faster, easier, and smarter. Whether a small team just starting out with agile or a global enterprise scaling agile, VersionOne customers get the best solutions in the industry backed by the pioneers in agile lifecycle management. VersionOne has offices in Atlanta and in Amsterdam.

    VersionOne is a registered trademark and ALM Connect and Continuum are trademarks of VersionOne Inc. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

  • Submit your proposal for DevOps Enterprise Summit San Francisco!

    Submit your proposal for DevOps Enterprise Summit San Francisco!

    The theme for this year’s #DOES16 San Francisco conference is Leading Change.

    We want to hear stories from the leaders of large, complex organizations implementing DevOps principles and practices.

    The submission deadline is midnight PDT, May 2, 2016.

    All submissions will be notified by June 17, 2016.

    Get details >>>

    DevOps Enterprise Summit keynote

    DevOps Enterprise Summit

     

     

     

     

    DevOps Enterprise Summit

    DevOps Enterprise Summit

     

     

     

     

    This year’s programming will be based on a series of survey questions about the biggest issues IT professionals continue to work with. Several universal topics emerged, and we will be selecting talks that address them:

    People and Culture:  We’re interested in the strategies and methods you employed to successfully lead change and to enable DevOps outcomes in large organizations. How did your approach to leadership and organizational design differ from those used in more traditional IT organizations? How is the workforce different, both for employees as well as contractors and outsourcers? And what have been your results?

    Process and Technology: We are interested in the practices you have adopted to integrate change into your workforce and build on changing relationships with your vendors. What are modern architectural and technical practices that every technology leader needs to know about?

    Compliance and Security: We’re interested in concrete ways you have helped DevOps bridge the information security and compliance gap, showing auditors and regulators that effective controls exist to prevent, detect, and correct problems.
    Submit your proposal >>>

    For the full news release, click here.

    EARLY BIRD TICKETS ON SALE NOW!

    If you missed the Blind Bird tickets, don’t fret.

    We are offering a discounted Early Bird rate for  $1,450 (ends May 16). That’s a savings of more than 25% off the full-price ticket.

    We encourage you to act quickly as the past two years have sold out.

    Get tickets >>>

  • DevOps’ Cultural Myths and Logical Fallacies

    DevOps’ Cultural Myths and Logical Fallacies

    Remember that guy you knew in college who was working on his fifth or sixth degree with no plans to stop? At some point the idea of real work must have terrified him, and instead what appealed to him was a continual state of learning. If you have the funding to master five or six disciplines, and perhaps not the ambition to get going in any one of them, why not stay and explore the next one?

    But if you work in IT, chances are you did not stay in college for more than a few areas of study, and since you entered the work force, your future options dwindled down to two: become a specialist (deep thinking in a singular discipline, but not too broad) or become a generalist (broad thinking across multiple disciplines, not too deep in any one of them).

    Managers tend to start their careers as specialists who do so well they are promoted to manager, where their career shifts and they become generalists. From time to time they dabble in a particular area of study to speak the lingo, use the right buzz words and understand what is coming, but the role they play is inherently generalist, as they are forced to deal with a number of topics beyond the realm of any one particular area of study.

    We tend to associate the title “architect” as being the specialist who is deep in an area we are forced to contend with. Examples might include, “We need to hire a network architect, or a database architect, or a software architect …” the list continues. When we do this, we have certain expectations. We are looking for the “guru” who can solve our network problems or database problems or security problems—wherever the skill set was that caused us to hire this specialist. If our new employee cannot solve our problems, we begin the search for another who can solve them.

    But the candidate has expectations as well: The network guy may have a little knowledge about databases but does not expect to have to perform at the level of his peers in that discipline. If we hire a network guy and then ask him to do everything in every other discipline, we are the ones out of line and he will likely flee our employment in haste, calling us crazy on the way out.

    The Cultural ‘Frankenstein’

    To create a true master of the multiple disciplines that exist within IT would require creating a modern Frankenstein in networks, servers, operating systems, storage, database, middleware, software and mobility. And, of course, this list is not limited to one expression of each type, but indeed multiple expressions of each type. So for example, our database discipline likely includes deep expertise in Oracle, DB2, SQL Server, NoSQL, MySQL … you name it. If it is popular or relevant to our current stack, our Frankenstein must know that one.

    As DevOps has gained in popularity, we have conflated certain aspects of it and driven ourselves off the highway of logic. Too often, proponents have taken the concept of co-location from the agile beginnings of DevOps and applied it to the operational endings of DevOps. Taking down silos is mistakenly applied to co-locating IT operational staff. This conflation occurs billed as the panacea it once was to co-locating business staff, with the developers producing products for them. In the strictly agile context, this works well. Applying it to IT personnel on the back half of delivery is the least effective means of creating Frankensteins. Co-location is a good way to share ideas, from user back and forth to innovator. In general, sharing ideas between a network guy (with limited interests outside his discipline) and middleware guy (who could care less how the network is configured in detail) has limited success.

    These operational IT disciplines do interact, but only as they have need, which is significantly less than having to sit in the cube 4 feet away from a counterpart involved in a differing discipline. Co-location is not the cure for breaking down silos or increasing communication—common backbones are. Imagine the example of the medical profession: A hospital provides the common backbone for the neurosurgeon, the orthopedic surgeon and the heart surgeon. These disciplines are inherently separate, and if you have a particular illness, you are going to want the one who specializes in the thing you need done. While each doctor understands general health aspects, they specialize for a reason—a reason you want and need—when it is your time to seek help.

    The hospital provides the common facility, the common support staff, the common electronic systems and tools we use. Our medical records are stored in one place, no matter what type of treatment we seek, so each specialist has to enter them there and can read them there. But distinctions by practice remain. There is a special surgical floor for heart surgeries, where they do not conduct orthopedic work or neurosurgical work. The tools may be slightly different; the medical journals are. The training is different. The experience is different. And none of these skills transfer by osmosis of co-location if you put all three doctors in one central cubical cluster. It takes years to get where they are. The same is true of our IT specialists.

    If instead of co-location we looked more at common systems for moving, documenting and articulating change. If we gave limited access to our DevOps tooling to the specialists, confined to the niche they have expertise in, then instead of co-location we could have remote-work-concurrence. Experts from all over the country could work on the movement of change without ever physically seeing each other, but with full visibility into what is happening in real time through a common lens. Network operations center (NOC) personnel remain physically in the NOC, but can see the entire stack from that location and change only their portion as changes are required from there.

    It is the common backbone of DevOps systems that breaks down the silos of change transparency and change participation. Prior to DevOps we were all using different tools to move change and track change. With DevOps we can begin to articulate change and document it, in the same tool or interface. Meaningful access is granted only to the portions of tools and only where it is needed. Database guys have full access to that platform and nobody else does (other than to see it). The same model works for every other specialty. And before you know it, you have a concert—or rather a symphony of moving parts—instead of disjointed sounds no one can comprehend.

    Organizations that hold to the idea that staff will become Frankensteins, equipped with deep skills in all areas because they share cubicle clusters, would do better buying lotto tickets. Where the culture will require attention is in demonstrating to the impacted teams why participating in the common backbone approach has merit for each of them. For engineers who have never had to use “something different” before, this takes work, but is the real win.

    When complete, what has truly happened is a conversion to a culture of unity. The work of the genius is still protected in this method; in fact, it is amplified as now it is visible to the entire organization. So even the prima donnas should be happy with the approach. And the ability to orchestrate change never will have been so high, with so much real-time interaction, as after the embrace of a common backbone of DevOps systems. This should offer executives new insights into product creation and evolution. In this sense, the cultural changes reach from top to bottom of the organization, and they are achievable.

    To continue the conversation, feel free to contact me.

  • cPrime and AgileCraft Partner to Scale Agile with Atlassian’s Jira Suite

    Partnership enables organizations committed to Atlassian suite to scale agile across all levels of the enterprise – including team, program, portfolio and enterprise levels.

    Foster City, CA (PRWEB) March 31, 2016

    cPrime, the industry leader focused on solutions to help companies adopt, transform and scale their business with Agile Development methodologies and AgileCraft, the leading provider of enterprise agility platforms to simplify software at scale, have partnered to help companies drive business agility and transformation at scale.

    “Customers interested in scaling agile to the enterprise are rapidly adopting JIRA along with AgileCraft to align business and technology.” Said Zubin Irani, CEO of cPrime. “Our customers tell us that using AgileCraft with JIRA allows organizations to bridge the PPM / ALM gap in a modern and highly scalable way. The result for customers is better software – delivered on time and on budget – with clear visibility and trace-ability from start to finish.

    “Our business model is to embrace partners to drive the implementation and customization of our platform” said Steve Elliott, CEO of AgileCraft. “cPrime already deeply understands the needs of organizations scaling agile, and was looking for a tool to help solve the problem of true enterprise agility. cPrime has repeatedly worked with our team to deliver innovative solutions that accelerate the path to operational agility.”

    Built from the top-down to support agile at scale, the AgileCraft platform helps align entire organizations around common goals and objectives while providing actionable views and metrics to everyone touching the technology product lifecycle.

    To learn more about scaling agile to the with cPrime and AgileCraft on platforms like Jira register for a one-hour complimentary webcast featuring a product overview and technical deep dive to be held on May 10, 2016.

    About cPrime Inc.

    cPrime enhances the full lifecycle of product development with comprehensive solutions for adopting and scaling Agile methodologies and software. Hardware, DevOps, JIRA, cPrime covers it all. The alignment of  people, processes and technology solutions build and optimize a lasting framework for client growth. cPrime works with the most notable enterprises; providing training, consulting, and team augmentations to help organizations adopt and scale Agile methodologies. Additionally, cPrime deploys and optimizes the software used to support client’s unique processes. The cPrime solution sets span the full application lifecycle management pipeline to ensure quick and quality product delivery.

    About AgileCraft

    AgileCraft® delivers the most comprehensive software solution available for scaling agile to the enterprise. AgileCraft transforms the way organizations enable and manage agile productivity across their enterprise, portfolios, programs and teams by aligning business strategy with technical execution. The AgileCraft platform combines sophisticated planning, analysis, forecasting and visualization with robust, multi-level collaboration and management. Designed to be open, the AgileCraft platform compliments and extends existing agile tools, methods and processes and can be deployed through the cloud or on premise. AgileCraft customers get the best agile solution on the market and benefit from a platform that is specifically designed to scale enterprise wide. For more information, please visit http://www.agilecraft.com.

  • Databricks Offers APIs to Enable Agile Application Development With Apache Spark for the Enterprise

    Fusion of API and Visualization Meets Application Deployment and Data Science Needs

    SAN FRANCISCO, CA–(Marketwired – Mar 30, 2016) – Databricks, the company behind Apache Spark, today launched a new set of APIs that will enable enterprises to automate their Spark infrastructure to accelerate the deployment of production data-driven applications.

    Today’s enterprise data platform must satisfy the disparate needs of multiple constituents as they work together to deploy production data-driven applications. While developers and DevOps teams operate in command line and APIs to automate infrastructure, data scientists demand a visual environment to create algorithms. Without a unified platform, enterprises suffer from a sprawl of tools, leading to long application development cycles and high IT infrastructure complexity. With the addition of secure APIs to an integrated workspace, Databricks natively supports this full spectrum of enterprise needs in one platform — a capability not yet available anywhere else.

    Databricks users will now have the ability to implement Agile Development best practices, such as continuous integration, in tandem with performing real-time data analysis and visualization. Added benefits to enterprises include:

    • Faster release cycles of Spark applications;
    • Higher reliability in Spark infrastructure deployments;
    • Improved oversight and management of Apache Spark infrastructure expense in the cloud.

    “Agile data-driven application development requires data scientists to work in perfect sync with DevOps, but these teams lack a unified platform to connect their separate workflows,” said Ali Ghodsi, CEO of Databricks. “The addition of Databricks APIs will enable these constituents to work seamlessly in one platform, allowing them to act on hidden insights from their data and create unique competitive advantages for the business.”

    “The APIs provided by Databricks combined with its integrated workspace and security framework has allowed us to release our applications twice as often as before,” said Doug Stein, chief technology officer at Metacog. “Instead of waiting for multiple weeks to incorporate improvements into our product, we are now able to do so every week.”

    The new APIs are available today to all Databricks customers. To sign up for Databricks, visit www.databricks.com or contactsales@databricks.com.

    About Databricks:
    Databricks’ vision is to make big data simple for the enterprise. The company was founded by the team that created and continues to drive Apache Spark, a powerful open source data processing engine built for sophisticated analytics, ease of use, and speed. Databricks is the largest contributor to the open source Spark project providing 10x more code than any other company. The company has also trained over 20,000 users on Apache Spark, and has the largest number of customers deploying Spark to date. Databricks is venture-backed by Andreessen Horowitz and NEA. For more information, contact info@databricks.com.

    CONTACT INFORMATION

  • 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

  • Evolving to Continuous Testing

    Evolving to Continuous Testing

    As agile development practices mature and DevOps principles infiltrate our corporate cultures, organizations are realizing the distinct opportunity to accelerate software delivery. However, when you speed up any process, immature practice areas such as testing and roadblocks become much more pronounced. It’s the difference between driving over a speed bump at 5 mph vs. 50 mph … at 50 mph, that speed bump is going to be quite jarring.

    Accelerating any business process will expose systemic constraints that shackle the entire organization to its slowest moving component. In the case of the accelerated software development life cycle (SDLC), testing has become the most significant barrier to taking full advantage of more iterative approaches to software development. For organizations to leverage these transformative development strategies, they must shift from test automation to continuous testing.

    Drawing a distinction between test automation and continuous testing may seem like an exercise in semantics, but the gap between automating functional tests and executing a continuous testing process is substantial. This gap will be bridged over time as the process of delivering software matures. Both internal and external influences will drive the evolution of continuous testing. Internally, agile, DevOps and lean process initiatives will be the main drivers that generate the demand for change. Externally, the expense and overhead of auditing government and industry-based compliance programs will be the primary impetus for change.

    A Roadmap for Testing

    Any true change initiative requires the alignment of people, process and technology—with technology being an enabler and not the silver bullet. Yet there are some basic technology themes we must explore as we migrate to a true quality assurance process. In general, we must shift from a sole focus on test automation to automating the process of measuring risk. To begin this journey, we must consider the following:

    Driven by business objectives, organizations must shift to more automated methods of quality assurance and away from the tactical task of testing software from the bottom up.
    graphic

    From Causal Observations to Probabilistic Risk Assessment

    With quality assurance (QA) traditionally executing manual or automated tests, the feedback from the testing effort is focused on the event of a test passing or failing—this is not enough. Tests are causal, meaning that tests are constructed to validate a very specific scope of functionality and are evaluated as isolated data points. Although these standalone data points are critical, we must also use them as inputs to an expanded equation for statistically identifying application hot spots.

    The SDLC produces a significant amount of data that is rather simple to correlate. Monitoring process patterns can produce very actionable results. For example, a code review should be triggered if an application component experiences all of the following issues in a given continuous integration build:

    • Regression failures greater than the average
    • Static analysis defect density greater than the average
    • Cyclomatic complexity greater than a prescribed threshold

    From Defect Documentation to Simulated Replay

    The ping-pong between testers and developers over the reproducibility of a reported defect has become legendary. It’s harder to return a defect to development than it is to send back an entrée from a world-renowned chef. Given the aggressive goal to accelerate software release cycles, most organizations will save a significant amount of time by just eliminating this back and forth.

    By leveraging Service Virtualization for simulating a test environment and/or virtual machine record and playback technologies for observing how a program executed, testers should be able to ship development a very specific test and environment instance in a simple containerized package. This package should isolate a defect by encapsulating it with a test, as well as give developers the framework required to verify the fix.

    From Structured Data to Structured and Unstructured

    The current tools and infrastructure systems used to manage the SDLC have made significant improvements in the generation and integration of structured data (e.g., how CI engines import and present test results). This data is valuable and must be leveraged much more effectively (as we stated above in the “From Causal Observations to Probabilistic” section.

    The wealth of unstructured quality data scattered across both internal and publicly-accessible applications often holds the secrets that make the difference between happy end users and unhappy prospects using a competitor’s product. For example, developers of a mobile application would want constant feedback on trends from end user comments on:

    • iTunes app store
    • Android app store
    • Stackoverflow
    • Twitter
    • Facebook
    • The company’s release announcements
    • Competitors’ release announcements

    This data is considered unstructured since the critical findings are not presented in a canonical format: parsing and secondary analysis are required to extract the valuable information. Although these inputs might be monitored by product marketers or managers, providing these data points directly to development and testing teams—in terms that practitioners can take action on—is imperative.

    From Dashboards to Business Policies

    In a Continuous Everything world, quality gates will enable a release candidate to be promoted through the delivery pipeline. Anything that requires human validation clogs the pipeline. Dashboards require human interpretation—delaying the process.

    Dashboards are very convenient for aggregating data, providing historical perspectives on repetitive data, and visualizing information. However, they are too cumbersome for real-time decision making because they do not offer actionable intelligence.

    Business policies help organizations evolve from dashboards to automated decision making. By defining and automatically monitoring policies that determine whether the release candidate is satisfying business expectations, quality gates will stop high-risk candidates from reaching the end user. This is key for mitigating the risks inherent in rapid and fully-automated delivery processes such as Continuous Delivery.

    From Tool Dependent to SDLC Sensors

    Let’s face it—it’s cheap to run tools. And with the availability of process intelligence engines, the more data observations we can collect across the SDLC, the more opportunities will emerge to discover defect prevention patterns.

    Given the benefit of a large and diverse tool set, we need to shift focus from depending on a single “suite” of tools from a specific vendor (with a specific set of strengths and weaknesses) to having a broad array of SDLC sensors scattered across the software development life cycle. And to optimize both the accuracy and value of these sensors, it’s critical to stop allowing tools to be applied in the ad hoc manner that is still extremely common today. Rather, we need to ensure they are applied consistently and that their observations are funneled into a process intelligence engine, where they can be correlated with other observations across tools, across test runs and over time. This will not only increase the likelihood of identifying application hot spots, but will also decrease the risk of false negatives.

    About the Author/Wayne Ariola

    Wayne Ariola (1)Wayne Ariola, Chief Strategy Officer, leads the development and execution of Parasoft’s long-term strategy. He leverages customer input and fosters partnerships with industry leaders to ensure that Parasoft solutions continuously evolve to support the ever-changing complexities of real-world business processes and systems. Ariola has contributed to the design of core Parasoft technologies and has been awarded several patents for his inventions. A recognized leader on topics such as service virtualization, SOA and API quality, quality policy governance, and application security, Ariola is a frequent contributor to publications including software test & performance, SOA World, and ebizQ—as well as a sought-after speaker at key industry events. Ariola brings more than 20 years strategic consulting experience within the technology and software development industries.