I will be presenting on Implementing Agile across Distributed Teams at the Lunch & Learn Agile event on October 2, 2014 at the Office of the CIO for Washington State.
The event is being organized by Cayzen Technologies; if you are interested in attending, please contact Mayra Pena.
Ben Vaught, from the Washington State Office of the CIO, and I had the pleasure of presenting at the state’s Office of Financial Management’s Fall Forum last week, held over two days at the Thurston County Fairgrounds in Olympia.
Ben talked about the use of visual processes as part of the Washington Business One Stop initiative he has been working on for a while, and towards the end of his talk he showed some pictures of the WIKISPEED garage in Lynnwood, where I first met Ben and Michael DeAngelo, Deputy CIO for the state.
My talk was supposed to have been on Visual Management in government and administrative processes, but seeing pictures of the old WIKISPEED garage, which used to be covered with stickies on all walls (including the massive garage doors!) before the team adopted Kerika to knit together their global community of volunteers, was a wonderful throwback moment!
When it came to my turn, in addition to showing the use of Kerika for cross-agency GIS projects, such as those led by Joy Paulus, I was also able to show examples of Kerika in use by Sherri Hrubi, Danica Ersland and Melissa Wideman, who all work together in OFM’s HR Division.
Several other people presented, including Irene Hill and her design team from the Department of Licensing, Howard Cox from the Department of Enterprise Services, and Eric Gardner from OFM’s Forecasting Division.
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.
Between 9AM and 11AM Pacific Standard Time, Google’s authentication service threw up about about 60 errors, which gave many of our users a rough ride.
The problem was that Google’s authentication servers were timing out repeatedly, showing errors like this:
Request URL: https://kerika.com/authcallback/google?code=XXXXXXXX
Request Method: GET
Status Code: 504 Gateway Timeout
There isn’t anything we can do in this situation to help our Kerika+Google users, unfortunately, since Google’s authentication service needs to be up and running in order to log in to Kerika.
The silver lining in this cloud, for now, is that this is a relatively rare occurrence.
Kerika has had a “Max Canvas” mode for a while: if you click on the green square button at the top of a task board, your view of the board would expand to take up the full browser space:
This was handy when you wanted to work on just one board: your view of that board filled up the available browser space, and you weren’t distracted by the rest of the Kerika “chrome” (i.e. the application’s menus and buttons).
What we found, however, is that most of our users work on several boards at the same time: they have boards that they created for themselves, e.g. personal Kanban Boards, as well as Kanban and Scrum Boards that their colleagues had created.
So, in reality, most people need to achieve several goals simultaneously:
To make all of this possible at the same time, we have improved our Max Canvas view, by adding a button that makes it easy to switch between different boards (including your Home Board):
To the left of the Max Canvas button is a new Tab Switch button: clicking on it shows you a list of all the currently open Kerika boards, and this lets you quickly switch to another board without having to leave the Max Canvas view.
This view is smart: if a board has unread updates, it’s entry shows up in orange, consistent with how we let you know that you have unread updates anywhere in Kerika.
And if a board has overdue cards, it’s entry shows up in red, as with “Sprint 43” in the example shown above.
The Max Canvas view also has a Search button built into it, so you can do searches without existing the Max Canvas view:
All of this makes the Max Canvas view of Kerika much more useful than it was before, and it’s all part of our grand strategy to make Kerika more useful on iPads!
With our newest update to Kerika, we have introduced a more elegant way to show colors on cards.
The old method we employed filled in the top of each card with a selected color (which was white, by default). Here’s an example:
There were a couple of design problems with our old approach:
And, to be blunt, it was excessive: the colors tended to dominate the board’s view, to the point of being distracting.
Our new design is more subtle: it lets you see the colors without calling too much attention to them:
Now, the colors appear in a “dog-eared” style, which gets them out of the way while still making it easy to see if a card is colored.
This new approach will also make it easy for us to add more color choices in the future and, in particular, to add darker and more vibrant shades, since we will no longer have to worry about having sufficient contrast with black text overlaying the colors.
Our newest update to Kerika serves up a rather long list of changes; the two big areas for improvement were:
The OAuth 2.0 upgrade and iPad improvements are described in previous posts; here we want to highlight some of the other changes and improvements we made with this new version:
In addition to being less distracting, this new design will enable us to expand the palette of colors we can offer: the old design restricted us to only the lighter pastel colors.
In terms of infrastructure and other under-the-hood improvements, we have expanded our use of JUnit automated tests and done a bunch of bugs fixes, as usual.
There’s a lot of improvements being done on Kerika, and at a very fast rate. Make sure you subscribe to our blog to keep up!
With our latest version, we will be using OAuth 2.0 uniformly across all the ways you could sign up for Kerika:
Across all these, we are now using OAuth 2.0: the more modern, robust implementation of OAuth which lets you sign into Kerika using a Google or Box ID, without Kerika ever seeing your password!
(Background: while we were using OAuth 2.0 for people who signed up directly at Kerika.com, we had OAuth 1.0 in place for people who signed up through the Google Apps Marketplace, and we needed to make every pathway consistently work with OAuth 2.0 and completely get rid of OAuth 1.0)
This new version will affect all premium users of Google Apps:
With the old (OAuth 1.0) integration with Google, it was possible for individual users who had the premium version of Google Apps to sign up for Kerika.
With the new (OAuth 2.0) integration, the Google Apps Administrator for the domain (i.e. your company) to authorize Kerika for the entire domain.
In other words, if you are a premium user of Google Apps, your Google Apps Admin — typically someone in your IT department — will need to authorize Kerika for your domain before you can use Kerika.
This will affect you even if you are an existing user of Kerika.
The good news is that once your Google Apps Admin authorizes Kerika for your company’s domain, it won’t be necessary for individual users to authorize Kerika any more: it becomes much easier for your colleagues to sign up.
OK, so our website has long stressed the word “unlimited”, and maybe that’s not such a great idea…
Most people have boards with a few dozen cards.
Some folks have boards with a couple of hundred cards.
Very few people have boards with up to 1,000 cards.
It turned out that one of our users had a board with nearly 4,200 cards, of which over 4,000 were in the Trash.
And that’s not good! A board with several thousand cards on it is going to take a long time to load, because each card has many different attributes to it: details, chat, assignments, status, history, etc.
And when someone with a very large board uses Kerika, this can cause very unexpected loads on the servers, particularly in terms of network I/O and CPU utilization.
This is what it looks like when someone suddenly opens a board with thousands of cards on it:
We have talked about this before, and now we need to do something about it…
Most of the time, boards get very big because they are very old: stuff piles up in the Done column, or, as in this case, in the Trash column.
Having very large boards can impact performance: unlike, say, email which you may be accustomed to leaving piled up in your Inbox for years on end, Kerika’s cards are “live object”: even when a card is in the Done or Trash columns, it is constantly listening for updates from the server, because it could be moved out of Done or Trash at any time by someone on the team, or have some of it’s attributes changed.
For example, even though a card is “Done” or “Trashed”, it could have its details updated, or new chat added to it.
This is different from email messages, which are essentially “dead objects”: once you get an email and read it, it doesn’t update after that, so it can sit for years in your Inbox without trying to get fresh updates from the mail server.
So, when you have 4,200 cards on a single board, you have that many live objects trying to get updates from the server at the same time, and that’s not good for your browser or our server!
(Imagine your laptop trying to read and display 4,200 emails at the same time, and you will get an idea of the problem…)
Having very large boards is not a good idea from a workflow or process management perspective, and so perhaps Kerika needs to do something about it: we need to think about how we can help our users improve their workflow, while also avoiding these CPU spikes.
A couple of ideas that we are considering:
We have a great new Export feature for all Task Boards (i.e. Kanban Boards) and Scrum Boards.
The Export feature is simple, elegant and powerful, and is available to all Project Leaders, Team Members and Visitors on the project team.
To access this feature, simply click on the Project Info button that’s shown at the top-right of each Kerika Board, and you will see the Project Info display (that we have talked about in an earlier blog post):
CSV format is useful if you want to want to take data from Kerika and put it into Excel or some other analysis tool;
HTML format is useful if you want to print material from Kerika, or insert it into Word, PowerPoint or similar tools.
With both CSV and HTML exports, hidden cards are not exported: this means that if you are currently choosing to hide some columns (by using the Workflow button), or hide some cards (by using the Tags filters), then the cards that you are not viewing right now will not be part of the export.
When you export a board in CSV format, you get the following data, for each visible card:
Column Name: e.g. Backlog, In Progress, Done, etc.
Card Name: e.g. “Create PR news release”.
Card Description: e.g. “We need to create a PR news release once our latest version is ready…” (Rich text will be converted to plain text, since CSV files can only deal with plain text.)
Status: e.g. Needs Review, Needs Rework, etc. (If the card doesn’t have a special status, “Normal” will be shown.)
Due Date: the date the card is due, if a date has been set. (If the card doesn’t have a Due Date, “Not Scheduled” will appear.)
Assigned To: a list of names of the people the card is currently assigned to. (If the card isn’t assigned to anyone, “Not Assigned” will appear.)
Exporting could take a while: the exported data are put into a file in your Google Drive or Box account — depending upon whether you are using Kerika+Google or Kerika+Box — and when the process completes, you get an email with a link to the file containing your data.
It’s a similar experience if you do a HTML export; however the format of the data is different, giving you an indented set of attributes for each card, like this example from a Kerika+Box project:
One caveat about exporting HTML: if you open the results in Google Docs, Google shows a preview of the output, and that doesn’t look good: instead of rendering the HTML, Google actually exposes it.
Here’s an example from a Kerika+Google project:
The export feature can be used for many different purposes, of course: the most common scenario we envision is people wanting to include material from Kerika in their analysis and presentations.
And, of course, one use would be for government agencies that have to respond to Freedom of Information Act (FOIA) requests, or other Sunshine laws.