What would your company look like if working mothers were a central feature of your organizational design, not a bug to be patched?
How great is Kerika’s integration with the Box Platform (that powers our direct signups?)
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.
We have improved the sorting feature for cards on Task Boards and Scrum Boards to allow for partial sorting: if you select some cards within a column and then do a sort, the sorting action will apply only for the selected cards.
This will make it easier to organize very large boards, e.g. where a single column may contain a hundred cards or more.
A fun video we made recently featuring Faith Trimble and Kate King, from the Athena Group, talking about how a consulting company can function as a truly distributed team — and get great work-life balance as a result!
At long last, we have built Views — one of the most commonly requested features, and something that we had been obsessively designing and redesigning over years, trying to figure out the best way to handle this need.
We are starting off with four standard Views, and we will built more in the future, and add a way for you to build your own Views as well.
The Views we have built are:
What’s Assigned To Me
The most commonly asked for feature by people who are working on several projects — and, hence, several boards — at the same time. This is what it looks like:
Everything that’s currently assigned to, on all boards except for those that are in the Trash or Archive, are collected for you into a single View, where cards are organized as follows:
- Not Scheduled
- Due Today
- Due This Week (excluding what’s already included in Due Today)
- Due Next Week
- Due This Month (excluding what’s already included in Due Today and Due This Week)
- Due This Quarter
- Due Next Quarter
It is a comprehensive summary of everything you need to get done, and it will be invaluable for managers and anyone else who has to work on multiple projects at the same time.
If you select a card in a View, like this
You get quick access to key actions:
- Move to Done
- Move to Trash
- View Board
Open opens the card right there, inside the View itself. View Board, on the other hand, opens the card in the board in which it is located.
Both are useful, depending upon the card and what you want to do: in some cases you just need to update a particular card — e.g. reschedule it, add a comment or file — and opening the card in the View itself, which is very fast, is enough.
In other situations you might want to be sure you are understanding the context of the card, and it is better to see where it is on the board that contains it. This can be helpful for cards that you are not quite sure about.
This View will be particularly helpful to managers (Board Admins): it summarizes everything that’s due, on all boards where you are one of the Board Admins:
Cards are organized for you as follows:
- Due Today
- Due This Week (excluding what’s already shown as Due Today)
- Due Next Week
- Due This Month
- Due Next Month
For this View, as with the What’s Assigned to Me View, we try to be smart about not showing duplicate cards: if something is due today, for example, it will show up in the Due Today column, but not get duplicated in the Due This Week or Due This Month column.
This makes it easier for you to plan your schedule: you can see what needs to get right away, and what needs to get done later.
What Needs Attention
Again, a View that will be of particular interest to managers concerned with several ongoing boards:
Here, Kerika tries to show everything that needs a little extra attention: things that are
- Flagged as Critical
- Flagged as Blocked
- Flagged as Needs Review
- Flagged as Needs Rework
- Flagged as being On Hold
These items typically represent your risk profile across all your boards, and Kerika brings it all together in a single View.
What Got Done
Great for anyone who needs to produce a status report, or any manager who needs to monitor progress across many different projects:
Across all boards where you are a Board Admin, this View summarizes
- What got done Today
- What got done This Week (excluding items shown in This Week)
- What got done Last Week
- What got done This Month (again, excluding items shown for Today and This Week)
- What got done Last Month
- What got done This Quarter
All your Views can be accessed from a new tab called Views (naturally) on your Home Page:
On each View card, Kerika shows how many items are included in that View, and as of when. The Views are automatically refreshed when you open them, but in-between they are not updated because we do not expect the information shown to change on a second-by-second basis.
If you are worried that your View is out of date, you can update it by selecting it on your Home Page:
You can also update any View that you currently have open, by clicking on the Refresh button shown on the top-right of the View:
We will let you go crazy with these Views, for now. In the future we will add more (we already have some ideas on that front, but would love to hear from you as well!) and also add a Custom View capability.
When a column is hidden, it’s name is shown vertically, so you can easily remember which columns you have hidden at this time.
Revealing columns that are hidden is easy: just click on the “eye” button and the column immediately comes back into view.
Every Team Member can decide whether to show or hide individual columns: their choices won’t affect the way other Team Members choose to view the same board.
Sorry for not having posted in a while; we have been swamped with a new UI design that has consumed all of our time.
The new UI, by the way, is all about making Kerika more accessible, particularly to people who are new to visual collaboration.
Our user feedback had revealed a couple of uncomfortable truths that we needed to address:
- Very few users were aware of all the functionality that already exists in Kerika. Which means that we didn’t need to focus so much on building new functions as we did on making sure people understand what Kerika can already do.
- Our new users aren’t just new to Kerika; in most cases, they are new to visual collaboration altogether. Even though there has been a proliferation in recent months of all sorts of companies trying to recast old, tired products as exciting new visual collaboration (hello, Smartsheet!), our new users aren’t converting away from our competitors as much as converting away from paper, email, and SharePoint.
This, then, is the goal of our new UI: to make it easier for people to adapt from paper and email to visual collaboration, and to make it easier for all users to exploit all the great functionality that we have already built.
We will have more on this in the coming months, as we get closer to releasing our new user interface, but in the meantime we have queued up a bunch of blog posts to make sure you know about all the other great stuff we have been working.
Yeah, our biggest problem is we don’t tell people what we have already done…
Another great new feature: if you upload a file on any card, canvas or board with the same name as a file that’s already attached to that particular card, canvas or board, Kerika will automatically keep track of these as being different versions of the same file. This makes it even easier to organize all your Kerika project files.
Here’s how it works:
There’s no limit to the number of files you add, nor any limit on the size of these files.
When you add a file, to a card, board or canvas, Kerika automatically uploads that file and shares that with everyone who is part of your board’s team. You don’t have to do anything: Kerika makes sure that all the Team Members have read+write permission, and all the Visitors have read-only permission.
That’s how Kerika has always worked; what we have added is an automatic versioning feature that checks when you add a new file to see if has the same name, and type, as a file that’s already attached to that particular card, canvas or board.
If the file name and file type match something that you have already added, Kerika automatically treats that new file as a new version of the old file, rather than as a completely different file. This makes it really easy to manage your Kerika project files.
Here’s an example: this card has a file attached to it called “Foo.docx”.
If a Team Member adds another file to this same card, also called “Foo.docx”, Kerika will treat that new file as a different version of the same Foo.docx, rather than as a completely different file:
Accessing these older versions is easy: if your Kerika files are in being stored in your Google Drive, you can get the older versions using the Google Docs File menu:
If your files are being stored in your Box account, you can access the older versions from the menu on the right side of Box’s preview window:
If you signed up directly with Kerika, you can access the older versions from within Kerika’s file preview:
Clicking on the Older versions of this file link on the top right of this preview will give you a list of all the old versions of this file that Kerika has:
So, that’s it: simple, easy, automatic tracking of multiple versions of your project files! Brought to you by Kerika, of course.
For folks who sign up directly with Kerika, we store the user password (in an encrypted form, of course), which means that these users can change their passwords directly from within the Kerika application by going to their My Account page at https://kerika.com/my-account:
So, their My Account page looks a little different, like in this example of a Kerika+Google user: