Hope you like it — we finally got around to customizing the WordPress TwentyThirteen theme we have been using for this blog.
Nothing fancy; just making sure the colors and font (especially the fonts!) are consistent with our website and app. We use Roboto everywhere now: we find this to be a really easy to read font for most screens, and think that Google did a great job in coming up to an alternative to the traditional Arial/Helvetica.
We are also trying to clean up the Categories and Tags we use to help you find older blogs: there were too many overlapping categories/tags that had accumulated over the years so we got rid of a bunch of them.
We have been busy through the holiday season, as usual, but there isn’t a lot of stuff to show you yet since the big new thing we are working on — a more automated and efficient account management and billing system — won’t be ready for a while.
Meanwhile, we have been working through bug fixes on a regular basis; many of them obscure and probably unnoticed by anyone but the Kerika team itself, but we don’t like to have known bugs sitting around so we knock off bugs fairly quickly even if no one has complained (yet).
Here are some of the bug fixes we have done recently (in no particular order):
A problem that affected direct sign up users who wanted to preview their documents, but didn’t allow third-party cookies to be set in their browsers.
An obscure situation where someone who owned a board, but wasn’t part of the board team, shared it with another user: in some situations the second user didn’t see this board listed correctly in their Shared With Me tab of their Home page.
Another obscure circumstance in which a board owner’s face wasn’t shown correctly in the Shared With Me tab of other users.
Helping a user restore access to a board that had gotten corrupted somehow in the database: this wasn’t the user’s fault and we wanted to make sure no work was lost.
Some improvements to labels used in My Preferences to clarify (better) the user’s choices.
Fixing at least one situation where someone wanting to sign up with their Google ID (as a Kerika+Google user) was getting endlessly redirected by Google and never reaching Kerika. (For some reason everyone who reported this problem is located in Norway; don’t know why…)
A problem affecting direct sign up users: they weren’t seeing thumbnails of their files in their Kerika cards and canvases.
Some situations where a browser left running Kerika overnight didn’t refresh itself automatically the next morning, and required the user to manually refresh the view.
We have a complete (one-hour long) video of the tutorial presented by Arun Kumar, CEO of Kerika, at the recent Lean Transformation Conference on the subject of Kanban vs Scrum: what’s the difference, and which should you use?
(The slides for this talk, and more, can be found on Slideshare.)
Forming a team 00:01:32
The Product Owner 00:02:01
The Scrum Master 00:02:55
The Scrum Team 00:03:55
Pulling Work 00:04:04
The Product Backlog 00:05:45
Scrum Stories 00:06:25
Writing a good Story 00:07:35
From Epics to Stories 00:10:25
From Stories to Tasks 00:11:13
Estimating with Story Points 00:13:04
Organizing a Sprint 00:15:00
How long is a Sprint? 00:19:15
Sprints in theory 00:20:32
Sprints in real-life 00:20:53
Daily Standups 00:23:25
Burndown Charts 00:24:13
Team Velocity 00:25:35
Best Practices for Getting Scrum Right 00:28:00
The Nuclear Option 00:30:57
Where does Scrum work best? 00:32:02
Scrum in Government 00:33:25
Where does Kanban work best? 00:35:43
Collaboration Networks 00:37:25
Paper doesn’t scale 00:38:30
Using Kerika for Personal Kanban 00:39:50
Using Kerika for Team Kanban 00:40:24
Using Kerika in the Public Sector 00:40:37
Using Kerika for Scrum Projects 00:40:54
Capturing stories as “virtual sticky notes” 00:41:20
Question: how do you deal with poor performers on the team? 00:49:15
Question: in Scrum, are units of measure like lines of code still applicable? 00:50:08
Question: how do you measure individual performance? 00:51:03
Question: how do you handle poor performers within a team? 00:52:25
Question: when do you use the Nuclear Option? 00:54:20
Traditionally, in a Kanban or Scrum board the priority is denoted by the position of the card within a column: cards that are higher priority are placed higher within a column, and the card at the top of the column is the highest priority at that stage of the workflow.
For example, in this view of a board the highest priority item for Planning & Design is the card on top of that column:
This method has the advantage of simplicity and clarity: there is no ambiguity about what is the most important work item at any stage of the workflow.
The disadvantage of this method is that as many cards start to move across the board, especially on boards where the workflow is complex (i.e. the board has many columns), it becomes harder to track all the cards that are especially important.
In other words: the simple method doesn’t scale well, and our goal with Kerika is to provide the simplest user interface on top of the most capable work management system, so we realized we needed to do something more.
With our latest version, Kerika makes it easier to explicitly tag each card with a priority of Normal, High or Critical:
Along with assigning tags to a card, you can now set the priority of the card as well: by default all cards are Normal, but they can alternatively be flagged as High Priority or Critical.
Viewing all the High Priority and Critical Cards
We have also extended the Highlights function for Task Boards and Scrum Boards to make it easy to quickly see all the High Priority and Critical cards on a crowded board:
When you are looking at a board, the High Priority and Critical cards are also highlighted with small stars: a solid red star for Critical, and a hollow red star for High Priority:
The Normal Priority cards don’t have any star; we didn’t want to crowd the design which would have made it harder to spot the more important High Priority and Critical cards at a glance.
High Priority and Critical Cards across all your Boards
Previously, when you hid a column Kerika would show that like this:
The name of the column that was being hidden was shown vertically, to make it easier to retain the overall context of the board.
We have improved this so hidden columns now look like this:
The subtle (but important) distinction is that Kerika now shows you how many cards are in the hidden columns, not just the name of the column. We think this will make this feature more useful, to more people, more of the time.
It will come as no surprise to our users that the Kerika team uses the software for every aspect of the company’s internal operations, including, of course, our product development.
(There really isn’t anything better on the market for planning and executing product roadmaps — we know, because we have checked and made sure we are better than everybody :-))
We are sometimes asked about our own internal workflow: how we plan releases and manage our Sprints, and in particular how we have gone without using regular old email for over 4 years now!
Well, here’s a glimpse at our internal workflow:
We work in two-week long Sprints; we have found two weeks to be the ideal Sprint length since it provides enough time to produce something — at least some usable part of a new feature — while not being so long that we forget we are supposed to be working as a Scrum team.
Whenever we plan a new Sprint, we are always also looking forward as well: hence the columns titled “Sprint +1” (i.e. the Sprint that will come after the current Sprint), “Sprint +2” (the Sprint that will come after the next Sprint), etc.
This gives a view into the next several weeks of our product roadmap which makes sure we don’t approach any single work item with tunnel vision.
Now you might notice that “Sprint +3” in the list above is way larger than “Sprint +1” or “Sprint +2”: that doesn’t mean that we expect a sudden spurt in productivity (i.e. increase in team velocity) in 4 weeks time. It just means that as we go further out in our planning there is more uncertainty about priorities and so the Sprints that are well into the future are not well defined — and that’s perfectly OK.
Within each Sprint we have a fairly conventional flow: Planning, Development and QA. The QA step actually consists of three separate stages:
Code Review: we try to make sure we review all the code we are writing in any Sprint, unless it is a really trivial change we are making (e.g. changing the label on a button).
Deploy to Staging: we have a separate set of servers where we test our new releases. This also happens to be where we have all our real projects running: we believe very much in the idea that “developers should eat their own dogfood”, so we run out entire business on the latest build that went past Code Review.
This can be a little scary or frustrating at times: if there was a bad release to our staging environment, it can bring every project and board to a screeching halt. But, from our perspective, that’s the whole point: make it everyone’s business to ensure that we produce high-quality code, and make it everyone’s priority to fix any problems that come up.
This model of living on the bleeding edge of our product gives us a really good incentive to write good quality code!
The final QA step is Show & Tell, where the team formally presents the new features or bug fixes to the Product Owner. With each new feature we will have identified a set of test cases, as part of the Planning phase, and these are used to formally check the new feature in a meeting attended by everyone on the team.
Very occasionally something will get rejected at the Show & Tell stage, in which case the card gets moved back to Planning or Development and flagged as “Needs Rework”. It’s more common for work to get rejected at the Code Review phase, not because it is buggy, but because it might not meet our internal coding standards.
Once a feature or bug fix has passed Show & Tell, it is ready for Deployment to Production.
We have a continuous integration process for handling code changes — pulling them from our internal git code repository — but we don’t do continuous deployment. Instead we prefer to deploy on the last day of each 2-week Sprint. We usually time this for Friday morning, Indian Standard Time, so that our developers in India can take one final look at the system working in production.
We have an unusually strong emphasis within the team on creating documentation at the same time as we write code. Many small companies skip documentation because they think it will slow them down.
In our own (sometimes bitter) experience, skipping documentation is false savings: if there are problems to be fixed later, or even if a feature simply has to be extended in the future, it’s very hard for even the original developer to recall the logic that she used to write the code in a particular way.
What’s important to note, however, is that we don’t have very big documents: most documents are less than a page long, because they refer to very specific work items. But we have thousands of these small documents, since every feature we have ever produced, and every bug we have fixed, has been documented.
And thanks to Kerika’s very cool integration with Google Docs (we use Kerika+Google), managing these thousands of documents is very easy: just open the relevant card for a specific feature or bug fix and you will find all the relevant documents as well:
For new features we always have a short Planning Document that identifies any existing modules that will be affected and provides an outline of the new code that will be written. Here’s an example:
There may be other documents created, depending upon the complexity of the new feature, but even the smallest new feature will have at least one planning-related document that’s written before the code is written.
For bug fixes, we have a Repro, Cause & Fix document that methodically analyzes the cause of a bug:
The most important section of this document is the Introduced Since piece, where we trace the origin of the bug back to its source, to understand what new feature or bug fix we were originally working on that resulted in this new bug appearing.
This methodical root cause analysis, which we do for even the most minor bugs, helps us identify patterns in our code writing that we need to improve. Sometimes it can even point to bugs that we haven’t discovered yet: the root cause analysis may identify an assumption that we have applied in other places, all of which need to be looked at to make sure there aren’t other variations of the same bug that haven’t been identified yet.
After the bug has been fixed, the Repro, Cause & Fix document is updated to reference the git branches where the code fix can be found. This completes the circle of careful analysis, careful execution, and methodical review that we strive to adopt (and improve continuously).
The End of Email
We stopped using regular email towards the end of 2013. There was never any formal decision to renounce email; instead there was a formal decision to “eat our own dogfood” in a very serious way.
And as we started to build our entire company using our own product, we found that using Kerika is so much better than using email that there really wasn’t any need for email any more.
So people simply started drifting away from email. There was no explicit decision or formal movement to do so, people just realized, on their own, that email is an exceptionally poor way of managing work within a distributed team.
Considering the size of our team — and entire company, for that matter — you may be surprised by the degree of formalism we have adopted, and the heavy emphasis on analysis and documentation.
We spend at least as much time on analysis and documentation as we do on “pure coding”, and if we add in the Code Reviews and other elements of formal QA, the actual coding time is a relatively small portion of our total expenditure.
But trying to skimp on analysis and documentation really doesn’t pay off, in our experience: if you are building a company and product for the long-run, as we very assuredly are, you need to build it right, not just fast.