Michael DeAngelo, Deputy CIO for the State of Washington (and a long-time user of Kerika :-) gave a talk on Lean & Agile Government in Washington State, at the Beyond Agile meetup in Kirkland last week.
Here are his slides:
We will shortly be uploading another presentation, on Agile QA, as well an edited video of his entire talk.
You can attach as many canvases as you like to cards on Task Boards or Scrum Boards, and if you don’t need them anymore, you can delete the canvases.
Here’s how you add a canvas to a card:
By default, the new canvas is simply called “Canvas”, but like with any other attachments on a card, you can easily rename it by clicking on the pencil icon that appears to the right when you hover your mouse over it:
Clicking on the “x” button at the far end will let you delete a canvas that you no longer need:
If the canvas is empty — which means that there is nothing visible on the canvas, and nothing in the canvas’ Trash either — you see a simple confirmation message asking if you are sure you want to delete it:
But, if the canvas is not empty, you see a Restore option instead:
If it seems puzzling why a canvas that appears empty isn’t really empty, make sure you open the canvas and take a look at the Trash: there may be items there that you had previously removed from the canvas:
In this example, above, the canvas looks empty but isn’t really: there are items in the Trash.
In situations like this, Kerika is careful to avoid losing all your work: until you empty the Trash on a canvas, the canvas isn’t considered to be truly empty, and until a canvas is truly empty, it cannot be removed from a card.
So, in this example, you see the Restore option rather than the Delete option:
Michael DeAngelo, Deputy CIO for Washington State and long-time Kerika user, will be speaking on “Lean Government” in Kirkland on June 24: how the Office of the CIO has been pioneering the adoption of Kanban, Scrum and “holocracy” within the state. Check it out at http://www.meetup.com/BeyondAgile/events/222991832/
Some techies in Seattle may like up to 50 shades of grey, but at Kerika we try to stick with just three:
This is easier said than done: there’s a lot of grey in the Kerika user interface, and as we add new features or tweak old ones, it’s easy to slip and introduce new shades of grey.
So, periodically, we need to take digital color meter and examine the Kerika UI in detail, pixel-by-pixel, to look for stray shades of grey.
Limiting the palette of grey to just 3 shades is an example of how constraints can help designers.
Kerika’s Scrum Boards look a lot like regular Task Boards (which you can use for Kanban-style) work; the main difference is that each Scrum Board can share a backlog with other Scrum Board.
(And switching between a Task Board and a Scrum Board takes just one mouse click!)
We were doing some fairly complicated bookkeeping when people added tags to their Scrum Boards, and we decided it was getting messy both for the system and probably the users as well.
So, we are simplifying tags for Scrum Boards:
The effect of all this is to ensure consistency of your tags taxonomy across all Scrum Boards that share the same Backlog: this will make it easier to pull cards from that Backlog into any Scrum Board and know that you will automatically get all the right tags set up for you by the system.
We try to be consistent in our use of colors and shades throughout the application, although it is easy to slip up from version to version, particularly since we do so many releases a year.
One recent diversion we corrected was in the use of the color blue: we have a specific shade we call Kerika Blue (#0099CC) which is used to indicate the concept of “new”:
Kerika Blue is more muted than the regular blue that you might find elsewhere: we generally try to keep our color scheme muted, so that the decoration of the Kerika app doesn’t compete with your data — after all, your data are far more important to you than anything we do in terms of decorating your screen ;-)
All of Kerika’s servers, which run on Amazon Web Services (AWS), operate within a Virtual Private Network (VPN), so they can be configured to only listen on local ports, e.g. ports like 10.0.0.1, etc.
This means that they cannot be accessed directly from the Internet: instead, all connections are routed through an Elastic Load Balancer (ELB), which is a special kind of AWS server that handles connections from all users.
The ELB is very secure: it implements SSL 2.0, and when vulnerabilities like Heartbleed and POODLE are discovered, it is relatively easy for us, with Amazon’s help, to quickly ensure that the the ELBs are patched. Patching the ELBs quickly gives us breathing room to patch all the other servers involved, particularly if vulnerabilities are found at the platform level itself.
But, running a VPN isn’t enough: while it blocks people outside the Kerika server environment from directly accessing our database, there is still — at least a theoretical possibility — that an attacker can find his way inside the VPN, and then try to connect to our database server on a local port.
To avoid this scenario, we use SSL within the VPN as well, so that the connections from the load balancers to the database servers are also authenticated and encrypted.
We found and fixed a bug related to our Whiteboards: it turned out that when you copied a bunch of items on a canvas, e.g. some shapes, documents, etc. that you had connected together with some lines or arrows, these weren’t always getting pasted properly when you did a copy–and-paste.
Our apologies for any inconvenience you may have faced.
We found a weird bug related to the export feature for Task Boards and Scrum Boards that affected users of Kerika+Box, and it has to do with the way Box keeps track of user names that’s different from the way Google keeps track of user names.
Both Box and Google ask for your first name and last name when you sign up, but their content APIs — the programming interfaces that Kerika uses — differ in the way they provide these names to Kerika.
Google gives us the first name and last name separately, e.g. it would tell us a user’s first name is “Arun” and his last name is “Kumar”.
Box, however, gives us both names together, as “Arun Kumar”, and this presents a problem because we can’t always figure out what the last name is.
And, by the way, given the wide range of cultures represented by our users, it’s far from easy to guess which part of a name is the “last name”.
For example, consider Latin American name like “Maria Beatrice Fernandez Rosario”. Here, the last name is probably “Fernandez Rosario”, but we can’t be sure.
The bug showed up when people did exports, by appending “null” to the name — basically this meant Kerika didn’t know what the last name of the user was, and simply tagged it as “null” (which is computer-speak for “I have no idea”).
We have fixed this.
We found a scenario where your Scrum Board could end up with duplicate tags. Let’s say you had a Shared Backlog which had some tags, and you also had a Scrum Board Template that had some similar tags.
If you created a new Scrum Board using that Backlog and that Template, you could have ended up with some duplicate tags, which is not at all helpful.
We have fixed this.