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.
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.