An “aha” moment is magical. You’re looking at something and all of the sudden an idea or insight hits you. What if we assembled these two elements in a different way? Maybe it would help to generalize these three disparate use cases? Or perhaps this perceived constraint is not real after all? Such moments often yield the ideas that will take your product to the next level. They can even be the germ of a real innovation.
Unfortunately, such moments are also hard to predict or to plan for. How do you know when the big idea will hit? Who on the team is most likely to come up with the next design breakthrough? Most importantly, what can you do to increase your chances of having these “aha” moments more frequently?
While “aha” moments can’t be scripted, there are some times when they are more likely to happen than others. Here are five of those times during the rhythm of a typical agile software development effort.
1. During iteration reviews. This agile ritual brings together a team who is ready and eager to show off its work and a set of stakeholders who care about the product being built. The environment is fun and upbeat, and the ground is fertile for new ideas. If you can welcome all feedback without defensiveness or criticism, you will get more of it. Amidst the numerous somewhat-mundane comments like, “Can we make this section wider?” and “I thought we agreed to disable this button for now?” someone in the room might just have a brilliant idea.
2. During iteration planning & kickoff. With a qualified product owner/manager in the room, this is another open and creative conversation between the team and its clients. It’s the chance to decide what the team will commit to. Keep the ideas flowing by staying open minded, asking “why” a lot, and being slow to shoot down proposals that smell like “new requirements.” When it’s time to do some actual design and tasking, the team is forced to look at things from a different angle, which can also bring out insights that were previously hidden.
3. During a pair programming session. The best pairing sessions feel like an ongoing conversation between the two programming partners. The partner who is not typing is often in a position to see the bigger picture. Freed from the mechanics of syntax, he or she can make new associations and contemplate new relationships between the pieces of code. The “navigator” should not hesitate to share the thoughts and impressions that come, and the “driver” should take them seriously.
4. During the “refactor” step in a TDD cycle. The practice of Test-Driven Development (TDD) turns the design process on its head. Rather than the traditional order of “design, code, test,” TDD encourages “test, code, design.” Once there is a working implementation of a piece of functionality supported by a suite of fast-running tests that preserve its behavior, the developer is free to experiment and innovate with the design. Kent Beck suggests looking for duplication as a great heuristic for noticing potential design improvements. Is there somewhere a piece of code is repeated almost verbatim except for a few lines? Is there a class or module that is surprisingly parallel in structure to another class or module? Taking a few minutes to ask these questions during each TDD cycle can provide some fantastic insights about how the code needs to evolve next.
5. During a hands-on user acceptance test. Watch what the users are doing with your software. What confuses them? What surprises you? What interactions are they actually are having with the product? These are all chances for learning and achieving a deeper understanding of what truly needs to be built.
These are just a couple of many opportunities for “aha” moments during agile product development. There are obviously others. (Many is a developer who got a great idea in the shower, for example.) But recognizing these situations as times when the ground is ripe for new ideas can make you more attuned to when those ideas come.