Adding a Twitter feed to your Kerika canvas

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
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:

Adding a Twitter feed to a canvas, part 2
Adding a Twitter feed to a canvas, part 2

And that’s all it takes!

 

Lunch & Learn Agile, for State Government Employees

Cayzen Technologies organized a Lunch & Learn Agile event at the Harbor House at Percival Landing in Olympia, Washington, featuring Arun Kumar, CEO of Kerika.

Arun’s topic was Implementing Lean across Distributed Teams, and we would like to specially thank Mayra Pena from Cayzen who organized the event:

Arun Kumar & Mayra Pena
Arun Kumar & Mayra Pena

The event was attended by folks from Washington State’s Employment Security Department and Department of Health, among others, and there was a lively discussion.

Here are the slides from that presentation:


If you would like to see the sample Kerika board that featured in the demo, go to https://kerika.com/m/H51M

Thanks for attending!

Arun speaking at Lunch & Learn Agile
Arun speaking at Lunch & Learn Agile

Work-In-Progress Limits: a new Kerika feature!

We are thrilled to announce a great new feature: Work-In-Progress (WIP) Limits for Kanban Boards and Scrum Boards.

WIP Limits are a very helpful tool when you are working in a true Kanban style: where work gets “pulled” as people become free, rather than work getting “pushed” onto people before the people ready.

To understand the difference between “push” vs. “pull”, think back to that famous episode of “I Love Lucy” where Lucy and Ethel take up jobs at a chocolate factory, and quickly find themselves unable to keep up with all the work that’s getting pushed onto them:

This is a perfect example of the perils of “push”: as the chocolate gets prepared upstream, the work becomes ready even though the people aren’t ready for the work.

If you push work on to people who aren’t ready to take it on, you will quickly have disastrous results. (It’s funny only when it’s on TV and it involves Lucy.)

At the very least, you will have an imperfect understanding of what each person is actually doing, if people upstream in the project’s workflow simply push work downstream as soon as the upstream folks are done with it.

A pull model is different: people “pull” work and assign it to themselves when they are ready.

Each person typically has a small number of items they are juggling at any time: it may be as few as two items, depending upon the complexity of the work, but it is rarely as few as just one item.

(You nearly always want to have one “background” task ready to be picked up whenever your “foreground” task gets blocked for any reason.)

When a person is able to take on a new task, she can “pull” a card from the column to  the left of her on a Kerika board.

Here’s a simple example, reflecting the workflow for a software project:

WIP Workflow Example
WIP Workflow Example

This project includes people with different roles: designers, developers and QA, and each group has determined it’s own WIP limits, based upon the team’s capacity and velocity.

In this particular example, we can see that the Planning & Design and Deployment columns have currently exceeded their WIP limits (and, in the case of Deployment, by a large margin!)

When this happens, Kerika alerts you to the condition by showing the affected columns with red text in the column headers:

Example board with WIP exceeded
Example board with WIP exceeded

WIP Limits as “soft limits”: Kerika doesn’t stop you from exceeding a column’s WIP Limit, but it does provide a very clear, visible warning to everyone that a bottleneck is about to form.

When bottlenecks start to form, the Project Leader should intervene and help manage the upstream flow so that the WIP Limit can come back to its acceptable amount.

WIP Limits originated in Kanban, but Kerika lets you use them for Scrum Boards as well!

To use WIP Limits, click on the Project Info button that’s at the top-right of the Task Board or Scrum Board:

Settings
Settings
  • WIP Limits can be set for every column on a board except for the Backlog,  Done, and  Trash.
  • WIP Limits can be turned ON or OFF at any time: turning WIP Limits OFF doesn’t cause the old values to be forgotten.

Pretty cool, huh?

Using Kerika for a subset of your Google Apps domain

We had a couple of users write in this week, saying that they were having trouble re-authorizing Kerika for their Google Apps domain following our recent upgrade to OAuth 2.0.

In both cases, it turned out that the Google Apps Admin had previously authorized Kerika only for a subset of their Google Apps domains, i.e. for an Organizational Unit (OU).

Even when the OU has been set up to override the master settings of the domain, Google seems to be giving us an error (specifically, our server is told by Google’s authorization server that “domain policy checking failed” — this is the check that we do to see if the Google Apps domain is authorized.)

The simple fix is to authorize Kerika for the entire domain rather than a subset of users.

Naturally, our users wonder if this means they need to license all of the users registered within their entire Google Apps domain: the short answer is “No” — you need to license only those people who are actually using Kerika.

So, don’t worry about getting stuck with a big bill simply because you authorized the use of Kerika within a large Google Apps domain: all you are doing is making it easy for your colleagues to try out Kerika.

If they try out Kerika and like it, we can talk about licensing then…

No, not Shellshocked

The announcement by CERT yesterday that there is a vulnerability in the Bourne Shell (more commonly known as “bash”) wasn’t great news for anyone running any variant of Unix, which includes Linux and MacOS.

Linux is very widely used for modern Web servers, particularly those running on Amazon Web Serviceslike Kerika does.

There are a number of variants of Linux out there, which makes things a little harder whenever a vulnerability is announced: you have to make sure your particular variant of Linux is patched quickly.

Luckily, this problem was fixed as fast as the notorious Heartbleed bug: within a couple of hours of the report of Shellshock, Amazon and Google (and, most likely, every other cloud services provider out there) started installing patches, and so the Software-as-a-Service (SaaS) world got back into good shape very quickly.

In our own case, we use Ubuntu Linux, and they were equally swift in issuing a patch for Shellshock which we installed yesterday.

On a side-note, we are less enthusiastic about Apple’s announcement that “the vast majority of users are not at risk“.

That’s true only in a literal sense: the vast majority of Mac users don’t ever use the Terminal program to access the shell, and a lot of permissions on Macs are locked down by default (and most users never bother exploring all their administrative privileges).

But, in a practical sense this bland statement from Apple understates the actual risk faced by Mac users: a significant majority of startups use Mac for their software development, which means a critical set of Mac users are still sitting exposed!

The sooner Apple fixes this bug, the better is will be for the startup world.

How to install Kerika on a Google Apps Domain

Since our last released, when we upgraded our integration with Google Apps Marketplace to use the OAuth 2.0 protocol, a number of folks have written in to ask about how they should install and authorize Kerika for their premium Google domains (i.e. Google Apps for Business, Google Apps for Nonprofits, etc.)

Here’s a step-by-step guide for the Google Apps Administrator in your organization:

First, login to admin.google.com with your Google ID. Your screen will look like this:

Google Admin Console
Google Admin Console

On the right side of the screen, you will see a link for Google Apps Marketplace, in the area marked Tools:

Go to Google Apps Marketplace
Go to Google Apps Marketplace

When you click on the “Google Apps Marketplace” link, you will be presented with a search box that looks like this:

Searching for Kerika
Searching for Kerika

Type in “Kerika” in the search area, and you will find us!

Adding Kerika
Adding Kerika

Once Kerika shows up, click on the blue “Install App” button:

Installing Kerika
Installing Kerika

Click on the blue Continue button, and you will be asked to authorize Kerika for your Google Apps domain:

Authorizing Kerika
Authorizing Kerika

And that’s it! Your final confirmation message will show:

All Done
All Done

And at this point Kerika will have been authorized for your entire Google Apps domain. Individual users will be able to sign up without going through any of this hassle.

If you have any difficulties or questions with this, please email us at support@kerika.com