I'm a dedicated podcast listener, and one of my current favorites is the BBC's In Our Time. The host, Melvyn Bragg, selects a bewildering array of topics, such as Daoism, the Battle of Bannockburn, random numbers, the medieval university, and metaphor. A recent episode about the Industrial Revolution unexpectedly and unintentionally turned into a very lively discussion about the sources of invention, a topic that's near and dear to application development and delivery professionals.
Here's the punch line to this discussion: Not everyone's brain is ready to conjure up new ideas, so you need a catalyst. And here's the connection to this blog: serious games can be that catalyst. Our brains regularly need to be shaken up this way, during both those magisterial moments when we're trying to look over the horizon and the more desperate moments when, as I discuss in a new study, we need to dig ourselves out of a hole.
Last year, colleague Mary Gerush and I wrote overviews of the requirements tools market, noting how it was segmenting to address different problems. (Click here and here for the two studies.) Application lifecycle management (ALM) tools may be undergoing the same evolution, forcing us to accept either a much larger definition of ALM, or several specializations within ALM.
In the requirements market, new tools, or new emphases among tools, were a sure sign that some kind of change was afoot. Several years ago, visualization tools were not only absent from the list of requirements tool capabilities, they were almost completely unknown. Now, any list of requirements capabilities that omits visualization would be incomplete. Several years ago, requirements management was the emphasis of these tools. Now, much of the interesting innovation is happening in requirements collection.
During my research for the just-published document "For Developers, Dog Food And Champagne Can't Be The Only Items On The Menu," I had an interesting conversation with the team at Adobe that handles internal pilots, which in their case entails more than just putting the next version of an Adobe product on the network for people to try. Instead of the typical "spaghetti against the wall" approach to "eating your own dog food" (to mix food metaphors), the Adobe team actively looks for use cases that fit the product. If a product like Flex or Photoshop is a tool, then it should be the right tool for some job. (And if you can't find any use for the software, you're definitely in trouble.)
This approach might require additional work above the "spaghetti against the wall" approach, but it definitely has dividends for many different groups. The product team identifies functionality gaps or usability flaws. Marketers and salespeople have a much easier time figuring out what to demo. As a result, Adobe runs a better chance of both building technology that's compelling, and then explaining what's compelling about it to potential customers.
Recently, I spoke with a major airline about their adoption of Agile, which they considered critical for a major customer loyalty project. Based on previous experience, the dev team expected the business users involved in this project to move slowly, so they saw Agile as a strategy for being ready to pounce on any opportunity to make progress. How slowly? The current estimation for the project's completion was....[drumroll]...five years. Now that's a customer loyalty program ensured to be left with just the most loyal customers imaginable.
As hair-raising a situation as this might be, it's hardly unique. App dev teams contributing embedded software elements to hardware products must time their deliverables to arrive at key landmarks in the overall release schedule. Compliance requirements weigh down software development with extra documentation and validation. Flawed requirements force teams to go back to the drawing board. Dev managers live and die by the schedule, and there's always something that could jeopardize the schedule. Development is pretty pointless unless someone delivers the bits and bytes, but dev ops still remains a relatively mysterious and unpredictable process for dev teams, over which they have little control once they throw their code over the wall.