Recently I spent ninety minutes with our full development and product teams listening to a series of two minute pitches on ideas for our quarterly ‘hack week’ event.  As a company we’ve been doing this for the past few years – setting aside one week every quarter for our development team to explore ideas and innovations that excite them.  Lots of firms do this kind of thing (including Google and 3M – check the link here for more information: http://bit.ly/11IroBf) and our company just finished our most recent iteration.

What do we do for hack week?  Folks across our consulting, product, and development teams collaborate to pitch ideas about new technologies to explore, fresh design ideas to prototype, and interesting problems to dig into.  Some of these ideas flow directly from issues that our clients encounter, and hack week gives us a chance to explore potential approaches to solving these interesting problems.  Other times one of our coders, testers, or quants wants to explore new technological offerings that might lead to innovative enhancements to our existing solutions.  And sometimes hack week offers a chance for people to explore something simply because it interests them.  Anyone – whether from the consulting, design, or development teams – can present a two-minute pitch for a project, letting the audience know the potential benefits of exploring the idea for a week and the types of skills needed for the project.  Our most recent set of pitches included roughly 25 ideas that ranged from research and training ideas to new design approaches and client-specific problems; pitches came from business consultants, testers, quants, and brand new hires to the team.  Then all those involved vote on which ideas will be examined and the teams form around the 15-20 hack week projects that generated the most excitement.

Why do we do take this regular time out of our full development schedule every quarter?  Partly because our development team loves the chance to learn and to try new things – and keeping this great team happy and engaged helps them produce the kinds of innovative solutions they work on the other 48 weeks of the year.  Hack week deepens the collaboration across our teams as people explore a defined project with folks they might not usually work with; fostering stronger connections among the members of our product and development teams leads to more productive partnerships during our normal sprint cycles.  Setting aside time dedicated to exploring new ideas also allows our teams to stay abreast of the newest technologies and approaches in a fast evolving field.  Rather than simply churning out more code in familiar ways, hack week gives our team the chance to learn better ways to solve existing issues and offers low-risk ways to examine innovative methods for solving complex business and technology problems.

What kind of results have we seen from our hack week projects over the past couple of years?  In addition to keeping our development team happy and showing our consulting team the kinds of cool things that are happening at the intersection of finance and technology, we’ve had some great practical outcomes from these hack week projects.  We have launched a couple of new products first explored via hack week, evaluated numerous technologies and found a few that we wanted to use, discovered several ways to enhance the performance of our systems, generated some useful analytics around our core applications, and developed new testing techniques that make all of our systems more reliably stable.  We have built out custom models that solve specific client problems, built light-weight prototypes to help determine how successful we might be with new product offerings, and allowed our teams to dig deeply into cutting edge technology.  And we’ve done all this while deepening the relationships across our teams, making our normal development cycles much stronger.

So how does all of this relate to Agile?  Hack week is one of many aspects of our company culture that reflect the core principles of Agile, principles like, “Business people and developers must work together daily throughout the project,” and, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”  Hack week helps us foster an environment of collaboration and support that tangibly demonstrates the ways we value the insights of our development team.  The emphasis on creating a working prototype at the end of each hack week also connects with and strengthens the Agile principle, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”  And the fact that these hack week projects often revolve around exploring new technologies and approaches to coding and testing embodies the Agile principle that, “Continuous attention to technical excellence and good design enhances agility.”  Our regular hack weeks flesh out our commitment to the core principles of Agile software development, allowing us to strengthen our teams and deepen our collaboration in ways that feed our regular development cycles.

Lots of companies talk about the importance of fostering innovation and strengthening cross-team collaboration.  We’ve found over the past couple of years that regular hack weeks have been crucial in pursuing both of these goals.  Rather than decreasing our coding output by spending four weeks every year not working on production code, we’ve seen both more and better results from our development team as they have had the freedom to set time aside for exploration.  We’ve generated some cool new models and products and we’ve validated (or rejected) some approaches quickly through these innovation experiments, all while deepening connections and providing an enjoyable outlet for our development teams.  There are still some people who question how useful it is to have these regular hack weeks, but personally I hope that we continue to strengthen them (just as I hope that more of my pitches get accepted as projects to work on).  There is always a need to balance the demands of our aggressive product development plans with the long-term benefits of setting time aside for experimentation, but the results of our regular hack weeks are gaining wider recognition across the company and so I expect that these will remain an important part of our culture.  These aren’t the only source of innovation at our firm, but consciously carving out this time does make a crucial contribution to cultivating a culture of innovation.  There is lots more I could say about our hack week experiments – enough for some future blog posts I expect.  I’d love to get all my thoughts into one post, but in truth it’s not that simple.