Skip to main content
Jul 31, 2013

A study on undirected innovation

carlos-montero-luqueNaked Sprint: A study on undirected innovation The technology team at Apperian follows a fairly mature scrum processes, with 2-week sprints that culminate with company-wide demos, releases into production at a frequent and steady pace, and sincere adherence to Agile ceremonies, backlog tracking, and team commitments. This commitment to the process is something we’ve maintained throughout our organizational life and it has allowed us to deliver continuous innovation and value to customers even as we have grown, including working with offshore teams. A few weeks ago we decided as a company to do one of our “experiments.” These are changes in what we do or how we do things with the intention to try new ideas, seek internal process improvements, or, as we have done before, challenge the status quo and the expectations of the market, our customers, and our partners. This experiment was one of unguided innovation. We told everyone in the technology team (development, QA, tech support, ops, products) that they would have one sprint’s worth of time to work on anything they wanted. The only requirement was that, at the end of the two weeks, they would have a demo that they would show to everyone in the organization. The idea of a “hack period” is far from new. But for us, this was a step outside our typical processes. And when you have a list of ideas and innovations like we do, the idea to redirect all technology resources to complete freedom of focus, even for a 2-week period (which, while seeming small, is still 4% of all available technology capacity for the year), is something to consider with open eyes. Fortunately, our company commitment to having the best possible team with the highest level of self-incentive delivering value to our customers and partners is such that, while not a light decision, we readily committed to make this possible. The only other guidance for the technology team was to tell people who had ideas to publicize and evangelize them and to recruit other team members for their projects. Free market competition even within our technology team. The team had about a month’s worth of time to do this while we delivered on the regular backlog of functionality and innovation, so by the time this sprint happened, teams not only had formed, but they had had initial discussions about what they wanted to get done and how they would self-organize. About the name, it’s not an elegant name but I think at this point it has become ours. Not being a native English speaker sometime allows me to come up with (or perhaps forces me into coming up with) odd names. Naked Sprint was initially that, a placeholder, which turned into a joke, and which, with some slight reluctance, became the easy-to-remember name for this experiment. As a side note, googling naked sprint is highly not recommended, at least at work. As I mentioned above, there were precious few guidelines. Individuals or teams could self-organize, use the Agile ceremonies and tools or not, work in whatever form they saw fit, and the “Definition of Done” was put on the freezer. Just make sure it’s a good demo was our call to the teams. The results were, as you may suspect, quite positive. Teams did go in different directions. Some teams created innovations that went all the way to the Board of Directors for consideration. Some teams challenged the elements of our EASE platform so that we could re-imagine them and transform them as the definition of Mobile Application Management continues to evolve. Some teams re-architected part of the backend infrastructure. Some teams sought to deliver new value to administrators and end users in functionality and visualization. In total we had a dozen demos, across the board. A risk of any hack period, of course, is continuity. So in the same way that we committed as a company to reserve this period and provide the maximum possible freedom of action to the engineering teams, we equally committed to review each project after the Naked Sprint was completed and determine the steps to follow. A few of these projects already have had a real impact on our product. There has been re-architecture work that is going into production quickly, some of the changes have become the core of work that will be happening later in this year to the base product, and at least one of the projects delivered something radically innovative and unique from what we bring to market today. The commitment from the technology and business leadership at Apperian is to ensure that all the projects are reviewed, honored, and where it makes sense, delivered as an enterprise solution to our customers. Overall, the results and commitment tell us one thing: this was a successful experiment, and one that we will repeat regularly. It is no replacement for a well thought-out strategic planning. But good engineers live for the creative process and this effort gave a great outlet for that creation. Bringing that into our solid scrum methodology and quickly into market is the next step, as we continue our innovative approach to the market, and looking for the next chance to do this again. Originally posted on July 26, 2013, on the From the Office of the CTO blog.

Apperian

More from the Blog
May 07, 2018

It's Time To Get Serious About Application Security

Apr 02, 2018

How to Detect App Threats to Protect Your Business

Apr 02, 2018

Protecting Apps Is Not Enough: Why You Need Threat Analytics

Every app downloaded via an app store is running in a
Read more