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!
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!
Kerika’s Task Boards are so easy to set up and use that teams sometimes make the mistake of sticking everything on the same board, week after week and month after month, until the board becomes really too big to be useful.
The Kerika software itself doesn’t buckle under the weight of hundreds of cards on a single board (and, to be honest, we are also guilty of sometimes doing very large Scrum iterations that turned over a few hundred cards -.-), but just because the software works fine doesn’t mean the practice makes sense.
The most common way for a Kanban board to get overcrowded is for it to be used for too long: the Done column gets bigger and bigger, as more work gets completed each week, until you end up with a very lop-sided looking board with perhaps 20-50 items in “To Do”, and maybe 1,000 items in “Done”.
When presented with a board that contains hundreds or even thousands of items in Done, it’s hard for individual team members to get visual satisfaction from seeing cards move over to the Done column on a regular basis: as work gets done, it seems to vanish into this endless pile of other work that’s already been done.
Teams and, especially, Project Leaders should not underestimate the value of this visual satisfaction of seeing a well-balanced board, with about the same number of items in “To Do” (or Backlog, or Pending, or whatever you choose to call your parking lot) and in the “Done” column, with an even-looking distribution of items in the columns in the middle.
(The simplest Kanban board may just have three columns: To Do, Doing, and Done, but Kerika makes it easy to have far more complex workflows, and to capture your organizations’ best practices as a collection of process templates.)
If a Kanban board is going to be used for an extended period, say several months or more, then we recommend create a parallel History Board that can be used to track the historical achievements and progress of the team. Here’s how this scheme works:
We will use these columns to hold all the cards that were completed in that particular month. So, for example, the Jan 2014 column would contain everything that was completed in January 2014.
Laptop users will find their right-mouse click menu handy for this: click on a card in the Done column, do “Select All” from the right-mouse menu, and then do a “Cut”. Once you have cut (or copied) anything into your Kerika Clipboard, a Paste button will automatically appear at the top of each column, on each board where you can make changes.
So, Cut from Done on your active board, go over to your History Board, and then do click on the Paste button at the top of the appropriate column, e.g. the August 2014 column.
This simple method lets you achieve two objectives at the same time:
A side-benefit: your active Kanban board will load a lot faster if it doesn’t get overloaded.
Another note from a user which we wanted to share with you…
Just this week we had a fundraising administrative group meeting where our people collected for a 4-day meeting.
One of my software developers attended the meeting and we were scheduled to do a 1.5 hour presentation in the last slot of the 3rd day at 3 PM.
At 11 AM that morning, while he was in the meeting, I created a Kerika project for our presentation. I added the cards and attached screen shots and links that I wanted to present.
I messaged him in the meeting to get him to add cards to the project for IT issues that had been discussed in the previous 2.5 days so that we could address them in our session.
While he added cards, I added more screen shots to his cards and we organized and combined the cards while being in separate rooms so that by the time 3 PM rolled around, I showed up for the meeting and we did our presentation together.
It was ‘very agile’ indeed.
It probably wasn’t as polished as a PowerPoint but it was a lot more relevant as we put it together so quickly.
While we presented the different topics, we swiped the cards through the ‘Active’ and into the ‘Done’ column.
As we neared the end of our time limit, we were then able to adjust on the fly the topics that we would present with the time we had left.
Of course, we didn’t finish but it allowed us to present the most meaningful information with the time we had.
One of our users wrote in last night with this great story, which we wanted to share with you…
I did a one hour webinar for the software company (Software AG) that we develop all of our software with as they were impressed with the way we were using their software development environment (NaturalOne).
I threw a little Kerika spice into my presentation as it has become such an important part of our development environment and I actually used it to prepare my presentation.
Instead of preparing the presentation by myself I used a Kerika project and had my software developers contribute cards and instructions in the areas that they specialized.
While I was doing a live presentation I was referring to the cards on my other monitor and swiping them to the ‘Done’ column as I completed them.
I know you like to hear stories about how people use your software and this worked very well for this presentation. It was recorded and I will send you a link to it once it is published. It might put you to sleep at night, except for the Kerika part.
On LinkedIn’s Scrum Alliance group someone recently posed this question:
Which is more effective agile software project management tool MS Project or a agile software project management tool for implementing scrum?
Here’s my response:
I started using MS Project around 1989 — must have been close to v1.0, I imagine — and even back then, when it was a relatively simple tool, it never delivered enough utility to warrant the immense hassle of trying to keep it updated so that it actually reflected the reality of a fast-moving project.
The phrase that came to mind often was “I have to feed the beast again“, i.e. I have to spend hours each day trying to map all the real-time changes that were happening in the real-world to the fake world modeled in MS Project.
The MS Project world wasn’t fake because I was incompetent: it was fake because it was always instantly out-of-date.
And as MS Project has gotten larded with more bells and whistles, it has never been able to address its fundamental shortcoming: it is a theoretical model of what you would like your project to be, rather than a practical/actual reflection of what your project is.
So, even back in the 1980s, before people were talking about Agile and Scrum, we were all actually living in an Agile/Scrum world; we just didn’t have that realization, and we didn’t have the appropriate tools to deal with a fast-changing project environment.
At Kerika, we live and breathe in a distributed Agile world: our team is spread out between Seattle and India, which means we never have any overlapping time, but by using Kerika scrum boards we are in perfect synch with each other.
We know exactly what everyone else is up to, and we are able to process, on average, 10-12 cards per week, per person, on a sustained basis.
Kerika also has a whiteboard capability so we are able to do brainstorming and design work.
Is MS Project useful for anything at all? Yes, if your project…
a) Is considered immutable from the very start.
An example would be a government contract which is negotiated up-front in painful detail, and your success is defined only in terms of whether you delivered exactly what was specified, not whether the final product was useful. (Business-as-usual for most Federal contracts.)
b) Every aspect of the technology has been prototyped, tested, and proven already, so uncertainties are minimized.
This is an interesting use-case of mixing Scrum and Waterfall that’s not explored very often, where you use Agile to do your R&D and figure out workable solutions to your biggest uncertainties, and then use Waterfall to build the final version.
We have a growing community of users in various agencies within Washington State government, and we are happy to provide the essential project management and team collaboration tool needed to achieve the Governor’s mandate for “Lean Government”.
Among other agencies, we are proud to serve people in:
To help folks within Washington State agencies understand how (and when and why…) they should Kerika, we have partnered with the state’s Office of the CIO to produce a quick guide to Using Kerika for State Government Work:
Hopefully this should help; additional resources are available from the Office of the CIO, Results Washington, and, of course, from Kerika!
Dan Genz from the Washington State Auditor’s Office gave a presentation at the 2014 IPMA Forum describing how the state agency is adopting Lean principles, while serving hundreds of state, county and local municipalities with a distributed team of auditors and analysts spread out across the state:
Will Treinen, founder and CEO of Treinen Associates gave a presentation at the 2014 IPMA Forum describing his experiences in building an “Agile PMO” to handle the extraordinary growth of his consulting business (600% in the past year!).
Will relied upon Kerika to create the perfect collaboration environment for his distributed teams of project managers, business analysts and business development staff:
Hi folks!
I recently offered my thoughts to the Scrum Alliance group on LinkedIn, on the discussion thread on whether
Kanban is a better way to manage support/maintenance work than scrum. I thought you might find it interesting:
Kanban is generally a better model for support/maintenance: these tasks tend to trickle in, so trying to handle them with a conventional Product Backlog is often awkward.
Support/maintenance tasks are also usually unrelated to each other: one bug fix may have nothing to do with another.
This makes for a different metaphor than Scrum/Product Backlog where there is some presumption that user stories and tasks, while perhaps independent, are at least part of a larger product or release theme.
If you did support/maintenance tasks in a Sprint, that Sprint would have no overarching theme which I strongly believe is essential for success with Scrum teams.
And if any team doing support/maintenance with Scrum will quickly realize their Sprints are unlike those of other teams that are doing product development with Scrum.
I would view your questions about swimlanes as arising from a misfitting metaphor: instead of using swimlanes, you would be better off using tags, and then filtering your board as needed to see all support/maintenance tasks related to a particular subsystem or process or person. E.g. “show me all the tasks related to the database schema”.
We use our own product (Kerika) of course, and we do all of our new product development with Scrum Board, and support/maintenance with Kanban boards since Kerika lets you easily have both kinds of boards.
We use multiple tags on each card on both the Kanban and Scrum Boards, so we can filter and search, e.g. “show everything related to our Google Drive integration”.
These filtered views are much more effective and flexible than trying to organize your board with swimlanes, because each card can have multiple tags, whereas with swimlanes a card would be in only one swimlane at any time.
Also, this arrangement gives us flexibility to move from Kanban to Scrum and back: for example, if a support/maintenance card that originally landed on a Kanban board is later deemed to be significant enough to handle as part of product development, we can just cut-and-paste that card from the Kanban board to the Scum Board, and Kerika brings along all the content, history, attachments, chat, etc.