We have a new feature in Kerika: a simple way to add numbers to your cards, for both Task Boards and Scrum Boards.
Project Leaders (and, of course, the Account Owner) can access this feature by clicking on the Project Info button, which appears on the top-right area of a Kerika board:
Settings
Auto-Numbering can be turned ON or OFF at any time.
It is a simple feature, intended primarily to help manage large numbers of cards on a single board, e.g. a Help Desk team using Kerika as a ticket management system.
In ticket management or asset tracking scenarios, the titles of many cards may be similar, e.g. “User has trouble logging in”.
A more useful way of distinguishing between cards might be through the card’s numbers, e.g. “104 User has trouble logging in” and “242 User has trouble logging in.”
When Auto-Numbering is turned ON, Kerika will automatically insert a number as a prefix to new cards that are added to that board.
Numbers are sequential: for example, the first card would have “1” added as a prefix, the second card would have “2” added as a prefix, etc.
Auto-Numbering can be stopped at any time, and then new cards added to the board won’t have numbers added to the card titles.
Auto-Numbering can be resumed after a pause, the numbering will intelligently figure out how many cards are on the board by excluding the Backlog and the Trash, as well as looking at the last number used.
The numbers are simple text, added as a prefix: they can be edited by any Team Member, and even removed.
Most users work on private projects: i.e. projects that are accessible only to people added to the project team.
But some folks find it useful to have their projects viewable by everyone, typically because they are working on nonprofit causes, like WIKISPEED.
WIKISPEED publicizes its projects because it helps attract new volunteers to their cause, and this is actually a pretty smart way for nonprofits to showcase their work.
Kerika has always had an option for people to have all their projects made viewable by the public, but even nonprofits, for example, may have some Kerika boards that they don’t want to share with the rest of the world.
Well, with our newest release, it is possible for the Project Leader (or Account Owner) to make individual projects open to the public to view.
A project can be easily switched from Private to Public, and back again, using the Project Info button that’s available on the top-right of every Kerika board:
Privacy
The privacy choices are as follows:
Only the project team can access: this is the default setting, and it means that unless people are added to the project team, they won’t be able to view it — or even find it using the Search function.
Anyone, anywhere can view: this means the project is “public” — it can be found through search, and anyone who knows the URL of the project can view it. (But, they still won’t be able to make changes.)
When a project is made Public, all the documents contained within it — on all the cards and canvases that make up that board — are also made viewable to the public.
This means, for example, that if your Kerika+GoogleWhiteboard or Task Board is made available to the public, all the documents in that board’s Google Docs folder are also made viewable by the public.
(And Google indexes all public Google Docs, the project could be found in more than one way, depending upon who is searching for it.)
One caveat: users of premium Google Apps, e.g. Google Apps for Business, cannot make their projects open to the public, because of limitations imposed by Google.
You may know already that Kerika’s patented canvases are a great way to share your ideas and content, like drawing process flow diagrams, flowcharts, etc., and these canvases can also include content from your laptop or the Web.
For example, you can drag-and-drop a file from your desktop, and it will get added to your Kerika canvas, and stored and shared automatically with your team members using Box or Google (depending upon whether you are using Kerika+Box or Kerika+Google).
When you add Web content to a canvas, Kerika is pretty smart about figuring out what that URL is that you just provided.
So, for example, Kerika makes it really easy to add a Twitter feed: all you have to do is click on the “+Web Content” button on your canvas toolbar…
Adding Twitter feeds to a canvas, step 1
You can add a Twitter feed simply by using the user’s Twitter handle, e.g. “@kerika” would give you Kerika’s Twitter feed right on your canvas:
Between the hours of 9AM and 11AM PST, Google’s authentication service — which we used to sign in users of Kerika+Google — kept having problems that affected people at random.
It was a tough morning for us, dealing with the flood of “504 System Timeout” errors coming back from Google, and feeling helpless that we couldn’t provide the kind of high-quality user experience that is at the core of the Kerika brand.
The problems finally went away by themselves, but a total of 31 Kerika users were affected and we are reaching out to each of them individually to apologize for the inconvenience, and explain what happened.
This is one of those situations where Kerika cannot do anything to fix the problem: if you signed up as a Kerika+Google user, when you try to login to Kerika you are automatically redirected to Google’s authentication service, which then comes back to Kerika to give us your identity information.
Then, we use the identity information to log you into the correct Kerika account.
Normally, all this happens really fast: you click on the Sign In button at Kerika, Kerika redirects your browser to Google, Google responds immediately, and within a couple of seconds you are logged into Kerika.
It all happens so fast and smoothly, 99.999% of the time, that most people are completely unaware that their browser was even redirected to Google in the first place — it’s something you might notice only if you have a very slow WiFi connection, and you are paying close attention to your browser’s status bar.
But every once in a while, Google won’t respond when you get redirected there by Kerika. In that case we retry again several times, and then finally Kerika does a “timeout”: it gives up.
(This problem has happened before, and as software developers ourselves, we are, of course, very sympathetic to other software companies that experience occasional bugs and hiccups, but Google can be irksome in their lack of transparency.)
This happens so infrequently that we didn’t really have any special code in place to tell users why they were not able to login, but that’s going to change starting tomorrow: if Google’s servers are not responding fast enough, we will show a special page to the user explaining what’s happening, so they understand the situation better.
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.
