We were thrilled to be part of the Lean Transformation Conference organized by Results Washington week at the Tacoma Convention Center. Over 2,700 people attended — a sellout crowd!
Arun Kumar, founder & CEO of Kerika, gave a presentation on both days on Distributed Lean and Agile Teams in the Public Sector, drawing upon lessons learned, case studies and best practices from multiple state agencies and private sector firms.
Here’s the presentation:
A couple of weeks ago we visited a UX team at the Washington State Department of Licensing, and took a photo of the “Post-It Palace” they had built within their cubicles:
2 weeks later, this is what we saw:
Everything is now inside a set of Kanban Boards powered by Kerika+Box!
We are thrilled to announce a new feature in Kerika: a very useful Project Info display that summarizes of your project.
You can access this by clicking on the new Info button that appears in your Kerika toolbar, at the top-right corner of your board view:
This view is available to everyone who is part of the project team: Project Leaders, Team Members and Visitors.
There are several sections in here: at the top is the Name and Description of the project:
The Description is a new attribute of Kerika’s boards: it lets you provide context about the project that can help orient new team members, and it can also help with your Searches in the future.
The Name and Description of a project can be modified at any time by Project Leader or Account Owner.
Next up is the Summary of the project:
The summary varies by the type of board (Whiteboards, Task Boards or Scrum Boards), but it provides useful information in all cases:
Since each card typically represents a work item, this is a quick way to find out how much work remains on a board, without having to count up all the cards in each column.
For Task Boards and Scrum Boards, this view also shows you how many cards are due today, due tomorrow, and overdue.
And for Scrum Boards, it shows you how many cards are in the Backlog that you are using, so you get a sense for how far along you are with the overall project, not just the current Sprint.
All Kerika Task Boards and Scrum Boards now have support for Work-In-Progress Limits: these can be turned on or off by the Project Leader or Account Owner:
Another huge new change: we are making it super easy to switch a board from being a Kanban Board to a Scrum Board, and back again.
Task Boards and Scrum Boards also have a new auto-numbering feature that can help you manage very large boards, e.g. if you are using Kerika for an internal Help Desk.
For both Tasks Boards and Scrum Boards, there is now a great new Export feature that lets you export cards from a board in CSV or HTML formats:
And, finally, you now have the option to make individual projects open to the public to view (but not change): a handy feature for open-source and volunteer-based projects like WIKISPEED:
Arun Kumar, Kerika’s CEO, will present at the Washington State Office of Financial Management (OFM) Fall Forum, at 1:30PM on September 17, 2014 at the Thurston County Fairgrounds in Olympia, Washington.
The topic will be experimentation with Visual Management in government and administrative processes.
Come join us at the Washington State Lean Transformation Conference, to be held October 21-22, 2014 at the Greater Tacoma Convention & Trade Center in downtown Tacoma at 1500 Broadway Tacoma, Washington!
Arun Kumar, Kerika’s CEO, will present a special Breakout Session on One team, many places: creating collaboration networks for distributed workgroups
The vision of Lean Government is about collaborating across offices, across agencies, and even across sectors. In an era of flat or even declining budgets, it’s become essential to get Lean across the state, not just across the room.
The old technologies never really supported distributed Lean and Agile, but that’s all changed now: a new generation of browser-based work management tools makes it fast and easy to build Lean and Agile teams that connect professionals across agencies, and across sectors so that expertise from the private sector, academia, and nonprofits can be leveraged to deliver great results in Washington.
This breakout session will feature a look at some great cross-agency projects and cross-sector projects: initiatives that have succeeded in delivering in a way that was unimaginable only a couple of years ago.
The session will be presented at 12:15PM in Room 318 on October 21, and again at 10AM in Room 318 on October 22.
If you are working in state, county or local city government and are interested in Lean and Agile, be sure to join us: the cost for attending is just one can of food, which will be donated to a food bank 🙂
(The sixth, and last, in a series of blog posts on how you can make use of the status indicators on cards, in Task Boards and Scrum Boards.)
In our last post we talked about how to use the “Is blocked” flag; today, let’s take a look at “Done”.
“Done” is where you want to get to: it’s a special column that’s always to the right edge of every Task Board and Scrum Board.
(You can always chose to hide the Done column, of course, just like you can hide every other column on the board.)
Marking a card as “Done” is simply a quick way of moving it to the Done column, which can be handy when you have a very elaborate workflow — and we have seen folks whose boards have up to 20 columns!
In the near future when we add Work-In-Progress (WIP) Limits for Task Boards and Scrum Boards, the Done column, of course, will not be subject to WIP.
We are also planning on adding more metrics to help Project Leaders and Account Owners understand how well their projects are going, and these will naturally make use of the Done count.
All posts in this series:
If you want to get rid of an old Kerika account, the easiest way is to simply de-authorize it from your Google account.
First, some background: when you sign up as a Kerika user, we use Google to figure out who you are, and what your email address is. (And to get permission to put Kerika project files in your Google Drive).
This means that Kerika becomes an authorized app, as far as Google is concerned.
And, it also means that you can de-authorize Kerika any time you want, from your Google account itself. Without authorization, you can’t use your old Kerika account, and neither can anyone else (assuming no one stole your Google password!)
So, here’s how you can disable Kerika, by de-authorizing it from Google: first, go to your Google account’s security settings at https://security.google.com/settings/security/permissions?hl=en
Here, you will all the third-party applications, including Kerika, that are currently authorized to use your Google credentials. Simply Revoke Access to Kerika, and you will disable your Kerika account:
Note: you need to make sure you are logged out of Kerika as well. If you leave yourself logged into Kerika on someone else’s computer, they will be able to continue to view your old projects, although they won’t be able to access any of the files that are stored in your Google Drive, or add any new files.
Since we are developing software for helping distributed teams collaborate more effectively, it was only natural that we would set up our own team as a distributed one.
Working remotely and relying principally on electronic communications, supplemented by some in-person meetings, has helped us understand better the challenges faced by distributed teams. As we believed from the outset, the biggest challenge has been keeping everyone on the same page in terms of our company strategy: business strategy, marketing strategy, and product roadmap.
Throughout our development process one of us would bemoan the lack of software like Kerika, that could help us build software like Kerika… Once the product became usable enough, we started “dogfooding” it –that elegant phrase invented by Microsoft that refers to a product team “eating it’s own dog food.”
One of the ways in which the Kerika team is using Kerika is for our QA: whenever we decide to work on a bug, we create a new project and name it after that bug number. Inside, we put our Build Verification Test (BVT) as well as the exit (success) criteria for that particular bug. It’s a neat trick: by going through the BVT, which we use as a sanity test before the developers hand off their code for QA, we end up creating a mini Kerika project for each bug.
For example, our BVT requires developers to upload a document to a Kerika page: well, for each bug, we upload a document that represents the exit criteria for that particular bug. The BVT requires users to go through various steps that provide a general coverage of Kerika’s main features. This means logging in using at least 3 different browsers (we usually test with Firefox, Safari and Chrome), and going through the process of adding Web links, videos, etc.
By using Kerika to test Kerika, at the end of each bug’s coding cycle we have a new project that we can look at and see whether it passed the BVT. It’s self-referential: the existence of a correctly set up project, with a particular team consisting of both Team Members and Visitors who perform certain actions, confirms that the BVT passed.
We combine the BVT with the exit criteria for each bug: these are derived from the reproduction steps of the bug report, plus the functional specifications. Going through the exit criteria for a particular bug, we end up with items in that bug’s project folder that confirm whether the bug was successfully fixed.
For example, if there was a bug about embedding YouTube videos on Kerika pages, the exit criteria would be such that at the end of the developer’s testing, the project would contain a YouTube video that could be examined to confirm that the bug was fixed.
So if the project for that bug is set up correctly at the end of the bug-specific repro steps and the BVT, then the developer knows he can check in his code for QA on our test environment. Of course, during our QA cycle we do more extensive testing, but this initial use of Kerika helps developers avoid breaking the build when they check in the code.
Pretty neat way of dogfooding, wouldn’t you agree?
After a rather long hiatus (over three years!), Kerika is back, and with a bang!
We owe the world some explanation of why Kerika disappeared, and why it is now reappearing…
Here’s what happened: when we launched Kerika back in 2006, it was as a desktop application, written entirely in Java so that it would run on Windows, Macs and Linux computers. People really liked the concept, particularly the innovative user interface and the ease with which one could do document management. But, there were two serious drawbacks with that first version:
Eventually, we ran out of time and money, which is really the same thing from a startup’s perspective. Of the two flaws listed above, the dependency on JXTA was really the killer: it meant that we couldn’t reliably provide communication or transfer of files between users. (And the topic of JXTA really merits its own blog post.)
And, so, we had to pack up our tents and go get “regular” jobs.
That’s the story of why Kerika disappeared.
What’s more interesting, is the story of why Kerika is now reappearing:
A funny thing happened, in the 3 years that Kerika v1 was taken off the market: people kept writing in asking for the product. (We had never taken down the website, so the demos were still available; you just couldn’t download the product any more.)
This got us thinking that maybe Kerika was fundamentally a good idea, but we had screwed up the execution of that idea. And there was another thing that surprised us: in the intervening years, no one else released anything like Kerika –a flexible whiteboard on which you could sketch out your ideas and plans, and also embed your content.
Last Spring, we sent an email to our old user base, trying to understand better what it was they found attractive about Kerika, and, in the process, trying to gauge the interest in reviving the product. The replies we received convinced us that (a) Kerika was, fundamentally, a good idea, at heart, and (b) the needs it served were still not being met by anything else in the market.
In August we reconstituted the Kerika team: a different team than before, with the skills that we would need to rebuild Kerika, from scratch, as a Web application. We have been hard at work ever since, and have done a compete rebuild – not a single line of code was reused! – and now we are ready to present to you the fruits of our labors.
In the next few blog posts, we will talk about the new product, the challenges we faced, the choices we made, and the lessons we learned from Kerika v1 (or “K1” as we like to call it.)
Welcome back.