DevOps is a movement for developers and operations professionals that encourages more collaboration and release automation. Why? To keep up with the faster application delivery pace of Agile. In fact, with Agile, as development teams deliver faster and in shorter cycles, IT operations finds itself unprepared to keep up with the new pace. For operations teams, managing a continuous stream of software delivery with traditional manual-based processes is Mission Impossible. Vendors have responded to DevOps requirements with more automation in their release management, delivery, and deployment tools. However, there is a key process that sits between development and operations that seems to have been given little attention: testing.
In fact, some key testing activities, like integration testing and end-to-end performance testing, are caught right in the middle of the handover process between development and operations. In the Agile and Lean playbook, I’ve dedicated my latest research precisely to Agile testing, because I’ve seen testing as the black beast in many transformations to Agile because it was initially ignored.
In a recent blog post that I wrote right before the Agile 2012 conference in Dallas, I expressed my hope that the conference sessions would be full of specifics, not generalities. No, thank you, I don't need another presentation explaining what test-driven development is. I'd like to hear someone talk about how they did test-driven development in a large project, or how they made it a standard practice across projects, or whether anyone has had success with it when working with outsourcing partners.
The presentations at this year's conference were a mixed bag, consisting of the following:
Very high-level discussions, often from consultants, about Agile and Lean concepts. These presentations consisted of a lot of name dropping ("Mumblemumble Daniel Pink mumblemumble Geoffrey Moore mumblemumble Taiichi Ohno") and colorful polygons ("You want to be in the two-by-two Grid Of Delight, not the Overlapping Ovals Of Doom"). Unfortunately, the keynote bore a bit too much resemblance to this category.
Emphatic statements of Agile precepts. Sometimes, the arguments were convincing, such as a good workshop-ish session I attended on Agile planning. Others were less persuasive, such as the contention that Scrum should be the governing methodology in every project. (That's exactly the sort of over-the-top pronouncement that gave birth to the phrase "Agile zealot.")
A common question we analysts hear from our clients is, "How do we scale our Agile efforts?" Now, let's be clear: the question is not how to get Agile to work in a large project. Sure, there are challenges in making Agile work within big teams, but there's a much bigger concern. Organizations invest in Agile, or allow Agile experiments to blossom, and then try to capture the Agile magic in a bottle and mass produce it across the organization.
That's an entirely different challenge, with ambitions and uncertainties that are both Texas-sized. (I'm in Dallas, so I'll use Texas metaphors. So shoot me. Wait, no, I take that back.) The uncertainties have many faces, including (but in no way limited to) issues like:
How many projects or products should employ an Agile approach?
Can we expect our outsourcing partners to use Agile as widely as we do?
Do we need a common tools strategy to support Agile?
How much diversity of Agile approaches within teams is a good thing, and how much is counter-productive?
We've seen a number of misconceptions about Agile come and go. For example, the urban myth that Agile is all about velocity gets far less circulation. More people have seen Agile in practice, witnessing first hand the other potential benefits (more chances for mid-course corrections, greater predictability of outcomes, better business/IT alignment, etc.) than just writing code faster. More people are starting projects with these potential benefits in mind, so Agile has clearly moved past the perception that it was some perverse cult of speed. Speed has no intrinsic business value, aside from keeping a twitchy software developer who has consumed way too much Mountain Dew from chewing his own foot off in frustration about delays and obstacles.
Agile Gets To Specifics Quickly
Business value is the goal for Agile transformation; benefits like quality, predictability, and business/IT alignment are either measures of that value or steps needed to achieve that value. Both topics require a lot of clarity or specificity. Otherwise, Agile can look a lot like a road trip gone horribly wrong: we're not sure where we're going, how close we are, or whether we're going the right way at all.
Agile succeeded brilliantly because it started with some very specific practices and values. Don't end a sprint without working code. Keep your backlog prioritized. Build the expectation of new or changing requirements into planning. Don't build your plans on information you don't have. That's a lot more-specific guidance than something like"Achieve this maturity level and you'll be fine" or "Follow this KPI to the ends of the earth."
Agile Practices Create The Need For Other Practices
Agile is a big topic that goes far beyond a set of practices and principles. Change the development cog in the larger software machine, and you change how other parts of the machine operate, too. It’s a deliberately disruptive change that’s supposed to make the software development and delivery machine become more adaptable, produce a higher quality product, or satisfy some other goal that makes people willing to ride the tiger of disruptive change.
Lean helps sustain Agile while driving it in the direction of value, flow, team empowerment, and waste reduction. Other practices, such as continuous delivery and design-driven development, also complement, reinforce, and supercharge Agile transformation.
As analysts, we might treat these developments as an excuse to write research that amounts, more or less, to a list of what’s hot and what’s not. Are more organizations taking a broader approach to DevOps challenges instead of just focusing on continuous delivery? Are Agile-friendly requirements practices, such as visualization, storyboarding, and serious games just a passing fad or permanent additions to the requirements toolkit? How many organizations have adopted test-driven development, and what are the barriers to adoption?
While these questions are important, and the answers more than a little interesting, they’re insufficient. Forrester is in the business of providing practical advice, not academic musings, so that software professionals can apply innovation strategies such as Agile and Lean immediately to the decisions they have to make today.
There is no doubt that Agile growth in the market is significant, and the growing daily number of inquiries I’ve been getting on Agile from end user organizations in 2012 gives me the impression that many are moving from tactical to strategic adoption. Why’s that? Many reasons, and you can read about them in our focused research on Agile transformation on the Forrester website. But I’d like to summarize the top five reasons from my recent research “Determine The Business And IT Impact Of Agile Development” :
Quality was the top — quite astonishing, but both the survey we ran across 205 Agile “professional adopters” and the interviews across some 21 organizations confirmed this. My read is that this is about functional quality.
Change was second to quality. We live in an era where innovation strives and organizations are continuously developing new apps and projects. But your business does not necessarily know what it needs or wants upfront. The business really appreciates the due-course changes that Agile development allows, as they enable the business to experiment and try out various options so it can become more confident about what is really right for the organization. Cutting edge cutting edge systems-of-engagement (Mobile, Web-facing, Social-media, etc) require lots of Change in due course.
The story of Agile is more than just one chapter in the history of software development. It's also an extremely valuable case study in innovation, an elusive and often humbling process that doesn't work in quite the way that we instinctively think it should.
The trajectory of Agile points toward increasing the value of the software delivered. However, it started with no metric of value and almost no notion of what happened outside the development team. Instead, the first phase of Agile, as I describe in the recent publication "Navigating The Future Of Agile And Lean," focused primarily on changing the behavior and world view of developers working together in a team. Therefore, you won't find anything in Scrum or XP that says, "This is how you know your software is better." Instead, these methodologies told you how to work more effectively as a team. Presumably, better results would follow.
Engineering methodologies have been around for a long time. They've not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There's so much stuff to do to follow the methodology that the whole pace of development slows down.
Never has a new trend annoyed me as much as Agile. Right from the get-go, the Agile Manifesto revealed the weaknesses and immaturity of the founding principles. The two most disturbing: “Working software is the primary measure of progress” and “Business people and developers must work together daily throughout the project.” These are
Fiction writers I've met have said that the hardest section of a novel to write is not the beginning or ending but everything that happens in between. The middle chapters trace the course of the protagonist's struggle in way that must be both engaging and credible. The story of how people adopt Agile successfully also has a beginning, middle, and end. The middle part here, too, poses some of the most difficult challenges. The first chapter is a grabber, with teams energetically and fervently doing daily stand-ups, blazing through sprints, christening a product owner, prioritizing their backlogs, and living through all the other exciting events that happen at the very beginning.
And then the plot takes a different turn. Success at the small team level is fantastic, but how do you fit into a development organization? What if you need to work with an offshore team? How do you maintain velocity when builds take several hours or maybe even a full day? Is it possible to deal with compliance requirements without a significant amount of automation? How do you work better with the ops team so that the speed of deployment matches the speed of development?
Since Agile went mainstream, the number of teams reaching the difficult middle chapters of Agile adoption has increased markedly. Both I and my colleague Dave West answer questions about the middle phases every day. Many of these questions also arise during the yearly conference that the Agile Alliance holds in the US. (This year, it's in Salt Lake City to mark the tenth anniversary of the signing of the Agile Manifesto in nearby Snowbird.)
Leaving Scrum, Sarbanes-Oxley, and related concerns aside for the moment, a hot topic these days in app dev circles is product-oriented development. While teams in IT departments might have different motives than ISVs, systems engineers, or people in other situations, they're all interested in roughly the same thing. What it takes to qualify as a product may not be altogether clear, and there may be no definitive way of measuring whether your team's thinking and behaviors have shifted from project-centric to product-centric. As rough-hewn as the concept of product-oriented development might be, it's still an attractive destination for people coming at it from multiple directions. (Not coincidentally, this is the topic of a soon-to-be-published doc.)
In an unexpected way, many of the app dev teams that have been most successful at dealing with compliance are, as it turns out, acolytes of the product-oriented approach. They may not realize it, as their work output may not be any more productized than it was before. Instead, compliance is what turns into a product.