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.
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?
With the employer mandate delays being the latest setback to U.S. president Obama's push for national healthcare, it's worth looking at how other countries are successfully tackling the same problem. The United Kingdom has had nationalized healthcare for years, and one of the things that makes this effort so successful is its approach to data collaboration — something Forrester calls Adaptive Intelligence.
While the UK hasn't successfully moved into fully electronic health records, it has in place today a health records sharing system that lets its over 27,000 member organizations string together patient care information across providers, hospitals, and ministries, creating a more full and accurate picture of each patient, which results in better care. At the heart of this exchange is a central data sharing system called Spine. It's through Spine that all the National Health Service (NHS) member organizations connect their data sets for integration and analysis. The data-sharing model Spine creates has been integral in the creation of summary care records across providers, an electronic prescription service, and highly detailed patient care quality analysis. As we discussed in the Forrester report "Introducing Adaptive Intelligence," no one company can alone create an accurate picture of its customers or its business without collaborating on the data and analysis with other organizations who have complementary views that flesh out the picture.
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:
I’ve previously written about how modern application architectures are shifting toward compositional, service-oriented architectures — “for real” this time. RESTful services using XML or JSON payloads proliferate because they’re easy for developers of omnichannel clients to use on virtually any device they need to support. It doesn’t matter if they’re building native apps in Objective C or hybrid apps with Cordova — if they can get an open web API call, it’s good enough to move forward.
This shift to web APIs and modern applications means that companies have to shift their API management strategy as well. They need to 1) create the web APIs and 2) create a life cycle to manage them. It’s this life-cycle element that’s conceptually distinct from traditional SOA governance solutions. For one thing, the services live on the open bus of the Internet and carrier networks. Another difference is that web APIs are increasingly made availabe to third-party developers. They may be part of a newly formed developer community, or they may support the growing number of digital agencies and mobile specialist firms that your company uses to supplement development projects. Security and access models are different (e.g., OAuth 2), provisioning access to APIs needs to support light-touch approval workflows, sandboxes where developers can test their calls are important, and analytics that detail call volume and how developers are using APIs are must-have capabilities. Above all, a developer portal that provides good documentation, example code, and quick time-to-value are important if you want to attract and keep developers.