For most people, the choice of whether to use Google or Box is often made by their employer, whose IT departments may have already developed a cloud strategy for their organization.
For a small number of people, particularly those in organizations that haven’t committed to a particular cloud strategy yet, they do have the choice of using either cloud service, or even both.
So, what happens if you have the same email address, e.g. email@example.com, and you set up a Google ID and a Box ID that use this same address?
You could end up with two different Kerika accounts that use the same firstname.lastname@example.org ID: that’s because each sign up, from Google and from Box, takes a different path into Kerika.
This is not a great situation to be in, and we certainly don’t recommend it, but the software does try to behave well when confronted with this situation.
If another Kerika user invites you to join her project team, the invitation will show up in both your Kerika+Google and your Kerika+Box account — and in your email, of course — but when you try to accept the invitation Kerika will check to make sure you are logged into the correct service.
Here’s an example: Jon, who uses Kerika+Google, invites Arun to join one of his projects. Arun happens to have both a Kerika+Google account, and a Kerika+Box account, but Jon doesn’t know that — and he shouldn’t have to care, either!
When Arun sees the invitation, he happens to be logged into his Kerika+Box account:
But when he tries to accept the invitation, Kerika checks to see whether Arun and Jon are both using the same cloud service, and discovers that Arun is logged into his Kerika+Box account and not his Kerika+Google account:
So, Kerika works behind the scenes to help Arun sort out his two accounts.
We would love to get your feedback on the Kerika app; one way, of course, would be to contact us directly at email@example.com, and an even better way would be if you could post a review of Kerika on the Chrome Web Store.
Here’s a step-by-step guide to posting a review of an app on the Chrome Web Store. (Of course, it’s going to be useful only if you use the Chrome browser, not if you use Internet Explorer, Safari or Firefox.)
We are often asked how the Kerika team itself uses Kerika, and we freely share this through demos we have done in person for potential customers and at various events. For those who we haven’t met in person, here’s a blog post instead..
1. Kerika runs on Kerika.
Pretty much everything we do, from the smallest, tangential effort to our main product development is done using the Kerika software.
(It shouldn’t surprise you to hear that, given that we are a distributed team ourselves — spread out between Seattle and India.)
2. No email, limited phone calls
In fact, we gave up using internal email back in Dec 2013. (Email sucks, and Kerika is the smarter alternative to spam.)
Because our team is spread out over 10,000 miles, we do occasional phone calls, using Skype or Google Hangouts, to discuss product strategy, but we don’t have daily phone calls as a matter of routine.
We have a phone call only when there is something substantial to discuss, never to catch up on routine status. In other words, all our phone conferences are about interesting topics, like “What do you think about this idea…?” or “I met a customer today who brought up this problem…”; never about “Where are you with Task X?”.
Kerika keeps us in perfect sync across these 10,000 miles on all matters of routine status and project management, so our phone calls are all strategic in nature.
3. Scrum for Product Development
We work with a 2-week Sprint Cycle for the most part, although we have occasionally deviated from this — never with great results, so sticking to the cycle is usually a good idea!
We capture all of our product ideas and feature requests in one large Scrum Board, which we call, simply, Product Planning.
This board organizes our ideas into various buckets, like Valuable for Enterprises and Valuable for Individuals:
You might notice that the Backlog column is relatively small: only 54 items. That’s because not everything in the other buckets is ready to go into the Backlog, either because a feature isn’t well defined enough, or it isn’t considered important enough to deal with in the short-term.
(We have a lot of ideas that sit and gestate for months, even years!)
It’s also worth noting that the Trash contains 62 items: this means we reject as many ideas as we pursue!
4. A Shared Backlog
As ideas for various features get prioritized — and, more importantly, defined clearly enough to be analyzed in detail by our developers — they get moved to the Backlog.
(And, by the way, the screenshot above is from a Kerika Whiteboard that we use to map out our product planning process.)
Each Sprint is organized as a separate Scrum Board, pulling items from the common Backlog.
As items get done (or not, as the case may be), the Backlog slowly shrinks over time.
But, as ideas for new features gets firmed up on the Product Planning board, this keeps feeding more stuff into the Backlog. So, the net result is that our Backlog has remained the same size for years: about 50-60 items.
We have been doing this for a while now, and are currently wrapping up Sprint 55, with each Sprint taking at least 2 weeks, and several taking 1 month to complete.
Here’s an example of one of our Scrum Boards:
5. Kerika’s Smart Notifications
So, if we are a distributed team that doesn’t use email, and not that much phone either, how do we keep up with what’s happening? The answer is: Kerika’s smart notifications help each of us easily keep track of changes taking place across literally hundreds of cards each day.
Here’s an example:
At a glance we can tell that this card has
Has a new due date
Has new attachments
Has new (unread) chat messages
And, unfortunately, needs rework
These smart notifications replace dumb email with a much more efficient mechanism for keeping everyone on the same page.
6. The Development Process
If we open up one of these cards, we can get a glimpse of the Kerika development process. Let’s start with the chat thread on this card:
This chat shows a typical interaction between a junior developer and a technical lead: after writing the code for a particular feature, the developer has passed it on to the tech lead for code review.
The code review itself is attached to the card, as an attachment:
For each feature we develop, our engineers create a small work plan that outlines their design thinking.
This design/work plan is a critical artifact for good software development: it ensures that people can review the work more easily and effectively, and it also provides a reference for the future — if ever a bug is found in this particular feature, we can go back to the work plan to see where the design flaw may have originated.
The code review is typically very short, and attached (in this case) as a Google Doc:
7. Card History
Each card in Kerika keeps track of its own history, which makes it easy for a distributed team to keep track of everything that happened. Frequently, a number of changes may have taken place on a single card during a workday, and someone who is 10,000 miles away is also about 13 hours away in terms of timezones, so the history feature is useful for understanding all the changes that took place when you weren’t looking.
So, that’s a typical card, on a typical board. And, in a typical 2-week Sprint Cycle, our development team handles 175-200 cards!
We love Kerika, not just because we have built it, but because it makes our distributed team so very effective!
If you have a premium (i.e. paid) version of Google Apps running in your organization, your Google Apps Administrator will need to authorize Kerika for your domain, before anyone within the organization can use Kerika.
Here’s step-by-step directions on how to do this:
1. Go to your Google Apps Admin console.
Go to http://admin.google.com, and log in as the Google Apps Administrator for your domain:
2. Click on the “Apps” button.
This is where you can manage all your Google Apps, as well as third-party apps like Kerika that integrate with your Google Apps:
3. Go to “Marketplace Apps”.
Google separates out its own apps from third-party apps, so you want to click on “Marketplace Apps”:
4. Click on “Add Services”.
All the apps you currently have installed for your domain will show up here (in this example, none have been installed so far); click on the blue “Add services” link:
5. Search for Kerika.
Search for “Kerika” in the Google Apps Marketplace:
6. Click on “Install App”.
Kerika’s entry will show up in your search results; click on the blue “Install App” button:
We have been one of the last jazzy Web apps out there that was still running on Internet Explorer 9, but that’s going to change: with our next release, due in a month or so, we will be asking Internet Explorer users to upgrade to IE10 or later.
The main reason for this change is that all “modern” browsers — and IE9 qualifies as “modern” only when it stands next to IE8 — do a lot of work within the browser itself that Kerika currently does: stuff like managing and manipulating the DOM structure of the Kerika application.
This means that the Kerika client-application — the bit that you actually see and use in a browser — is unnecessarily complicated, and somewhat slower, than it needs to be, because we are doing some work that IE10+, Chrome, Firefox and Safari all do within the browser itself.
Dropping support for IE9 will enable us to provide a faster user experience, with less complexity in the code.
We have a small Twitter following, admittedly, but for the most part it looks very relevant: folks who are (a) real, and (b) actually interested in collaboration, Lean and Agile.
The part about “real” may sound odd, but consider for a moment how many Twitter accounts are actually apps that post stuff automatically, with little or no human intervention in terms of what is read or what is written.
Something peculiar we noticed recently is that we would get notifications from Twitter say that the same person, say User X, was now following us: every 3 days or so, Twitter would tell us that User X is now a new follower of Kerika.
There are a bunch of “User Xs” out there: people who will follow you on Twitter not because they are interested in what you have been posting, but because they want you to follow them back, which increases their “social capital.”
Here’s one of our followers: a total of 26 tweets, yet she has 8,675 followers!
Whenever someone follows @kerika, we are happy to take a look at their Twitter feed in return, and see whether it would be worth following them in return: after all, we, too, want Twitter to be a good source of news and views.
But a lot of folks aren’t worth following for a bunch of reasons:
They just retweet stuff; they don’t write anything.
They are “real people”, but are clearly using software to find material for their Twitter posts, which is the same as saying they don’t write anything.
They are “real people” who don’t understand that Twitter isn’t the place to have a bunch of sidebar conversations: their Twitter feed consists mostly of cryptic asides to other users.
So, it kind of boils down to this: if you have original content to share, we would be delighted to follow you. It doesn’t have to be your own blog post; it could be that you are pretty good at finding stuff on the Internet that we might have missed ourselves.
We have found great news and opinion sites that are not very well known, thanks to Twitter, so folks who do actually curate the Web for us are always welcome.
So, what happens when we hear that User X is now following @kerika, take a look at User X’s own Twitter feed, and find it is mostly retweets and random articles?
We don’t follow User X back. User X then “unfollows” us, and retries a few days later to see if we will take the bait the second time.
We have seen some folks try this repeatedly over several weeks. We don’t know whether to find this flattering or just plain weird, and that’s assuming there is a real person doing this and not some app which blindly finds Twitter accounts to follow and then keeps track of which ones follow back.
Some of our Kerika+Box users have been complaining about the number of email notifications they get when new projects are created: this has to do with Box, rather than Kerika, but it’s helpful to understand what’s going on, and what you can do about it.
When you create a project in Kerika, Kerika creates a dedicated folder for the files that will be used in that project. This folder is shared with whoever needs access to that Kerika project.
Every Kerika user can set a personal preference: you can choose to share your new projects with your account team automatically when they are created, or just with people as and when you add them one by one to a Kerika project. By default, this is set to “share with account team” since this helps people discover new projects within their organization.
One downside of this: whenever you create a new project team, especially if it owned by a service account, a new Box folder will get created for this project and shared automatically with everyone who is part of that account.
This was resulting in way more emails than anyone wants to see, so we have made a change in the way we work with Box:
When people get added to a Box folder, through Kerika, they will no longer get an email notification.
However, the Account Owner will still be notified; there doesn’t seem to be any way around this.
Kerika is work management for distributed Lean and Agile teams