In the days of old, not very long ago, release cycles were measured in years —organizations were using “on-time” and “on-budget" as the mantra for project efficacy. Business today is compelled to deliver business technology in cycles of hours, or days. Faster cycles render not only tradition “waterfall” processes and silo based IT obsolete, it also renders traditional metrics ineffective! These arcane metrics no longer deliver the visibility and granularity tech pros need to fine-tune their delivery capability. The mission has transitioned to rapidly deliver high quality, high value solutions. For all, this is a significant shift from the past, when the main points of focus were schedule, cost, and efficiency. Modern software metrics — speed, quality, and value — are based on continuous feedback from business partners and customers.
Too many businesses believe that their digital business strategy is actually a roadmap, or a series of IT projects. Being digital is a capability – in your business it impacts the culture, metrics, organization, skills, and finally – the technology.
As a CIO, one of the most important roles you’ll play is helping to make the business FAST – removing friction points from processes and enabling new capabilities to be developed as required by the customer, partners, and business stakeholders. Too often technology is one of the (many!) bottlenecks in our ability to quickly meet customer needs or respond to changing or new competitive threats.
I recently had the chance to spend some time with some senior technology leaders in Sydney discussing the need for quality when delivering digital business outcomes. With the growing need for speed, many businesses sacrifice quality for speed. This is ok – to an extent – but there are also many companies with their own horror stories of delivering a mobile app that is unstable, a website that is slow, or a connected/smart product that doesn’t work as planned. It can take years to recover from negative feedback and bad mobile app ratings, and poor products can cost millions in ongoing customer support.
Unfortunately, QA and Testing have too often been afterthoughts in the rush to Agile development. Your Quality Assurance and Testing practices must adapt to digital business too – testing needs to be able to accelerate development – not slow it down. QA needs to focus on customer needs. The QA team needs to speak the language of the customer, get involved with new technology projects at the ideation stage, line up and manage test data before it is required, and empower developers to do much of the testing themselves.
I am just back from the CA World 2015 in Las Vegas, where everything was cool: from the weather, with unexpected but welcomed temperatures in the low 50s; to the event theme, with a strong focus on Agile, DevOps, APIs, and security; to Fall Out Boys and Sheryl Crow’s concerts.
As digital pervades all industries, and software becomes the brand, CA Technologies, which has traditionally had a stronger focus in the IT operations or “Ops” world, is making huge efforts to conquer the hearts and minds of the developers of large-scale development shops, or the “Dev”world. No doubt CA has been building a stronger DevOps in the last few years. Its goal is to partner in a larger industry ecosystem and be better positioned to serve the many organizations that are struggling to scale Agile and consistently build better applications faster. To make a stronger play in the Agile and Dev side of DevOps, CA made two brilliant acquisitions in 2015 which CEO Mike Gregoire highlighted in opening session of CA World: Rally Software, a leader in Agile project management at Scale, and Grid-Tools, a leader in Agile test data management and test optimization and automation.
With its revamped Dev strategy, CA aims to enter the Olympus of those large software and enterprise companies that have moved thousands of internal developers, testers, operations pros, and even managers to Agile and DevOps. With this transformation, CA will position itself to better serve current and future clients’ new needs to develop more software at speed. While CA started this transition much later than its competitors like IBM, Microsoft, HP, and other large software players (and even traditional end user enterprises), we recognize it’s still in time!
A few months ago, I blogged about testing quality@speed in the same way that F1 racing teams do to win races and fans. Last week, I published my F(TA)1 Forrester Wave! It examines the capabilities of nine vendors to evaluate how they support Agile development and continuous delivery teams when it comes to continuous testing: Borland, CA Technologies, HP, IBM, Microsoft, Parasoft, SmartBear, TestPlant, and Tricentis. However, only Forrester clients can attend “the race” to see the leaders.
The market overview section of our evaluation complements the analysis in the underlying model by looking at other providers that either augment FTA capabilities, play in a different market segment, or did not meet one of the criteria for inclusion in the Forrester Wave. These include: 1) open source tools like Selenium and Sahi, 2) test case design and automation tools like Grid-Tools Agile Designer, and 3) other tools, such as Original Software, which mostly focuses on graphical user interface (GUI) and packaged apps testing, and Qualitia and Applitools, which focus on GUI and visualization testing.
We deliberately weighted the Forrester Wave criteria more heavily towards “beyond GUI” and API testing approaches. Why? Because:
Formula One has gotten us all used to amazing speed. In as little as three seconds, F1 pit teams replace all four wheels on a car and even load in dozens of liters of fuel. Pit stops are no longer an impediment to success in F1 — but they can be differentiating to the point where teams that are good at it win and those that aren’t lose.
It turns out that pit stops not only affect speed; they also maintain and improve quality. In fact, prestigious teams like Ferrari, Mercedes-Benz, and Red Bull use pit stops to (usually!) prevent bad things from happening to their cars. In other words, pit stops are now a strategic component of any F1 racing strategy; they enhance speed with quality. But F1 teams also continuously test the condition of their cars and external conditions that might influence the race.
My question: Why can’t we do the same with software delivery? Can fast testing pit stops help? Today, in the age of the customer, delivery teams face a challenge like none before: a business need for unprecedented speed with quality — quality@speed. Release cycle times are plummeting from years to months, weeks, or even seconds — as companies like Amazon, Netflix, and Google prove.
Our bi-yearly Forrester Agile survey suggests that Agile development (or simply "Agile") continues to see consistent, strong adoption. However, the same survey data shows that only a small percentage of firms are outsourcing Agile application development due to a lack of experience with the development sourcing approaches and governance models needed to make it work. Successfully outsourcing Agile development, either fully or partially, involves redefining roles and responsibilities, change management processes, metrics and SLAs, service descriptions, and other contractual elements. Merely using traditional outsourcing language and practices risks jeopardizing the benefits of Agile. There is no single way of doing this right.
When computers were invented 60 years ago, nobody would have thought that gazillions of 0 and 1s would soon rule the world. After all, that’s all there is in any computer memory, be it a laptop, a mobile phone, or a supercomputer like Watson; if you could open memory up and visualize the smallest elementary unit, you would “see” only an infinite sequence of 0s and 1s, something that would look like this:
Interestingly, that has not changed. Computers are still processing 1s and 0s. What has changed is that we live in an age of digital disruption, an age where software applications run and rule our business more and more. To be successful, those applications need to be engaging and entertaining so that consumers enjoy and are delighted by them; they also have to be mobile and accessible anywhere and at anytime, and they have to leverage tons of information, no matter if it comes from a database, a tweet, or Facebook.
I hear people talking about Agile 2.0 a lot. But when I look at what’s happening in the application development and delivery space, I see that many organizations are just now starting to experience Agile’s true benefits, and they’re not yet leveraging those benefits completely or consistently. So let’s stop talking about Agile 2.0 for a moment and instead digest and operationalize what’ve learned so far. There’s plenty to improve upon without getting into inventing new practices and acronyms to add to the Agile transformation backlog!
What I see is that app-dev leaders want to understand how they can optimize existing use of AD&D Agile practices like Scrum, XP, Kanban, improve the practices around the more advanced ones like TDD, continuous testing, CI and CD and leverage all with what they’ve learned over the years (including waterfall). Scaling the whole thing up in their organization in order to have a bigger and more consistent impact on the business is what their next key goal is. We fielded the 2013 version of our Global Agile Software Application Development Online Survey to find out how. I present and analyze this data in my latest report. The survey addressed common questions that clients ask me frequently get in inquiries and advisory, such as:
How can we test in a fast-paced environment while maintaining or improving quality?
How can we improve our Agile sourcing patterns to work effectively with partners?
What a strange summer this has been! From Boston to London to Paris to Turin, the weather has offered weekly and even daily reversals, with continuous change from sun to rain, from hot and damp to cool and crisp. I missed a nice spring season. Even today, from 35º-38º Celsius (95º-100º Fahrenheit), we just went to 22º Celsius (71º Fahrenheit) with a perfect storm! A continuous climate and sudden change is quite unusual in some of these countries. Certainly it is where the Azores Anticyclone usually dominates from mid-late June to mid-late August, offering a stable summer. How many times have you had to change plans because you discover weather is about to change!?
You might be thinking, "What does this have to do with this AD&D blog?" It’s about change! I am wondering if, in our daily lives, getting used to unexpected conditions and having to handle continuous change favors a mindset where change is just something we have to deal with and not fight. A new mindset very much needed given the change we see ahead in how we develop, test, and deploy software!
My focus in this blog is testing, although the first change we need to get used to is that we can’t talk any longer about testing in an isolated fashion! Testing is getting more and more interconnected in a continuous feedback loop with development and deployment. (See my colleague Kurt Bittner's report on continuous delivery; I could not agree more with what Kurt says there!)
I just finished my new report on the Agile testing tools landscape. I’ll point Forrester readers to it as soon as it publishes. But there are few things that have struck me since I took over the software quality and testing research coverage at Forrester and which I would like to share with you in this preview of my findings of the testing tools landscape doc.
My research focus area was initially on software development life cycles (SDLCs) with a main focus on Agile and Lean. In fact, my main contribution in the past 12 months has been to the Forrester Agile and Lean playbook, where all my testing research has also focused. Among other reasons, I took the testing research area because testing was becoming more and more a discipline for software developers. So it all made sense for me to extend my software development research focus with testing. But I was not sure how deep testing was really going to integrate with development. My concern was that I’d have to spend too much time on the traditional testing standards, processes, and practices and little on new and more advanced development and testing practices. After 12 months, I am happy to say that it was the right bet! My published recent research shows the shift testing is making, and so does the testing tool landscape document, and here is why: