We were at Boxworks14 last week, and had a great time!
We met a bunch of interesting folks, including Heidi Williams, Senior Director of Platform Engineering, who — along with Peter Rexer and others from her team — gave some really insightful deep-dives into Box’s technology stack.
(Among other things we learned that we could improve the Kerika user experience by changing the way we do OAuth 2.0 with Box.)
Keynote speeches were amazing: the hyper-kinetic Aaron Levie made for a rousing start, but the real star was Jared Leto who not only brought his Oscar onstage, but in a jaw-dropping move handed it over the audience for people to take selfies with while he blithely continued with his “Fireside Chat”.
Jared’s move even upstaged Aaron, which is pretty hard to do (as you will know, if you have ever encountered Aaron in the flesh…)
Other great speakers included Jim Collins, author of Built to Last, Vinod Khosla of Khosla Ventures (and, originally, Kleiner Perkins and Sun Microsystems), and Andrew McAfee from MIT.
We often get asked if Kerika has an integration with Git. The short answer is “No”, but the longer answer is more nuanced…
We use Git ourselves for managing our own source code and other software assets.
Git was designed from the git go (ha!) to be used by distributed teams, having originated with the Linux kernel team, perhaps the most important distributed team in the whole world, so it made perfect sense for us to use it: it works across operating systems, and a number of simple GUIs are now available for managing your various source-code branches.
We simply embed the git references within cards on our project boards: sometimes in the chat conversation attached to a card, but more often within the card’s details.
Here’s an actual example of a bug that we fixed recently:
Example of Git integration
We use multiple Git branches at the same time, because we put every individual feature into a separate branch.
That’s not a fixed rule within Git itself; it’s just our own team’s practice, since it makes it easier for us to stick with a 2-week Sprint cycle: at the end of every 2 weeks we can see which features are complete, and pull these git branches together to build a new release.
So while Kerika doesn’t have a direct integration with Git, it’s pretty easy to use Kerika alongside Git, or other source management systems.
Here at Kerika, we often get asked how we do Scrum as a distributed team.
Here’s the model we have evolved, which works for us mainly because we are the very essence of a distributed Agile team: we have people working together on the same product from locations that are 10,000 miles apart!
And this means that we are the most enthusiastic consumers of our products: we use Kerika to manage every part of our business and we only build what we would ourselves love to use.
Here’s the basic outline of our Scrum model:
Kerika’s model for 2-week Sprints
Each Sprint is 2 weeks long: that that works well for us; other folks might find that 3 weeks or 4 weeks i better. Pick what works for you.
Each Sprint begins with Sprint Planning, where the Scrum Team gets together with the Product Owner to decide which cards will be pull from our main Product Backlog into the Sprint Backlog.
Each Sprint is organized as a separate Scrum Board: this makes it really easy for us to concentrate upon needs to get delivered in that particular Sprint, without getting distracted by what was done in the past or what remains to be done.
And Kerika makes it really easy to pull cards (literally!) from the Backlog onto a Scrum Board, and then hide the Backlog from view so it doesn’t distract the Team while the Sprint is underway.
Half-way the Sprint, at the end of the first week, we do a gut-check: does the Sprint look like it is going reasonably well? We don’t ask if it is going perfectly: almost no Sprint does; what we are looking for is any indication that the Sprint is going to severely under-deliver in terms of the Team’s commitments to the Product Owner.
We could do these gut-checks every day during our Daily Standups, but in the first part of a Sprint cycle these can often give us false positives: it’s easy to tell early on if a Sprint is going to be disastrous, but it’s hard to tell for sure that it is actually going to end well. But about midway through the Sprint we start to have a more reliable sense for how things may turn out.
In keeping with the Scrum model, our goal is to complete a potentially shippable set of features and bug fixes with each Sprint, although this doesn’t necessarily mean that we will always ship what gets built after each Sprint. (More on that later.)
For each feature or bug, however large or small, we make sure that we have design and testing baked into the process:
An analysis document is prepared and attached to the card, either as a Google Doc or as Box document. (We had been using Kerika+Google exclusively for years, but have recently switched to Kerika+Box since we completed our Box integration.)
The document is often just a few paragraphs long, because we always take cards representing large features (or other big work items) and break them up into smaller cards, so that no card is likely to take more than a day’s work. Kerika makes it really easy to link cards together, so it’s easy to trace work across multiple cards.
For bugs, the attached document describes the expected behavior, the actual behavior, and the root cause analysis. Very frequently, screenshots showing the bugs are attached to the cards.
For new features, several documents may be attached, all quite small: there may be a high-level analysis document and a separate low-level design document.
For all features and bugs, we do test planning at the time we take on the work: for back-end (server) work we rely primarily on JUnit for writing automated tests; for front-end (UI) work we have found that automated testing is not very cost-effective, and instead rely more on manual testing. The key is to be as “test-driven” in our development as possible.
There are several benefits from doing formal planning, which some folks seem to view as being antithetical to an Agile model:
It helps find holes in the original requirements or UI design: good technical analysis finds all the edge cases that are overlooked when a new feature is being conceptualized.
It helps ensure that requirements are properly interpreted by the Team: the back-and-forth of analysis and reviewing the requirement helps ensure that the Product Owner and the Team are in synch on what needs to get done, which is especially important for new features, of course, but can also be important to understand the severity and priority of bugs.
It deliberately slows down the development pace to the “true” pace, by ensuring that time and effort for testing, especially the development of automated tests, is properly accounted for. Without this, it’s easy for a team to quickly hack new features, which is great at first but leads to unmaintainable and unstable code very soon.
At the end of the 2-week cycle, the Team prepares to end the Sprint…
We like to talk about Sprints as “buses”: a bus comes by on a regular schedule, and if you are ready and waiting at the bus stop, you can get on the bus.
But if you are not ready when the bus comes along, you are going to have to wait for the next bus, which thankfully does come by on a regular 2-week schedule.
This metaphor helps the Team understand that Sprints are time-boxed, not feature-boxed: in other words, at the end of every 2 weeks a Sprint will end, regardless of whether a feature is complete or not. If the feature is complete, it catches the bus; otherwise it will have to wait for the next bus.
And here’s where the Kerika team differs from many other Scrum teams, particularly those that don’t consume their own products:
At the end of each Sprint, we do the normal Sprint Retrospective and Show & Tell for the Product Owner.
But, we also then take the output of the Sprint and deploy it to our test environment.
Our test environment is the one we actually use on a daily basis: we don’t use the production environment as often, preferring to risk all of our work by taking the latest/greatest version of the software on the test environment.
This forces us to use our newest software for real: for actual business use, which is a much higher bar to pass than any ordinary testing or QA, because actual business use places a higher premium on usability than regular QA can achieve.
(And, in fact, there have been instances where we have built features that passed testing, but were rejected by the team as unusable and never released.)
This is illustrated above: the version of Kerika that’s built in Sprint 1 is used by the team to work on Sprint 2.
This is where the rubber meets the road: the Kerika Team has to build Sprint 2, while using what was built in the previous Sprint. If it isn’t good enough, it gets rejected.
At the end of Sprint 2, we will release the output of Sprint 1 to production. By this time it will have been used in a real sense by the Kerika Team for at least 2 weeks, post regular QA, and we will have a high confidence that the new features and bug fixes are solid and truly usable.
We could summarize our model by saying that our production releases effectively lag our Sprint output by one Sprint, which gives us the change to “eat our own dogfood” before we offer it to anyone else.
We got an email this morning from a user that we decided to answer here, because the topic is relevant to many of our old users…
We are wondering what the differences between Box vs Google are going to be. Also, if we move over to a Kerika+Box account, will we have to rebuild what we have set up in Kerika+Google?
To answer the first question: the Kerika user interface is the same, whether you use Kerika+Box or Kerika+Google.
And, we fully intend to keep the user interface the same across these two cloud storage platforms — and any others that we might support in the future.
That said, the Kerika user experience, which is more than just the user interface, is a little different due to the quirks of Box vs. Google.
For example, Box makes it really easy to sign up as a new user, and keep your old email account. You can do that with Google, too, but it’s a lot more cumbersome.
Box also works really well with Microsoft Office files: Box doesn’t try to convert your files into it’s own proprietary format, i.e. it doesn’t have its version of Google Docs, so if you like working with Microsoft Office, Kerika+Box is probably the better choice.
(Note: it’s possible to use Kerika+Google and not have your files converted to Google Docs, by setting a user preference, but that kind of misses the point of using Kerika+Google in the first place…)
If you like to view and edit your files right in the browser, then Kerika+Google is the better choice because Google Docs is getting better all the time.
For both Kerika+Google and Kerika+Box, we try to make sure all your Kerika-related files are neatly stored within your own cloud platform, but that’s a little better on Kerika+Google than with Kerika+Box:
Google allows Kerika to create as many nested folders as we need, which means that you only see a top-level folder called “Kerika.com” when you view your Google Drive, and all your projects, across all the accounts you work with, are all stored inside here.
Box doesn’t allow us to create nested folders in the same way, so you will see a lot more top-level folders in your Box account as your Kerika collaboration network grows.
So, the same user interface for both Kerika+Google and Kerika+Box, but a slightly different user experience with pros and cons for both Google and Box.
And the user interface will remain the same in the future: we have no intention of adding features that will only work with Google or Box — only features that will work well with both.
Now, for the second question: if you create a new Kerika+Box account, you will need to create new projects in this account because it is not connected in any way to your Kerika+Google account.
This may be a bummer for some of our old users who have a lot of projects built up using their Kerika+Google accounts, and now want to switch over to using Kerika+Box.
The reason this limitation exists is that the underlying cloud platforms are completely different, and come from two companies that are competing with each other rather than collaborating in any way.
This makes is impossible for us to move content from a Kerika+Google account over to a new Kerika+Box account, even if they are owned by the same user, since even if we tried to move over all the cards, boards and canvases, we wouldn’t be able to automatically move over any related files.
We are now dealing with two different user communities!
People are signing up for our new Kerika+Box product, and we are continuing to grow our Kerika+Google user base.
Next up: we are upgrading our Google Apps Marketplace integration to also use OAuth 2.0, so that all logins to Kerika will be with OAuth 2.0, across all platforms.
The background to this work is slightly wonky, and reflects the way Google Apps Marketplace has evolved within the Google ecosystem.
If you sign up for Kerika+Google today, you actually go through a OAuth 2.0 authentication and authorization process with Google, which gives us your basic profile information (name, email, photo) that we use to set up your Kerika+Google account, as well as access to your Google Docs.
Google has deprecated OAuth 1.0, so we are updating our Google Apps Markeplace to also work with OAuth 2.0, just like a regular sign-up through Kerika.com.
This change will not affect any existing users: the most visible effect will be on our Sign Up page, which will start to show three options for new users:
Sign up for a Kerika+Box account: this will work as it does today – it will use OAuth 2.0 to set up a Kerika account using your Box credentials (name, email address, and access to your Box account to store your Kerika-related files).
Sign up for a Kerika+Google account: this will also work as it does today – it will use OAuth 2.0 to set up a Kerika account using your regular Google credentials (e.g. Gmail ID, YouTube ID) and store your Kerika-related files in your Google Drive.
(The ninth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)
We have been doing internal testing (“eating our own dogfood”) of Kerika+Box for the past three weeks, and the results have been much better than we expected!
We have found very few bugs so far, which is great — it’s feels like a huge vindication of our decision to invest several Sprints in improving our internal QA processes, clearing the backlog of old bugs, and generally improving our software development processes with code reviews across the board, for even the smallest changes.
In other words, we didn’t move fast and break things: we moved slowly and broke nothing. Which makes sense when you have paying customers who rely upon your product to run their businesses…
Since Kerika makes it really easy to have multiple backlogs in a single account, we put all the OAuth and infrastructure work in a separate backlog, allowing a part of the team to concentrate on that work somewhat independently of other, more routine work like bug fixes and minor usability updates.
And, as before, put every feature in a separate git branch, making it easy to merge code as individual features get done.
Here’s what our Box QA board looks like, right now:
Box QA board
The user interface for Kerika+Box is essentially the same as for Kerika+Google, with a few quirks:
Box requires more frequent logins: Google provided us with relatively long-lived refresh tokens, so a user could close a Kerika browser tab and reopen it a day later and log right back in.
With Box, you are going to see a login screen much more often, along with a screen asking you to re-authorize Kerika as a third-party app that can access your Box account.
This is kind of irritating, but apparently unavoidable: from what we have found on Stack Overflow, Bug views this as a feature rather than a bug.
The other, really big difference is that files are edited offline rather than in the browser itself: when you click on the Edit button, you will end up downloading a local copy of the file, using Microsoft Office for example, and then when you do a Save of that file, your latest changes are uploaded automatically to the cloud.
Here’s what you see when you open a file attached to a card on a Kerika board, when you use Kerika+Box:
Example of opening a file within Box
This works great most of the time, except when two people are making changes simultaneously: in that situation, Google’s in-browser editing seems a lot more convenient.
On the other hand, downloading local copies of files means that you get the full power of Microsoft Office, and we know that’s very important for some of our users, e.g. consultants dealing with complicated RFPs or government users dealing with official documents.
Performance also seems a little less than Google Drive, although we would stress that this is highly variable: while Google Drive files generally open within 1-3 seconds in a new browser tab, they can take much longer if Google’s servers are slow.
Overall, we are very pleased with Kerika+Box: we are planning to do all of our new development with this new platform, to continue eating our delicious dogfood ;-)
(The sixth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)
And this brings us to Box…
We first heard of Box through cloudPWR, a Kerika partner and long-time Box reseller: Shadrack White, Dennis Brooke, and Cullen Hower suggested to us (a year ago!) that we consider integrating with Box.
Shad and Dennis were both enthusiastic proponents of Box: they had done several implementations of Box, including a very interesting use-case for Washington State’s Liquor Control Board which found itself in the business of regulating medical marijuana this year.
As we looked at Dropbox and OneDrive as possible alternatives to Google Drive, Box came up repeatedly in the conversations we were having with enterprises.
It was clear that Box was treated very seriously by some folks that we considered very smart and knowledgeable — a senior director at Amazon, for example, told us (off the record) that he considered Box to be the most enterprise-ready cloud storage platform — and so we decided to take a closer look at the Box platform.
We attended Boxworks in San Francisco last summer, and were immediately struck by the differences in tone and substance between Boxworks and DBX.
While Dropbox is a consumer-oriented company with a newly developed interest in the enterprise, Box is a very enterprise-focused company (with little or no interest in consumers).
We took a close look at the Box API, and were very pleased with what we found: Box’s API was very close to what we were getting from Google Drive, which meant that a Kerika+Box integration could offer a really good user experience:
If you add a file to a card or canvas on a Kerika project board, it will automatically get shared with everyone who is part of the project team.
People’s access to project files will be automatically controlled (and updated in real-time) based upon their roles: Team Members will get read+write access; Visitors will get read-only access.
There will be no need for users to manually adjust or manage permissions on any files: Kerika will provide a great contextual layer on top of the cloud storage platform.
Box has another great advantage: it doesn’t have its own proprietary format for storing Word, Excel, etc. This is a big issue for many enterprises who would like to use Kerika, but don’t want to move away from Microsoft Office format.
If we can the great Kerika user experience, with an enterprise-class cloud service, and the convenience of Microsoft Office, we think we will have a winner on our hands!
So, from a technology perspective a Kerika+Box integration makes a lot of sense. But what about from a market perspective?
When we polled some of current and prospective customers, however, the reaction was somewhat mixed:
Folks who were knowledgeable about Box were very supportive. (Good!)
Folks who were already using Box were very enthusiastic. (Excellent!)
Unfortunately, too many people still haven’t heard about Box… (Not so good…)
Box’s biggest challenge at the moment is name-recognition: far too many folks we talked to confuse Box with Dropbox.
The name confusion vis-a-vis Dropbox is a pretty big issue that we are betting that Box can ameliorate on its own, and Box’s pending IPO should certainly help with gaining greater name recognition and a more distinctive personality in the marketplace.
We are also hoping to build good partnerships with Box resellers, like our friends at cloudPWR, who have long-standing relationships with enterprises that would be great candidates for Kerika’s work management tools.
(The fourth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)
As we noted in our last post, our initial preference was to add Dropbox as our second cloud platform. We had personal experience of using Dropbox ourselves, mostly to synch files across multiple personal computers and devices, and to a much more limited experience we had tried using it for collaborating with partners, mostly to share large graphics and video files.
(Particularly in the early days of Google Drive, there were limits on file sizes we would bump against, and high-resolution video files can easily be very large.)
By itself Dropbox doesn’t really provide any collaboration features: there is no contextual overlay on it, like Kerika provides on top of Google Drive. The best use-case for Dropbox is still that envisioned by Drew Houston’s original mockup video: if you use multiple computers a regular basis, e.g. a desktop and a laptop, and you need to make sure your working files are always available on all these machines.
(The key phrase here is “working files”: using Dropbox as a “system of record” — for files that have been finalized, frozen or otherwise are in an archived state — seems less useful. Archived files can very quickly grow in size to hundreds of gigabytes, making Dropbox a prohibitively expensive solution.)
To learn more about Dropbox, we began by attending their DBX conference in San Francisco last summer.
DBX turned out to be a startlingly extravagant affair — it made us feel quite the country bumpkins since we can’t envision any Seattle-area startup spending so lavishly on a single day’s conference! But, it was also an excellent opportunity to meet some of their engineers particularly from their Platform Team, and to understand better Dropbox’s API and product direction.
We immediately ran into a major hurdle: it appeared that Dropbox’s API offered no way for third-party apps to create and manage nested folders.
We didn’t get discouraged immediately, since we did have an opportunity to talk to folks from their platform team.
We put together a detailed presentation on why it made sense for Dropbox to extend their API; and we supplemented this with a mockup video showing exactly how this could result in a great integration of Kerika+Dropbox, similar to what we had achieved with Kerika+GoogleDrive.
(This video hasn’t been released publicly.)
Some folks in the Dropbox platform team were clearly interested in what we presented, and felt that it presented an interesting direction for the platform to take, in order to be more competitive in the enterprise space. However, it was clear that the Dropbox API product roadmap was full up for the foreseeable future, and we were unlikely to find the platform capabilities in Dropbox that we were looking for.
It was disappointing, but not a show-stopper for us: while considering the technical strategy for a Kerika+Dropbox integration, we had also been sounding out some of current and prospective customers to see how enthusiastically they would welcome such a product, and we were getting mixed feedback: on a personal level, most folks liked Dropbox, but at an enterprise level there was much less enthusiasm.
Part of the problem may have been simply perception: Dropbox was viewed very much as a consumer product, and enterprise IT may have reflexively dismissed it as lacking in security, enterprise management, etc.
We did, however, find that some of these folks were suggesting we consider a different platform as an alternative to Google Drive: Box…
