The solution? An innovation sprint!

An innovation sprint is a day set aside for the technical writers to explore new ideas related to the documentation. Giving everybody an outlet to explore these ideas is a win-win situation. As Thomas Edison once said, "To have a great idea, have a lot of them." We've implemented a number of ideas from past innovation sprints, such as flowcharts in key guides and Tips via Twitter pages.
 
 
How did it work?

A technical writer innovating looks surprisingly unassuming. You'd never know that they were turning brilliant ideas into awesome innovations. In fact, here are some examples of technical writers participating in an innovation sprint:

A few weeks ahead of time, we agreed to reserve the 20th of September for the innovation sprint. Closer to the date, we nominated the ideas that we'd be working on. These ideas were discussed at our team meeting just prior to the sprint for peer feedback.

During the day, each tech writer explored an idea that they had nominated at the previous team meeting. Some of us paired on a task, while others worked solo. Our team standup was cancelled and we only attended essential dev meetings.

We wore hats. We ate chocolate. We innovated.

 
 
What did we achieve?

We have a retrospective planned for our innovation sprint in two weeks time. However, the early results look promising. I've seen new conceptual diagrams, improved flowcharts, style investigations, scripts for finding broken links and conditional publishing prototypes. I'm sure that many of these ideas will find their way into our documentation.

Why hats? Everybody knows that a good hat is essential for innovation. Hats also help ward off pesky interruptions.
 
 
What could we have done better?

In hindsight, we should have dedicated more time to peer review of our ideas prior to the innovation sprint. Getting the perspective of other people can help you refine your idea earlier, making the sprint itself much more productive.
 
 
Guidelines for running your own innovation sprint

An innovation sprint doesn't require a lot of structure. However, it is important that everybody has a clear idea of what they want to work on. This prevents people from unknowingly working on the same idea or turning up on the day without anything to work on.

It's also helpful for participants to have as few interruptions as possible. A distraction can totally derail your train of thought. I posted an internal blog post a week ahead of time letting everyone in the company know that we would be unavailable on the day, except for urgent issues.

Finally, you want to make sure that your ideas are implemented. There's no point in dedicating a day to innovation when the results of everyone's work gets put on the backburner for the next year. Note, you don't want to deter people from aiming high and failing. However, participants should be planning out the next steps for their innovation work, regardless of how well the sprint went.

Best of luck running your own sprint!

What is the iPhone web-interface? It's a plugins 2 plugin that can be deployed to a JIRA instance. Once deployed, any user accessing your JIRA instance will get redirected to a more iPhone friendly web-interface for JIRA. With the latest release (version 0.6) the following features are now available:

• Viewing Dashboards & Gadgets
• Creating Issues (limited to certain fields)
• Browse issues via favourite filters and JQL
• Viewing issues reported by you and assigned to you
• Adding comments to issues

Since the last release the UI's been completely re-written with jQTouch providing a much cleaner and faster UI. The plugin now works with JIRA 4.1 and it is now possible to create issues on the go (the most requested feature so far). Currently creating issues is limited to the following fields, but hopefully more will follow soon:

• Project
• Issue Type
• Summary
• Assignee
• Priority
• Description

So what's left on the roadmap? Adding more fields both to the view issue and create issue screens has the highest priority at the moment followed closely by edit issue functionality.

So feel free to give the plugin a go and leave any feedback on this blog or create reviews on the plugin's homepage.

During my last support stint one of our JIRA Studio support engineers brought a support case to my attention where customers where using the JIRA dashboard fairly heavily from iPhone and Android devices. Since their Studio instance got upgraded to JIRA 4.0, they could hardly use the dashboard anymore and apparently 2 gadgets were critical for their users in the field. The JIRA 4 dashboard includes a lot of javascript at the top of the page, and generates a lot of DOM elements dynamically with javascript. This generally isn't a problem on most modern browsers, but on a mobile device with limited CPU and memory it can make a website crawl.

Read on for a one file solution to this problem.

With my last fedex day project, I created the JIRA iPhone Webclient as a proof of concept showing that it's possible to develop a web-interface for the iPhone that looks and feels almost like a native iPhone app.

With that thought I set out to write the deeplyIsEqual matcher. The result is the DeepIsEqual Matcher. Using it is pretty easy. In that previous post I described the Matcher for comparing lightsabers, LightsaberIsEqual. We no longer need that. Now we can simply do

    assertThat(anakinsLightsaber, is(deeplyEqualTo(lukesFirstLightsaber));

No extra boilerplate is needed and we still get all the benefits of only seeing the fields that didn't match in the error messages. Oh, and the reported expected value is built using reflection too, so you don't need to worry about whether the type of objects you're comparing implement toString or how they implement it.

After going through the initial implementation I started switching over the OAuth tests to use this new matcher. Everything was going great until I hit a case where PublicKey or PrivateKey objects were being compared. The problem was, one was a generated key and the other was converted from an encoded string value. Apparently, depending on which way you create Key objects, the internal fields can be slightly different. So, comparing them recursively was failing. I struggled with what to do - I could add the Key to the internal, hardcoded types that are compared by simply using equals(), or I could add the ability for testers to specify how they wanted certain types to be compared using a MatcherFactory. This being 20% time and me seeing other places where specifying custom matchers for certain types would be very useful, I went with the second option.

So, if we wanted to match Hilts in a very specific way we could that pretty simply.

    public static Matcher<? super Lightsaber> equalTo(Lightsaber lightsaber)
    {
        return deeplyEqualTo(lightsaber, extraTypeMatchers);
    }

I wrapped the deeplyEqualTo call in a convience method, because the creation of the extraTypeMatchers can be a bit gnarly and makes the tests a bit harder to read. As a simple example, let's say we want to compare {{Hilt}}s using their equals() and don't care if the subtypes are different. To accomplish that we could use the following extraTypeMatchers.

import static com.atlassian.hamcrest.ClassMatchers.isAssignableTo;
import static com.atlassian.hamcrest.DeepIsEqual.deeplyEqualTo;
import static com.atlassian.hamcrest.MatcherFactories.isEqual;
    Map<Matcher<Class<?>>, MatcherFactory> extraTypeMatchers = new HashMap<Matcher<Class<?>>, MatcherFactory>()
    {{
        put(isAssignableTo(Hilt.class), isEqual());
    }};

That's not very pretty, but by wrapping it up our test can go back to simply being

    assertThat(anakinsLightsaber, is(equalTo(lukesFirstLightsaber));

and we get all the benefits we had before, plus we are matching Hilts in the desired way.

The biggest thing left to tackle is how to handle object graphs that have cycles in them. We have some ideas about how to do it, such as tracking the objects visited and if we find one that we've already visited just stop recursion and assume it will be true, relying on all the other matching to prove otherwise. I'm not 100% sure this will work. The main problem being, what happens if a field in expected value has a reference to, for example, the first object in the graph. But, the actual value doesn't have a cyclic reference but does have a reference to an object that should be considered "equal" to the same object as the expected value (I know, it's probably not entirely clear what I mean but I'm having a problem figuring out how to phrase it more better as my brain keeps breaking when I think too hard about it). I'm thinking for now, being able to specify custom matchers for types should be enough. If there is some part of the object graph that we expect to have a cycle, then just specify a custom matcher for it and move on.

To play with this you can checkout the code from the labs project, or you can get from our public maven repository. If you find any problems with it report them in JIRA.

Thanks, and enjoy testing again!

You're probably thinking: "Yup, that's a great deal, but I how do I run it?". Anticipating this, I took some 20% time last week to find a way to get you up and running quickly. What I've worked out will get you started with no up-front costs, and running costs that can be less than $5 a week!

With a few simple steps, anyone can use Amazon's Elastic Compute Cloud (EC2) to get JIRA and Confluence up and running for their team in a matter of minutes. Let me show you how:

Setting up

Step 1: Create an Amazon Web Services account

Follow Amazon's instructions for setting up an account for use with their EC2 hosting service. Skip the part about the X.509 Certificate and the AWS Account ID, as you won't be needing them. Instead, look for your Access Key ID and Secret Access Key on the Account Identifiers page.

Make sure you record your Access Key ID and Secret Access Key, as you'll need them in step 3.

Step 2: Install Java

Make sure that you have a recent version of Java installed on your desktop PC. You may already have it.

Step 3: Download and run the Instant Atlassian tool

Download the Instant Atlassian tool to your desktop PC, and at a command line, change to the directory containing the tool and run the following command (substituting the red placeholders with the credentials you obtained in step 1):

This will create a server for you, with JIRA and Confluence pre-installed, and 10 gigabytes of space for storing your data.

This tool uses the Amazon Elastic Block Store to store your data. 10 gigabytes of space will cost you $1 per month. These charges stop once you use the tool's "delete" command (described below) to delete the data.

The server will take a couple of minutes to start. During this process, it will give you two pieces of information that you need to keep a note of: The EBS Volume ID (which you'll need to stop the server, and hence the time-based charging), and the URL of your new server.

The server is a "small" EC2 instance located in the US and running Linux, so it costs 10 cents per hour (or part hour). These charges stop once you use the tool's "pause" command (described below) to shut down the server.

Step 4: Complete the JIRA and Confluence Setup Wizards

Open the server URL in your web browser, and you'll see the following page:

From this page, you can click the JIRA and Confluence logos to navigate to the respective applications.

To start, each application will display a Setup Wizard which you will need to complete with a few details. To make your life easier, some of the options have been pre-configured for you, and are disabled in this configuration.

Step 5: Share the URL with your team

Once you've finished the Setup Wizards, share the URL of the server with the rest of your team. They can open it in their web browser and can immediately get to work with JIRA and Confluence.

When you're done

Cutting costs by pausing and resuming

Your team might not need 24x7 access to JIRA and Confluence, so there's a lot of potential to cut costs by pausing your Instant Atlassian server when you're not using it: A 24x7 server will cost you $16.80/week, but this drops to just $4/week if you only run the server for 40 hours a week. (Storage and data transfer costs will be additional, but in typical usage scenarios these will be negligible compared to the time-based charges.)

To pause your server, simply run the following command on your desktop PC (substituting the red placeholders with the credentials from step 1 and the volume ID from step 3):

Once this command completes, your hourly charges have stopped (but your data storage charges will continue until you use the "delete" command, described in the next section).

When you need your server again, just run the following command:

When this command completes, your server will be up and running again. The URL will have changed, so make a note of it, and make sure to share it with your team. (Later in the week, I'll show you how you can set up your very own customised URL that won't change when you pause and resume your server.)

Cleaning up when you're done

While your server is paused, Amazon will only be charging you for the cost of data storage. If you've followed the instructions above to create a 10 gigabyte storage allocation, this will only cost you $1 per month.

If you have finished with your server, and you're sure you no longer need any of your data, you can delete your data storage by entering the following command:

When this command completes, your data will have been deleted, and Amazon will no longer be charging you for its storage.

Beyond the basics

These instructions should be all you need to get your team started with JIRA and Confluence.

Later in the week, I'll show you how to give your new server a customised URL of your own, how to backup and restore your data to protect against the risk of data loss, and how you might be able to reduce your costs even further by making an up-front payment.

All currency amounts are in US dollars, and were correct at the time of writing.

We get a lot of questions about the 'nuts and bolts' of how we've implemented 20% Time, so I'm happy to share the details.

The Goal of 20% Time
	To encourage innovation in products, development techniques and the Atlassian development ecosystem. Not every 20% Time project has to lead to shipped features Internal innovation is encouraged - new processes, techniques, libraries Contribution to the larger ecosystem counts too, where it assists Atlassian Failing is OK

The key here is that innovation is not guaranteed. We can't mandate that every 20% Time project must lead to a new feature since we don't want people to be afraid of failure. Rather, we aim to create an environment where innovation is encouraged and where 'trying' is as much a cause to celebrate as 'succeeding'.

We have also stated a broad scope for 20% Time that includes work on productivity enhancements and external activities (eg working on Open Source projects) — but only where there is a beneficial link back to Atlassian. After all, 20% Time is a part of our Development effort, not a charity. (We have the Atlassian Foundation for that!)

Tracking effort vs Tracking projects

Reporting against specific 20% projects can lead to a decrease in the innovation factor. 20% projects, by their very nature, will have a lot of false starts, dead-ends, and time spent that doesn't directly contribute to a production product (and that is how it should be). If you start tracking and reporting on individuals and how much time they are spending on a project, they might start picking safer, less innovative products, so they don't have a lot of false starts and dead-ends showing up against their name in the reports.

These two viewpoints lead to some friction. For example, we have two sign-off points to ensure projects don't consume too much time without foreseeable benefit:

• Any project that has consumed more than 5 days of developer time requires the sign-off of three supporters. These supporters should be developers who are not involved in the project, but who believe the project is both viable, and a good idea.
• Any project that has consumed more than 10 days of developer time requires sign-off from a Founder.

Enforcing these rules would mean that we have to track time against each project, but this is contrary to giving Developers freedom to innovate without a "big brother" watching over them.

After vigorous debate amongst management, it was decided to have Faith that our Developers would apply their time wisely. Therefore, we are tracking 20% Time at a high-level within our normal time-tracking system, but not at the individual project level. Developers are responsible for getting appropriate sign-off and updating the status of their own projects, the results of which are displayed on a dashboard on our corporate wiki.

(For those interested, we track each 20% project as an individual 'issue' within JIRA, then display those projects as a dashboard on our Confluence wiki.)

It's also worth mentioning that our quarterly FedEx days also contribute to 20% Time but are tracked separately. They involve specific days set aside for innovation in a time-limited, competitive-like atmosphere.

The Future

In line with Atlassian's innate openness, I'm happy to share our findings.

The biggest surprise was the fact that we only delivered "1.1% Time", based upon the number of developers involved. While people had worried that we would spend too much time on 20% projects, it turned out that we hardly invested much time at all.

It's worth mentioning that these statistics are approximate. We didn't mandate strict record-keeping and we don't have reliable timesheet data since 20% Time got mixed-in with our FedEx projects. Therefore, the actual time spent could be 2 or 3 times this figure, which is still very low.

However, we do know that projects ranged in time from 1 to 18 days of effort and that we created some shit-hot improvements to JIRA, Confluence and Bamboo. There were also some projects focussed on internal improvements and Open Source efforts.

How did it work?

Each project was listed on our internal Confluence wiki, with manual tracking of 'days expended'. Projects that got incorporated into products were moved to a virtual 'Hall of Fame' while other projects were retired. A great many projects are still on-going.

Interestingly, the projects that were incorporated into products actually consumed very little 20% Time. Once a concept was proven, it was typically adopted by a Product Manager and incorporated into the normal stream of development. The bulk of work on the feature (adding functionality, testing, perfecting) was therefore done in normal development time. As a result, Hall of Fame projects were typically only 1-5 days.

What problems did we experience?

Atlassian has frequent product releases, so it is very hard for teams to schedule 'down time'. Small teams in particular found it hard to afford time away from core product development. This wasn't due to Team Leaders being harsh. It was often due to developers not wanting to increase the workload on their peers while they did 20% work. They like the products they are developing and are proud of their efforts. However, they don't want to be seen as enjoying a privilege while others carry the workload.

Another problem was accurate tracking of 20% effort. We have tight controls around Annual Leave, so why don't we have controls around 20% Time? The answer probably lies within the Atlassian culture. One of our core values is to "build with heart and balance" and there is a shared feeling of trust that people know whether they are providing valuable work. We track time in major buckets (eg new product development vs maintenance) but there is no "big brother" breathing down the necks of developers who can't explain every minute of their day.

Are we continuing with 20% Time?

After some further refinement during Atlassian's 20% time scheme, I am now pleased to announce that the Confluence Future Macro has been released as an open source plugin on the Atlassian Labs site.

It is currently in beta release and I welcome all feedback regarding its current operation and future improvements. Of course, as Atlassian has generously allowed me to release the source under the Apache 2 license, you are very much free to adjust it as you see fit!

Dmitry Baranovskiy, a Developer on the Confluence team, has been spending his 20% time on a JavaScript library for creating vector graphics. In August, Dmitry released Raphaël -- the first 20% project unrelated to an Atlassian product to be released to the public. At the 2008 Web Directions South conference held last week in Sydney, Dmitry delivered a presentation, related to his work, and was interviewed by SitePoint's Andrew Tetlaw on the beginnings and details of the library.

Here's an excerpt from the article:

SitePoint: Right, I thought my first question should be: why did you write Raphaël? What inspired you to write it?

I was doing a FedEx project. Internally at Atlassian, we have FedEx Days when you are given the time to present a project you've been working on. [...] So I thought I'd do something the programmers might not know anything about, and because I've had experience with SVG before, it made sense to work with SVG. But, as a front end developer, I'm concerned about creating something that only works in Firefox, so I wanted to create a bridge for VML on IE. My original project was to create a charting application, like a simple line chart. I quickly knocked it up in a day and a half from scratch, showed it, but it didn't win anything. It didn't impress people.

SP: Not even a little bit?

Oh, maybe a little bit, but not in general. So I left it for a while. Then we started our 20% projects (just like Google). I decided to pick up this project and extend it a little bit. I got rid of the charting part and turned it into a generic drawing library. Just a bridge between SVG and VML to enable me to do more cool stuff without worrying about browser compatibility.

So at the next FedEx Day, I used this library to create a Skitch-like application. You could take a picture and add things like arrows and ellipses. It even saved the image, but obviously that's not the hardest part.

Then I started working more on this 20% project. To be honest, I spent more than one day a week: I worked with my laptop on the train -- one hour to work and one hour back -- two days a week in general, for about a month. Then I decided that it was good enough to release, because it's better to do so before another developer releases the same thing. So, I released it in the middle of August.

I was stunned by the feedback. I didn't expect it, to be honest, because I wrote about it on my blog and I usually get about 20 hits per day; but after it was released and made it to the front page of Delicious and Reddit, I got about 8,000 hits per day. It chewed through my bandwidth and I had to create a new domain. It actually started costing me money!

To find out more about technical challenges Dmitry faced, like cross-browser compatibility, you can read the full interview. And if you're super keen, you can also follow Dmitry's personal blog to get the latest on what he's up to.

I expect that as 20% time continues to give our developers an outlet for innovation outside of the realm of Atlassian's existing products, more projects like Raphaël will make their way into the wild. As a relatively young Atlassian, this excites me greatly, as it's yet another reminder of how cool this place is to work at, and gives me instant bragging rights in any tech-related conversations that could occur in a social context (believe me, it happens!). Stay tuned for more updates!

This is a major productivity improvement. Some of the annoyances are taken care of now:

Filter out updated issues where the author of the last update is current user

In a typical way, when going through the bucket, I would open the issue in a new browser tab, so I would still have my bucket open and did not need to navigate back to it. That means that once the issue was actioned, I would go back and remove it from the bucket. However, because I just updated that issue, in few moments later the very same issue would re-appear in the bucket.

Not, anymore. You can select an option to exclude your updates from re-entering the bucket.

See BUCKET-21 for more information.

Issue view page operation that will allow for issue removal from a bucket

If you follow the process as described above, you will find it easier to remove the issue from the bucket directly on the view issue page. Once you are done, you can close that tab and refresh the page with the bucket. Done. No more looking to the "just actioned" issue in the list of issues in the bucket just so you can click the little trash icon.

See BUCKET-16 for more information.

Compatibility

This version uses new JIRA 3.13 API, therefore it won't run on older versions of JIRA. Also, as JIRA drops support for Java 1.4 in the future major release (4.0), this plugin steps ahead and only supports Java 5.

See BUCKET-29 for more information.

Shareable buckets

As the dashboard pages are now shareable we had to make this feature work as well. So now, if you share the page with your bucket, other users will be able to see what's in your bucket. Respecting the permissions, if you don't own the bucket, you cannot do anything with it (read-only). And also you can only see the issues that you have permission to see. Keep in mind that as a result there could be more issues in the bucket than you can actually see.

See BUCKET-30 for more information.

JIRA is all about issues; whatever they may be. Some JIRA users create issues. Others action issues: fix bugs, implement new features, follow up on tasks, etc. If you are one of those people who need to monitor what is happening in your JIRA instance, read on.

I am a bug master for JRA project. My responsibilities include keeping an eye on bugs. I need to know about all new bugs raised - so I can take an action if needed; to comment back, to schedule them for fixing or to bring them to attention higher up if necessary. The problem I faced was that it was difficult for me to check the pulse at random. Surely, I have a filter set up to list all issues updated in last 24 hours (which includes created ones as well). I even have a subscription that e-mails me the results of this filter at 2pm every day. The issue coverage in the filter looks like this:

Unfortunately, I could not check the updates in real-time. Well, I could, if I ran the filter. If I ran the filter too soon (in less than 24 hours) I would have overlaps as shown on the next picture:

Or if I ran the filter too late I could potentially miss some issues that were created / updated during those time gaps as shown on the next picture:

Here comes JIRA Issues Bucket plug-in!

This plug-in displays a list of issues in a portlet on a dashboard page. It focuses at showing the created / updated issues from the last time you ran this portlet.

Issues are added automatically as they are created or updated and match the criteria of the associated filter (e.g. bugs in JRA project updated in last 24h).

These issues stay in the list until you manually remove them either by deleting the from the bucket one by one or flushing the whole bucket at once.

You can think about this portlet as your personal to-do list. The issues stay in the bucket until you action them - whether that means to look at them only or actually doing something about them.

Oh, and it also has a "happy factor!" It's what you feel when you go home at the end of the day and you bucket looks like this:

The plug-in is free and can be downloaded from https://labs.atlassian.com/wiki/display/BUCKET/Download. For more information head to project's homepage and JIRA at Atlassian Labs.

I think that among some people there was an expectation that we would just turn on the 20% spigot, and out would come a steady stream of new ideas and implementations. Of course, that's not going to happen. 20% of ten weeks gives each developer at most ten working days, and with the effort of having to fit them around already-tight release schedules, I doubt anyone's used up more than half their allotment so far. Most teams were a month or so into the programme before they could spare any significant developer time.

Still, we've had some successes already. Two different projects are already deployed on our internal JIRA instances, ready for inclusion in the product's next major release. With that in mind, I sent out a quick survey to a few of the developers taking part.

The first thought that popped into my head was that we are giving people one day a week to slack off. Hence, the features that we think will benefit customers the most will be delayed. How can we encourage developers to spend time away from the chosen roadmap? Aren't people just going to spend their time learning the latest scripting language of the day off the web? How will that bring benefit to our customers?

I could just see it...
Coming to work on a Friday morning, checking whether we are on track with the latest JIRA release, and seeing the guys, beer in hand, recoding JIRA's data access layer in JavaScript!

I've been at Atlassian for 5 years now, working on JIRA, our oldest product, first as a developer then a team lead. Over the years I have seen JIRA grow in size and stability, provide more solutions and deliver more and more "bang for the buck". It's my responsibility to ensure that we continually improve JIRA while meeting deadlines, and it's something I truly enjoy. Therefore, I'm not a big fan of anything that threatens our ability to continue doing that well.

However, a few moments later, another thought kicked in. Choosing features has always been our hardest task. The number of possible improvements that we could make, hugely outnumbers what we can actually deliver with acceptable quality. Additionally, it is often impossible to accurately gauge the benefit of making one large improvement versus twenty five smaller ones, especially because people use JIRA in so many different ways. What is extremely important to one person is not necessarily so for the next.

I believe it is even harder to prioritise feature work with respect to internal improvements. We feel guilty each time we take away developer resources from feature work today, (e.g. to speed up the build process or improve the development environment setup script), so that we can spend more time on features tomorrow.

All Atlassian developers use our products, speak with customers and do support. They are an extremely committed bunch of people, who have a keen sense of where good improvements can be made. They are also the best people to evaluate which internal improvements need immediate attention.

Rather than schedule endless discussions about relative importance of each improvement, why don't we give developers time and ask them to use it in the best way they can come up with? I think we could see some great benefits come out of this and allow developers to identify even more with the product they are working on.

I do believe, however, that the success of this trial heavily depends on the discipline of each participant. Each developer needs to ensure they use their time effectively. I am really in favour of time boxing the effort to 20% and sticking to the guidelines that we have in place, especially the peer review of the 20% time projects.

From my perspective, the 20% time trial is an interesting take on Product Management. While the project could affect our velocity in the short term, I believe that it has a large potential to help us improve our products and deliver more customer value, via more innovative releases and internal improvements to tools and processes.

I am eager to see the results at the end of the trial.

About three months ago, at our not-quite-quarterly all-hands meeting, Mike announced that Atlassian would, at some time in the future, in some way shape or form, begin an experiment with 20% time.. My immediate reaction was:

1. This is a great idea.
2. What can I do to make sure this still isn't on the drawing board when the next staff meeting rolls around?

Generally, the biggest barrier to getting something running is finding the time to take care of the boring details, so I decided on a neat hack around the problem: I would volunteer to spend the first six months of my own 20% time... on organising 20% time.

Explaining why I think it's a good idea is another post, and probably repeats a lot of what Mike has said already. This post is all about implementation. I'm not going to go into all the details straight away (that would be long and tedious), but hopefully this is a good overview of how the project has been set up.

Bootstrapping

My first task was to work with company founders Mike and Scott, and Soren (our Director of Engineering) to come up with a framework in which we could start the experiment. For the most part this meant coming up with a list of questions we expected developers might ask, and having answers ready for them. (Sometimes the A in FAQ stands for 'anticipated').

We made a conscious effort to make as few rules as possible. In many ways this whole programme is an exercise in trust between Atlassian and its developers, to see what is done when the restrictions are removed. Shackling it in proscriptive regulation would be counter-productive. Even some rules we did come up with were discarded -- one draft rule barred new developers from taking part in 20% time until they had passed their three-month probationary period, until it was pointed out that this would have excluded our most recent Fedex Day champion.

Expectations

What are we expecting people to work on in their 20% time? I put it this way in the FAQ:

"Our experience with Fedex day, and with general developer slack-time is that the output of developers left to their own devices will fall into the following categories:

• pet features/improvements that never made it onto the roadmap
• "this always annoyed me" bug-fixes or architectural improvements
• integration of some technology-du-jour with a product
• random wacky shit

We're also going to try to use 20% time to encourage contribution to open source projects, JSRs or other community projects, because we want to be good citizens.

Forces

The first three core Atlassian values are:

1. Open company. No bullshit.
2. Build with heart and balance.
3. Don't fuck the customer.

It turns out that a lot of what we need to guide us through 20% time comes out of these three values.

Open Company, No Bullshit

This exercise is, as of now, an experiment. For the experiment to be successful, we need to have some idea of what is being produced, and what effort it took to produce it. For this reason, all projects have to be documented on our internal wiki, and we'll be organising "demo lunches" where developers can show off their achievements... or warn others away from the jagged rocks of their failures.

Build with Heart and Balance

How do you set up a program where developers are free to pursue their passion, to do what they feel is most worthwhile for them to be doing, but at the same time stop developer time disappearing into black-holes and dead ends?

We really only put one a priori restriction on projects: that 20% time not be used as a technological masturbation aid. If you have some concrete goal in mind and honestly think that Haskell is the best way to reach it, that's great. If you just want an excuse to play with Haskell, that's what weekends are for.

Beyond that, the most powerful force to keep it real is peer review. If you have to justify your project to your peers, who will feel it is their duty to ask the difficult questions you may have been fudging over, it should be apparent if your project is worth continuing or not. So there are two mandatory checkpoints. If you want to spend more than 40 hours on one project (one developer-week), you must find three supporters within the company who agree that the project is both a good idea, and viable. After 160 hours, the project also needs to be signed off by Mike or Scott.

Don't Fuck the Customer

Atlassian needs to innovate. We need to devote resources to research and development. We need to take risks and try new things. If we don't, our products will grow stale, wither and die, and the company will follow them. That's not good for us, and not good for our customers. At the same time, we have development schedules. We have customers who are waiting on far more mundane, bread-and-butter features. If we have developers running off to do 20% work whenever they feel like, our release cycles will suffer.

The solution we've come up with is to treat 20% time exactly the same way we treat annual leave. If you want to take time off from scheduled work to work on your own project, you have to give your manager reasonable notice and have it approved ahead of time. And like annual leave requests, managers are expected to approve them unless there is some good reason not to, like the developer being on the critical path for a release, or too many developers taking time off at once.

On Success

One problem with the emphasis we have placed on peer review is that it might cause developers to become too conservative in what they attempt. To quote a Russian proverb my girlfriend is fond of, "He who does not risk does not drink champagne." To remind everyone that failure is, in fact, an option, I put this in the FAQ:

A failed 20% project is not necessarily a bad thing. 20% is an exercise in innovation and risk, and when you take risks you invite failure. You could work on some cool technology and discover that it doesn't really produce the result you were after. You could work on a product feature and find that it doesn't fit in with the direction the product is going. You could just realise, as you develop your project, that it isn't such a good idea after all.

The best advice is to fail fast. Don't get stuck in a death-spiral of unproductiveness, don't spend your days trying to bang a round peg into a square hole. Don't be afraid to draw a big red line through your project, and move on to something that could bear fruit.

(Warning: mixing this many metaphors can be dangerous.)