Outside the technology industry, engineers sometimes build multiple prototypes before selecting one particular design. Rather than finding the defects of one proposed design, discarding it, and moving on to the next idea, engineering teams that apply this approach, set-basedconcurrent design, save themselves a lot of time and headaches by running through as many options as possible simultaneously. As you might have guessed, this technique isn't cheap. You need to staff multiple design teams, and prototyping in many industries, such as automotive manufacturing, is always expensive. Nonetheless, by delaying the design decision for as long as possible, until the team has found the best among multiple ideas, development can take less time, with a greater probability of building a good product, than with sequential design.
So why don't we build software this way? For Microsoft, SAP, and other technology companies, prototyping is orders of magnitude cheaper than it is for Toyota and General Motors. Executives at tech companies would love to reduce the unpredictability of development schedules, often thrown off-track by unexpected design issues. So why hasn't set-based design caught fire in the technology industry?
That question has been plaguing me since hearing an excellent presentation by Jean Tabaka and Bill Wake on this topic at Agile 2009. I'm not sure of the answer ("More research required," says the analyst), but I'd be amazed if it didn't include two factors: (1) the nature of the product being developed; and (2) the unspoken assumptions of the tech industry.
A lot of my recent research – about SaaS/PaaS, Agile tools, requirements tools, and innovating with your channel – share a common conclusion: successful technology vendors see integration as more than just a necessary evil. Here's why.
Business problems drive technology adoption You can see this principle in action in the requirements tools market, which in the last decade has grown larger and more complex. Teams use these tools to address more than one type of requirements-related challenge, so it's easy to see why the tools themselves are now as diverse as as Micro Focus (née Borland) Calibre, Atlassian JIRA, Ravenflow RAVEN, and VersionOne's Ideas Management module. If your problem is, "People don't like using our product," you might look at a visualization tool like iRise to shorten the feedback loop, leading to better design decisions. If, instead, your problem is, "We don't have a good business justification for what we build," you might look at IBM Rational DOORS to evaluate the pros and cons of alternative scenarios for what goes into the next release.
In the tech industry, the "tell me a story" approach to product requirements – personas, user stories, use cases, visualizations, etc. – has made a bigger impact than many people may realize. Not only has this new type of content resolved many problems that existed with requirements, but it has led to a brand new way of looking at requirements. By thinking of requirements as stories, it's easier to figure out what kinds of requirements we need, and why we need them.
A tale of two mini-series
The fundamental question when writing any kind of story is, "What are you trying to convey?" I was thinking of exactly that question while I was watching the HBO mini-series The Pacific. I probably wasn't the only person to expect The Pacific to be the same kind of story as Band Of Brothers, just transplanted from the European to the Pacific theater of operations. I was wrong.
As it turns out, the new series has a very different kind of story to tell. Band Of Brothers depicted the experience of combat, in (literally) gory detail. While The Pacific does have more than enough battle scenes, it also tries to show military life beyond the battlefield. For example, one episode focused on the painful romantic choices that young people stationed in faraway lands have to make. Another episode depicted something rarely seen in war movies, the psychiatric casualties of war. Far more than Band Of Brothers, The Pacific shows more of the atrocious things that young men under brutal, terrifying conditions are capable of doing.
As we've discussed before, Agile adoption swelled in the last one or two years, diving into the mainstream of how businesses build and deliver value to customers. (You can definitely say that Agile is mainstream if there's more than a one-third chance that, in your next job in a development team, you'll be following Agile practices.) At a time when the public perception of companies has taken a brutal beating, that outcome is a genuine compliment to many businesses.
When the economic storm clouds gathered, companies might have battened down the hatches, sticking to the most tried-and-true ways of doing business. The recession might have been the strongest argument against disruptive changes, once the economic margin of error became a lot smaller. A business process as critical as product development might have been the last thing anyone wanted to tinker with.
Therefore, Agile presented just the kind of disruptive change that organizations might have avoided. It doesn't work unless organizations embrace new values and procedures. These changes ripple throughout the organization, especially in the technology industry, where the technology is the business, not just a business accelerator. Every team must figure out how to chart its own Agile course, usually leading to an idiosyncratic mix of Agile and non-Agile methods. None of these changes will be easy.
Agile adoption requires a change in values, not just a change in process. That's the message of the Agile Manifesto, and everything we've learned in the year since the Manifesto's publication has only expanded and emphasized it. We might not have all the specifics on how that relationship works (for example, does an "Agile culture" automatically dictate Agile practices?), but the correlation is definitely there.
In technology companies, these values are critically important, since technology does not just improve the business, it is the business. Agile changes how teams develop and deliver technology. In a technology company, delivery includes practically everyone outside the development team—marketing, sales, support, consulting, partners, you name it. Beyond the janitorial staff, it's hard to think of someone who won't be effected when a tech company goes Agile.
Consequently, product managers and product marketers, sitting on the border between the development team and everyone else, are simultaneously the agents and targets of Agile transformation. For example, when monolithic releases crumble into many smaller iterations, people throughout the rest of the company have obvious questions, such as, When can I tell a customer to expect the enhancement they've wanted for the last two years? When is the next time we're going to have to do sales training? When will we have delivered enough new value to merit a product launch? PMs facing this situation will have to make adjustments to their own work, such as building and communicating the product roadmap.