devopsy.kinsta.cloud

Category: Blogs

The Docker whale swallows another one, Kitematic

Docker announced another acquisition yesterday, the 2^nd one in the last two weeks. This time they have swallowed up Kitematic, a Canadian open source project that makes it setting up Docker on a Mac really easy, Like up and running in 5 minutes easy.

I know some of you may be asking yourself, “I am not going to deploy Docker on my Mac, I only use Mac for my laptop.” Why would Docker spend money or more probably some of their valuable stock, buying an open source tool that lets users run Docker on Mac computers, not servers, not in the cloud. But Kitematic’s popularity is with developers who like the convenience of setting up Docker containers quickly on their laptops so they can develop, test and experiment on the fly. That is Dockers customer base right now.

It is a great little tuck in that gives Docker a good tool that will make their developer supporters happy as they develop apps in Docker containers. I spoke to the Docker folks about this acquisition and they tell me the 3 people behind Kitematic are already on their way to San Francisco to join the team.

The fact that Kitematic uses one of the recently released Docker Orchestration tools is a nice bonus showing what can be accomplished using the Docker tools.

At the end of the day it really is a nice addition to the Docker toolset. It also continues a trend of Docker cherry picking the best of the tools that are popping out of the Docker ecosystem. It makes for a great, quick exit strategy for those folks developing tools for Docker. In the case of Kitematic it was really quick. The 3 founders are barely out of school themselves. But from Docker’s point of view, it makes sense. Buying them early usually means buying them cheap. Usually but not always.

Bigger picture I was more excited about Docker’s recent acquisition of SocketPlane. The company while short on actual code and product had a good roadmap on SDN type of functionality to allow multiple Docker containers to work in concert. There is still a lot of work to be done to make that a reality, but more than a tuck in, Socket Place is a key to Docker success going forward.

There is no doubt that Docker is a darling of the tech world and developers in particular. The issue is when are we going to see Docker move from people tinkering with it to see what is possible, to actual deployments in a big way. Yes there are some real world deployments of Docker. I am not saying there is not. But that is rather small potatoes compared to what the promise holds.

To fulfill that promise enterprises will need to deploy dozens if not hundreds of Docker containers across disparate clouds and infrastructures. These containers will have to communicate and act in concert. That is still probably a little while off, but that is the vision that will see Docker live up to the hype.

The only dark cloud (no pun intended) on the horizon if this type of functionality cannot be engineered in an elegant manner or more likely another container option comes to market with this type of functionality first. Not saying that is going to happen, but Docker buying up these companies at the pace they are inhibits competition from popping up as well.

In any event, we haven’t see the end of Docker acquistions. They will continue building the business by swallowing the best of the ecosystem that is growing around it. There is also a ton of activity on the partner front with IBM working with them on Enterprise Containers, Microsoft working on Azure. In fact I was told in my Docker briefing that Docker themselves are bringing Docker to Windows for Azure in a much faster timeline than even Microsoft.

Stay tuned for more on Docker and containers the rest of this month on devopsy.kinsta.cloud.

March 12, 2015
The right answer was “process”
The question is “why is there no one-size-fits-all automation and orchestration solution”?

Automation, a component critical for continuous deployment particularly as it extends beyond app operations and into the broader environment to encompass network and security operations, too, continues to be a custom build kind of thing. There’s no single automation tool, framework or pattern that can be generally applied to a significant number of environments. Mi casa es no su casa, after all. That’s because environments don’t actually look like power point slides; your environment is not the simplistically diagrammed firewall –> load balancer –> web server typically found in decks extolling the virtue of one solution over another. They are far more complex, comprising not just multiple tiers of interdependent and interconnected apps and services, but multiple chains of infrastructure services spanning the gamut of security, availability, mobility, performance and access control. The specific flow through and between these services is unique. Indeed, the intimate relationship between network latency and app performance is well known, and thus the navigation through the critical yet complex site of services required to deliver an application could easily be considered a competitive advantage if it’s able to keep performance under the 5 second toleration limit on response time apparently now the standard for consumer satisfaction.

So it’s no surprise that automation and orchestration, responsible for automatically setting up the triggers and routes required for application traffic to correctly traverse the right set of services for optimal performance, would not be a simple, turn-key solution. One size does fit all. It must, like its business process focused counterpart – BPM – be customizable and easily changeable.

BPM? Are you seriously?

I’m dead seriously. BPM – business process management – has been around far longer than automation and orchestration of IT systems and its focus is, as its name implies, on process. Automation is included, but it is the orchestration of business processes that often change in the face of variable business conditions that makes it an invaluable tool for optimizing business and a source of competitive advantage. “The ability to change quickly is essential. Businesses change their key processes 4-7 times per year. The driver for change can be internal or external. New opportunities can arise. New partners or customers need you to support a different way of doing business. Federal or international regulations can require you to change your processes.” (Making the Case for BPM, Jim Rudden)

Consider for a moment this data from a 2012 Bearing Point survey on the goals and impact on culture:

Top BPM goals are increased efficiency (93%), increased transparency (90%) and the realization of standardization potentials (85%). A number of BPM goals have an impact on corporate culture, e.g. increased transparency (rank 2), increased customer orientation (rank 5), disclosure of weaknesses/ bottlenecks (rank 6) and the reduction of mistakes/ error rates (rank 9).

– Bearing Point Business Process Management Survey 2012

If many of these goals and impacts sound familiar to you, they should. Because what DevOps ultimately needs to focus on is exactly the same as the focus of BPM – process. In an application world, these processes require applications and services. IT must be able to support these process changes in the application and service infrastructure.

BPM (Business Process Management) has known this for years, and it is the orchestration of the process – the workflow – from task to task, from approver to doer that generates the efficiency gains achieved with that technology.

Indeed, adopters of DevOps who focus on the “big” picture would do well to consider the similarities to BPM which touts as benefits such things as:

Process quality improvements

Continuous process improvement

Reduces costs

Improves business agility

It would be difficult if presented with that list of benefits with no attribution to determine whether it was referring to DevOps or BPM. That’s because the operationalization of business through process orchestration is not all that different from the operationalization of IT through process orchestration.

And processes are not, nor should they be, turn key and one-size fits all. They should be tailored to address the needs of a specific operational or business goal, i.e. deploy an application or secure an order from a customer, based on the systems in use to achieve those goals. BPM shines where it is most able to address bottlenecks and obstacles caused by handoffs between systems and teams. DevOps will shine where it is most able to address bottlenecks and obstacles caused by handoffs between systems and teams. It isn’t about racing through a given task with automation. Speed isn’t efficiency and, if you do the math, a focus on automation without similar focus on process can lead to even greater inefficiency.

And that’s why there is no one size fits all automation and orchestration tooling; because the goal isn’t automating tasks, it’s orchestrating process. Coordinating workflows. Ferreting out inefficiencies.

Orchestration is the glue that binds automated tasks together. For example, recently a missed route update caused some unexpected down time during what was considered a routine* decommissioning of gear. A missed route update. In other words, someone forgot. That task might have been automated, it might have just needed to be kicked off. But it wasn’t.

That’s the kind of thing that would likely not happen if the process was governed by some form of orchestration; if there was a clear list of what needed to be updated or changed based on the removal of that particular component. If orchestration was involved to provide visibility and oversight of the operational processes needed to perform such a routine task. This does not mean the tasks should have been automated; in fact automation is not strictly required to achieve the visibility and oversight necessary because processes are about workflows and hand offs, not specific tasks completed during the steps that comprise a process.

Which leads us right back to Business Process Management. Take a deeper dive into the aforementioned Bearing Point survey and you’ll find more similarities with DevOps:

Crucial elements for sustainable BPM are clearly defined roles (95%), top management support (92%) and a clear mandate (92%)

Typical implementation barriers such as the lack of resources (53%), sponsorship (32%) and experience (25%) need to be identified early and addressed in a structured way

BPM as a continuous (=sustainable) approach is already adopted by 59% of companies, coordinated and implemented either centrally or locally

Involvement of stakeholders (90%), process oriented thinking (90%), organizational institutionalization (82%) and a well-communicated concept (75%) are elements of communication and change management which must accompany the establishment of sustainable BPM

That’s because both are ultimately about process, with automation being only one of the tools in the tool chest that support implementation of a continuous approach to enabling agility in the process layer. Indeed, about 38% of the companies in the survey use software to support their BPM initiatives while another 37% do not. A spreadsheet with the right Six Sigma calculations can be as powerful as any automation framework, toolset or API in identifying the dead space between tasks that introduce inefficiencies and delay application deployments.

BPM has, like DevOps, brought tangible, measurable results to the table. Bearing Point found that almost three quarters of the surveyed companies (72%) were able to achieve measurable benefits through BPM such as process lead time (72%), process cost (68%) and error rate improvements (67%).

So rather than focusing too much on automation, adopters and proponents of DevOps would do well to up-level the conversation and start looking at process orchestration and improvement as the goal. The successes BPM has had on the business side of the equation tell us that doing so will provide a better path to achieving success with DevOps in the operational side of the equation.

* I’d argue that in today’s environment of hyper-sensitivity to availability that nothing that touches a service or gear in the critical path of an application is “routine” but, hey, it is what it is.
March 12, 2015
Webinar: Swapping Engines In Flight: Transforming Brownfield Enterprise Applications
As application release velocity becomes a reality for the enterprise, DevOps professionals must consider how and when to transition brownfield enterprise applications to an agile approach. With production applications on legacy infrastructure, how do you think about “changing the engine on a flying plane”?

Rob Berger is currently Architect at Mist Systems and a noted visionary in the DevOps space, with hands-on experience in automating large enterprise class workloads and migrating traditional product development to agile methodologies.

Join Varma Kunaparaju, CTO of Vistara, as he hosts Rob Berger to discuss:
- What elements of legacy applications can and should be changed
- Common pitfalls and challenges in transforming an application “in flight”
- Deep dive into best practices in re-engineering APIs, responsive and automation
- Best practices and what’s next for enterprise DevOps
Date: Tuesday, April 14th, 2015

Time: 2pm eastern standard time
```
REGISTRATION LINK:(EXPIRED) 
```
Panelists

Rob Berger is currently Architect at Mist Systems, and a real visionary in the DevOps space, with hands-on experience in automating large enterprise class workloads and migrating traditional product development to agile methodologies. Most recently Rob has been involved with software and web services development based on Ruby and Rails as a consultant or advisor at SkyPilot, TelTel, ZipDX and CloudScaling. Rob was a founder and the CTO of Runa Inc., an early stage start-up developing a Software as a Service for online merchants.

Varma Kunaparaju is President and Chief Technology Officer at Vistara. Varma co-founded Vistara, driving the development of the unified IT operations management platform. Varma has over 20 years of experience in high-technology engineering, and has a proven record of building and delivering enterprise software.
March 11, 2015
Beyond Server Monitoring

The logs go in and the visualizations and insights come out. You suddenly have access to data you never had before—data that helps improve your operations and your DevOps environment. But is that where the value of log analysis stops? No! Extending log analysis benefits your entire organization, not just the development and IT Operation teams.

(more…)

March 11, 2015
The best of the first year of devopsy.kinsta.cloud

What were the highest ranked articles by views during the first year of devopsy.kinsta.cloud? We take a look at the top 10 with links back to the original files. What do you think? What were your favorite articles from devopsy.kinsta.cloud this past year?

[seoslides embed_id=”e3bb125a894a” script_src=”https://devopsy.kinsta.cloud/embed-script/the-best-of-devops-coms-first-year/top-10-devops-com-articles/” overview_src=”https://devopsy.kinsta.cloud/slides/the-best-of-devops-coms-first-year/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”The Best of devopsy.kinsta.cloud’s First Year” /]

March 11, 2015
First wave of sessions and speakers announced for DevOps Connect: SecDevOps @ RSA Conference

As we previously announced there will be a DevOps Connect: SecDevOps @ RSA Conference this year at the Moscone Center. The event takes place Monday of RSA Conference week at the Moscone Center. The program committee for the event is headed up by Gene Kim and Josh Corman. Gene and Josh will be delivering the keynote for the event as well. More on that will be announced soon.

Today we are happy to announce the first wave of speakers and sessions selected by the program committee to present at DevOps Connect: SecDevOps. The first wave of selections are:

Automating Enterprise Security by Chris Corriere of Autotrader.com (and devopsy.kinsta.cloud) – How to automate security scans and make the remediation process as easy as possible for everyone involved.

I’m the new Security Lead, and I’m Here to Help by Chris Walsh of Signal – How a new security hire learned from and Agile+Devops team, added security to the mix, and made people happier.

DevOpsSecFail: DevOps Security Anti Patterns by Constantine Cois of Carnegie Mellon University – Common security anti-patterns I’ve observed in DevOps implementation and process.

Blending the Automated and the Manual: Making Application Vulnerability Management Your Ally by Kris Curylo of Ally Financial and Dan Cornell of Denim Group – Security in DevOps is often laser-focused on automation. This talk looks at methods to incorporate manual tasks in a non-disruptive manner.

All four of these sound like excellent presentations. There will be many more sessions to announce soon. With a little over a month until RSA, stay tuned for more information soon including some surprise guest speakers.

Many thanks to everyone who submitted responses to the CFP for the event. Just because you were not selected in this first wave does not mean you are not selected. Stay tuned for more speaker announcements shortly.

March 10, 2015
Continuous Testing – Accelerated !
Except for cases where test duration is the point of the test, as indicated in my prior blog “Isn’t Continuous Testing a Longevity Test Anti-pattern?”, faster continuous testing cycles are preferred because failing early and often is a DevOps goal. There are multiple reasons for this, but it should be evident that faster tests reduce the wait time to get results and since there are typically many development team members looking for results the developer time savings multiplier effect is huge for every minute of test time saved on each CI/CT cycle. When aggregated over multiple code branches a few minutes saved per test can be man-years of time saved over a year!

So what can be done to accelerate continuous testing? Frankly a thorough answer to this topic could fill a book. Below are some suggestions in a checklist format intended to be useful for DevOps .
1. Organize the team for speed: When team members and the organization are explicitly selected for CT speed the entire DevOps process will be accelerated.
  • A test architect familiar with the principles of best practices test environments and continuous test design is critical to design and tune continuous testing for speed. The architect establishes the CT strategy and speed goal relative to the coverage goal.
  • A test analysis team reviews test results so no time is wasted on results analysis.
  • Developers and test members are trained on best practices test design and their test scripts are peer-reviewed to ensure they comply with the strategy.
2. Select powerful test resources: Powerful, dedicated, scalable resources will accelerate all test processes and shorten the time to results.
  • Select the fastest processors, low latency storage and I/O to initialize and execute both the test systems and system-under-test entities quickly.
  • Dedicate resources that have longer initialization times so they can be pre-initialized.
  • Virtualize resources that can be scaled horizontally without sacrificing speed.
  • If affordable, arrange enough resources to run ALL tests in parallel.
3. Choose test tools that are designed for fast test execution: Look for the following features when you are evaluating test tools. Not only will this save you a lot of headaches in the long term, it will give you the flexibility to design tests that integrate with other DevOps tools.
  • Restful APIs that do not require wait states between commands and responses
  • Priority queuing of test cases
  • Creation of test topologies that can be pre-loaded
  • Ability to spawn out tests in parallel to run on any number of machines
  • The ability to park a test that needs to wait for an event and return to it after proceeding with subsequent tests
  • Caching features that enable initialization and results data to be processed for one test while the tool proceeds to execute other tests
  • Multiple devices, session types and results data processing utilities implemented as an embedded part of the tool and not requiring slow speed scripting
  • The ability to render commonly used test utility functions in a fast execution language.
4. Organize test schedules and test suites to fail early: The sequence and approach for scheduling of test cases greatly affects the speed of testing. If possible the scheduler should launch all tests in parallel as soon as the build is ready. Otherwise priority schemes are needed.
  • Organize the test scheduler and test suites to avoid any unnecessary tests.
  • Cache initialization and topologies data and resources ahead of the next test execution.
  • Check the test environment before running tests, abort if invalid conditions are detected.
  • Organize tests so the most important ones are run first.
  • Set a failure escape threshold and abort the test if exceeded.
  • Eliminate dependencies between tests so that each one can run standalone or in parallel. Queue the next test while a test is running.
  • Use smart gray box testing methods to limit test selection to the most important tests according to the software change and skip tests that are low risk.
  • Run longer tests in parallel with shorter ones.
5.Design test cases to fail early: The test cases themselves need to be designed with the strategy to get test results as fast as possible.
• Design each test case with a single unique test purpose and make it self-contained so it may be scheduled to run standalone or in parallel with any other test case.
• If a test case has multiple verdicts arrange the highest priority verdicts first and close the test at the first failure.
• Prune or refactors tests that have a low failure history.
• Shorten dead-script timers, and make any wait timers conditional so they can expire as soon as the condition is met.
• Reduce the number of test iterations to fit a time budget.
• Reduce communication wait times by using the fastest protocols. Optimize the most frequently used utilities.
1. Arrange test results reduce to minimize analysis wait times: Arrange the test results to be consumable as soon as the tests are run so the system does not bottleneck.
  • Report test results as the tests are run and accumulate the results across parallel test targets.
  • Establish thresholds for aggregated test results and abort the tests and release test resources to be used by other tests if the thresholds are exceeded for any run.
  • Keep track of test timings and adjust the test schedules according the average and peak run times for each test case.
  • Separate test result report processes to persistent resources so no test process is waiting to finish a report and the test process can proceed to the next test in parallel with test results.
  • Correlate the test results to the changes and use trends analysis to help speed up diagnostics and as an input to test selection such that the most failing test cases are given higher weight in future test runs.
The above is a partial list of suggestions for accelerating continuous testing that have been proven to yield good results for accelerating continuous testing and DevOps.

At Spirent we think testing has a bright future in DevOps. You can read more about our views at Spirent.com/solutions/devops

What do you think of these suggestions and do you have others that should be mentioned?
March 10, 2015
Red Hat launches platform to support Docker, Kubernetes and enterprise-grade containerization

Red Hat continued its momentum to capture a piece of the containerization market last week with the official launch of its new Red Hat Enterprise Linux Atomic Host operating system. According to Red Hat executives, this is a natural progression in the Red Hat ecosystem as more of the company’s customers embrace Docker and other containerization technologies.

“Today, with the launch of Red Hat Enterprise Linux 7 Atomic Host, we are doing the same for Linux containers, bridging innovative open technology with the stability and security required by the enterprise,” said Jim Totton, vice president and general manager of the platforms business unit at Red Hat. “More than just an addition to the Red Hat Enterprise Linux portfolio, Red Hat Enterprise Linux 7 Atomic Host showcases the future of the enterprise application, a powerful, flexible application greater than the sum of its parts, and entirely fueled by the power of open innovation.”

–THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

March 10, 2015
HIRED to power devopsy.kinsta.cloud jobs page

We are pleased to announce that we are partnering with HIRED to power our jobs page. It has always been our hope that with devopsy.kinsta.cloud’s presence we would serve as a great place for employers and employees to find each other. While we have had a jobs board up and running for a while now, it has not fulfilled the lofty goals we had for our jobs section. We believe partnering with HIRED will give our readers the jobs experience they are looking for. HIRED is growing rapidly because it gives both job seekers and employers a better way of doing what has been a painful experience for too many.

Check out the new page when you can. If you are looking for a new job or to hire a new engineer, developer or other tech worker, give the devopsy.kinsta.cloud job board powered by HIRED a try.

Here is the press release announcing the partnership and service:

devopsy.kinsta.cloud AND HIRED PARTNER TO OFFER A NEW WAY TO FIND YOUR DREAM DEVOPS JOB

Hired’s Disruptive Model of Matching Employers and Tech Talent Via Auction

Boca Raton, FL – March 10, 2015 – devopsy.kinsta.cloud, where the world meets DevOps and Hired today announced that they will partner with the result that Hired will power the Jobs section of devopsy.kinsta.cloud. The DevOps related job market is red hot and Hired’s model promises to make hiring, or getting hired, less painful and easy as possible.

Hired is the first two-sided marketplace created specifically for Engineers, Data Scientists, Designers and Product Managers who are overwhelmed with job opportunities.

“We believe recruiting should be transparent, unbiased, and that the talent should be in control. Our one week “auctions” provide upfront offers from vetted and funded companies, dedicated talent advocates, and a $2,000 signing bonus,”said Matt Mickiewicz, CEO of Hired.”Since we started Hired, DevOps has grown from a niche segment of engineering to one of our fastest growing job categories. We’re thrilled to partner with devopsy.kinsta.cloud and for the opportunity to connect their talented community with companies of all sizes and industries in eight major tech hubs around the globe.”

“Our vision has always been to use devopsy.kinsta.cloud’s big tent to offer a premier way for DevOps related workers and companies to find each other. Hired gives us a best-in-class solution” said Alan Shimel, Editor-in-Chief of devopsy.kinsta.cloud. “We hear from companies constantly that they cannot find qualified talent fast enough for their needs. Hired should help those companies and help people find their dream jobs.”

devopsy.kinsta.cloud job page is already up and running at https://devopsy.kinsta.cloud/jobs/ Both employers and perspective employees can register following the links on the page today.

####

About devopsy.kinsta.cloud

devopsy.kinsta.cloud is where the world meets DevOps. With the most new original content around DevOps per month, it is the largest source of DevOps related news in the world. Additionally its community support and other DevOps information help DevOps community members the world over. Producers of the DevOps Connect series of conferences, devopsy.kinsta.cloud is bringing DevOps information and communication the world over

March 10, 2015
IBM’s DevOps Journey

Companies that want to better address market demand and more efficiently deliver value through speed, quality, and agility are embracing DevOps. This includes retailers, insurers, defense contractors, and most certainly software makers.

Consider the DevOps journey within the IBM Software Group, which is unarguably larger than most enterprise software groups: currently 519 major software product titles, 36,000 software engineers, 116,000 virtual machines supporting development and testing, and 44,000 physical servers. “This is DevOps at scale,” said Matt Ellis, vice president mobile and cloud DevOps at IBM, recently at InterConnect 2015.

Getting teams and processes of that size – while cutting waste associated with outdated ways and duplicate toolsets – is no easy feat. But if it can be done, the benefits are substantial. For IBM, the efforts do appear to be paying off – if the results recently shared over the past six months at the DevOps Enterprise Summit 2014 and the IBM InterConnect 2015 conferences are any indication.

According to Dibbie Edwards, VP DevOps for hybrid, continuous engineering and application lifecycle management development at IBM, IBM has gone from spending about 58% of its development resources on innovation to about 80%.

What did that shift in focus do to IBM’s time frame? In 2008, IBM’s time to project initiation took 30 days. That was reduced to between two and three days in 2014. Groomed backlog was reduced from 90 days to one day and sprint test times from five days in 2008 to 14 hours today. Overall time to development went from 120 days to three, with time between releases reduced to three months from 12.

“IBM is seeing the value of DevOps, and as you heard themes through each one of those sessions, it’s really about speed,” said Edwards at the DevOps Enterprise summit this past fall. Speed has always been important, to be sure, but with the rise of cloud, analytics, mobile, and social, it’s become more important now than ever.

How did IBM begin its DevOps journey?

According to Edwards, it was systematic. The teams examined the work they were doing: all of their processes – from how they worked with their business stakeholders to how they were working with clients – and eliminated all of the inhibitors and friction points. It hasn’t been a swift journey – a couple of years – but it has been a meticulous one.

According to Edwards, during her talk at the DevOps Enterprise Summit 2014, Real-life Experiences Leading Large Organizational Transformation at IBM, the software group focused on uncovering every manual process that it could – things such as how the tests were being created, building more efficient testing tools, and building a page object framework in selenium that its developers could leverage. “That framework itself has allowed us to more than double the number of automated test cases that we have,” she said. “That very significant ability gave us the option to do our function verification testing alongside our development.”

With manual inefficiencies identified and senior leadership agreement to prioritize how processes would be improved and how much will be invested on clearing technical debt, the IBM Software Group then had a foundation on which it could build development processes based on DevOps principles and current business objectives. “We proceeded to build a groomed backlog based on those business priorities and on the size of the development work,” Edwards said. “And if the teams came up against work that they didn’t understand, they would run an exploration phase within their sprint to better understand what needed to be implemented.”

With that groomed backlog in place, IBM could then make more informed decisions at the end of each development sprint – and even pivot, if needed. “If we had a customer need or a business change where we need to shift the focus of the individual teams, we had the flexibility to do that,” she said.

That ability to pivot had been a big benefit for the IBM Software Group. “I recall just how many times we would just churn over these decisions and remake them and make them again,” she said.

Continuous Testing Automation

The culture at IBM has moved to full automation ahead: everything should be automated, and it’s an exception if it isn’t. “I think this is so critical. I saw a real shift in our team as it started to see the value of this and recognized that doing things manually just was not acceptable and really not sustainable, given the level of speed that we were trying to achieve,” says Ellis.

Previously, IBM completed testing in following sprints, because testing teams just could not keep up. Getting to this point was an effort that took focus on continuous improvement. “One thing I always share with the team is how critical learning at the end of each one of our sprints is. And then planning for the next sprint to eliminate the friction points and the areas where we were less efficient than we should have been,” she said.

Finally, IBM automated the testing of its more complex customer usage scenarios. “It literally used to take my team 30 hours to set up an environment to do the testing because we did everything manually,” she said. “We would have to set it up, break it down, and reset it up, because we had all the different databases configurations. By using patterns and automation, we were now able to deploy automatically within three hours.”

March 9, 2015