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:
(The ninth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)
We have been doing internal testing (“eating our own dogfood”) of Kerika+Box for the past three weeks, and the results have been much better than we expected!
We have found very few bugs so far, which is great — it’s feels like a huge vindication of our decision to invest several Sprints in improving our internal QA processes, clearing the backlog of old bugs, and generally improving our software development processes with code reviews across the board, for even the smallest changes.
In other words, we didn’t move fast and break things: we moved slowly and broke nothing. Which makes sense when you have paying customers who rely upon your product to run their businesses…
Since Kerika makes it really easy to have multiple backlogs in a single account, we put all the OAuth and infrastructure work in a separate backlog, allowing a part of the team to concentrate on that work somewhat independently of other, more routine work like bug fixes and minor usability updates.
And, as before, put every feature in a separate git branch, making it easy to merge code as individual features get done.
Here’s what our Box QA board looks like, right now:
Box QA board
The user interface for Kerika+Box is essentially the same as for Kerika+Google, with a few quirks:
Box requires more frequent logins: Google provided us with relatively long-lived refresh tokens, so a user could close a Kerika browser tab and reopen it a day later and log right back in.
With Box, you are going to see a login screen much more often, along with a screen asking you to re-authorize Kerika as a third-party app that can access your Box account.
This is kind of irritating, but apparently unavoidable: from what we have found on Stack Overflow, Bug views this as a feature rather than a bug.
The other, really big difference is that files are edited offline rather than in the browser itself: when you click on the Edit button, you will end up downloading a local copy of the file, using Microsoft Office for example, and then when you do a Save of that file, your latest changes are uploaded automatically to the cloud.
Here’s what you see when you open a file attached to a card on a Kerika board, when you use Kerika+Box:
Example of opening a file within Box
This works great most of the time, except when two people are making changes simultaneously: in that situation, Google’s in-browser editing seems a lot more convenient.
On the other hand, downloading local copies of files means that you get the full power of Microsoft Office, and we know that’s very important for some of our users, e.g. consultants dealing with complicated RFPs or government users dealing with official documents.
Performance also seems a little less than Google Drive, although we would stress that this is highly variable: while Google Drive files generally open within 1-3 seconds in a new browser tab, they can take much longer if Google’s servers are slow.
Overall, we are very pleased with Kerika+Box: we are planning to do all of our new development with this new platform, to continue eating our delicious dogfood 😉
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:
In a recent post on the Scrum Alliance forum at LinkedIn, a member asked this question:
How do teams handle defects that have been found after a user story has been accepted and released to Production?
My first thought was to just log a defect against the user story, but that screws up reporting as it removes the Accepted status. Executives do not want to see that. I am thinking we should just create a new user story and slate it for the next Sprint. ?
My answer:
Defects are bound to be found after a story has been accepted and released to production; that’s just a very normal part of software development, so it makes sense to add them to the Product Backlog to prioritize for a future Sprint.
There isn’t any need to take the “Accepted” status off a story that was already considered done within an older Sprint: “Accepted” doesn’t mean “super-excellent and done for all time”; it just means it was considered good enough by the Product Owner at the conclusion of the Sprint, and therefore accepted.
To “un-accept” stories post facto would not just screw up your reporting; it would start to create an unhealthy dynamic between the Scrum team and the Product Owner, where the Product Owner starts to believe he can reject stories post facto.
For Scrum to work well as a process, you need to get everyone to buy into the core idea that stuff gets done in iterations; new stuff gets done in new iterations; old stuff gets improved in future iterations.
On a more tactical level, Kerika lets you link together individual cards or even entire Scrum Boards, because every board, every card, every canvas has a unique URL that you can reference anywhere in the system to create dynamic links between stories and boards.
So, if we find a bug in a previously accepted story, we create a new card for that and simply reference the old card in the new card’s details. Here’s a video that shows how that’s easy with Kerika.
Another question answered on LinkedIn’s Scale Agile group: The team is facing a high Technical debt before adopting Scrum. Now, they want to fix this. How could they include this in the Sprint?
If you already have a lot of technical debt, I would recommend that the first few Sprints do nothing but clear the most expensive debt.
The trick is to persuade the Product Owner that this is necessary, because it means deferring any delivery of “real features” while the debt is paid down.
Note that I say “paid down” rather than “paid off”: in my experience, there is rarely an opportunity to completely pay off technical debt and have a clean Product Backlog with nothing in it but nice user stories that deliver tons of end-user functionality.
At Kerika, we have found that we accumulate some debt almost continuously, and that this is unavoidable even though we are using Scrum.
Purists might argue that a true Scrum model eliminates technical debt, but this is unrealistic when you are dealing with a fast moving market and are focused on rapidly improving your product.
Periodically, we devote an entire Sprint to paying down technical debt. We did one fairly recently because we are in the process of adding some substantial new functionality: Kerika will now become the first Scrum/Kanban/Scrumban tool that has full integration with both Google Drive and Box for sharing project files within distributed team 😉
Because this was a major platform enhancement, we took a 3-week Sprint to pay down our technical debt by clearing a bunch of bugs and server exceptions that individually were never going to make it to the top of the Product Backlog.
The Kerika tool makes it really easy to tag items, so it was easy for us to find all the bugs that were in our (rather large) Product Backlog and we cleared nearly 50 items.
Actually, this was our second debt payoff Sprint this year: in April, the Heartbleed scare prompted us to do a full internal review of our security processes, which morphed into a full review/overhaul of our QA and other software development infrastructure/process stuff, and we spent an entire Sprint to significantly clean up a bunch of stuff that had been moldering a while.
For what it’s worth, we generally do an all-hands-on-deck Sprint to pay down debt: we don’t try to sneak in any new product features because I find that it sends a confusing message to the team about the importance of paying down the debt.
I said earlier that often the big challenge is convincing the Product Owner of the need to devote a Sprint or two to pay down debt; in our case that’s relatively easy because I am the founder/CEO and buy into the idea 😉 but I do believe that if you are going to pay down debt, you need to do it with serious intent and get everyone focused on that, which means the Sprint is all about debt, not new goodies.
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.
For a major upgrade project at a municipal planning department, a team spread from Washington to Minnesota, used Kerika to successfully manage document reviews, technical questions, issue management, and key tasks. Dennis Brooke has the story on cloudPWR’s blog.
And this is just the beginning: expect much more in terms of a Kerika+Box integration!
Global, distributed, agile: words that describe Kerika, and WIKISPEED.
WIKISPEED is a volunteer based green automotive-prototyping company that’s distributed around the world and coming together on a Kerika board to design and build safe, low-cost, ultra-efficient, road-legal vehicles.
We first visited WIKISPEED in the summer of 2012, as part of our research into the needs of distributed, agile teams.
We found huge walls covered with sticky notes:
Dedicated volunteers….
And the irrepressible Mr. Joe Justice himself:
Today, WIKISPEED uses Kerika’s Scrum Boards to organize itself (you can see them at kerika.com/wikispeed):
This transformation has helped knit together folks from around the world: the Kerika boards are now used by WIKISPEED volunteers in the United States, Canada, Europe and New Zealand to communicate and collaborate. A great example of how Kerika can help bring together a globally distributed agile team!
(And, by the way, Kerika was a proud sponsor of the WIKISPEED car that was built for the Future of Flight Aviation Center in Everett, Washington ;-))
A month ago we wrote about how Kerika makes it really easy to spot bottlenecks in a development process – far easier, in our opinion – than relying upon burndown carts.
That blog post noted that the Kerika team itself had been struggling with code reviews as our major bottleneck. Well, we are finally starting to catch up: over the past two days we focused heavily on code reviews and just last night nearly 80 cards got moved to Done!
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
