Category Archives: Distributed Teams

Posts related to collaboration within distributed teams.

Kerika’s internal product development workflow

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:

Kerika internal workflow
Kerika 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.

Planning

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.

Quality Assurance

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.

Deployment

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.

Documentation

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:

Documents attached to cards
Documents attached to cards

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:

Example of a Feature Planning document
Example of a Feature Planning document

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.

Bug Fixes

For bug fixes, we have a Repro, Cause & Fix document that methodically analyzes the cause of a bug:

Root Cause Analysis
Root Cause Analysis

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.

Conclusion

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.

Visitors can view chat on public boards

Some of our users are working on open-source, advocacy, or volunteering projects, and for these people privacy is less important than publicity: rather than hide their work, they would prefer to have as many people as possible view it, in real-time, so they can build momentum for their initiatives.

Here’s an example of a public board:

Example of public board
Example of public board

We have always accommodated such users, by offering an Anyone with link option that Board Admins can use to make their boards accessible by anyone who has the URL of that board, even if they aren’t Kerika users:

Making boards public
Making boards public

When a board is made public, all the files attached to and all the chat as well can be viewed by anyone.

As with any other Visitors, members of the public cannot make any changes.

Our latest improvement to this public boards feature has been to make the chat also viewable by anyone who has the URL of the board.

Note: a Board Admin can change their mind at any time, and revert a public board back to one that’s restricted to the board team or account team.

 

Changing the Owner of a Board

People usually don’t pay attention to the question of who owns a particular board, but it is an important question to consider when you create a new board: the Account Owner owns not just the board, but also all the files attached to cards and canvases on that board.

This is not always important (and often not important in day-to-day use of Kerika): our deep integration with Google and Box ensures that everyone who is part of the board team has automatic access to all the files needed for that board, with access permissions managed according to each individual’s role on the board: Board Admins and Team Members get read+write access; Visitors get read-only access.

(And, as people join or leave board teams, or their roles on a particular board’s team changes, Kerika automatically manages their access to the underlying project files, regardless of whether these are being stored in Google or Box.)

But when someone is planning to leave an organization, the question of ownership can suddenly become important: you don’t want an ex-employee to continue to own critical project files.

Changing ownership of boards was not something that was easily done in the past — there were workarounds, but they were fairly cumbersome and obscure — and we mostly handled these as special requests, on a case-by-case basis.

With our newest update to Kerika, this is no longer the case: changing the ownership of a board is a simple process that can be initiated at any time by the current owner of a board:

Change Board Owner
Change Board Owner

You can ask any other Kerika user, who has signed up the same way as you did (i.e. either as Kerika+Google, Kerika+Box, or by directly signing up) to take ownership of a board. Because this is a consequential action, not something you should rush into, you are asked to confirm your intention by typing the word “YES”:

Confirming change in ownership
Confirming change in ownership

Once your request is sent off to the other user, the board is in a frozen state: existing members of the board team can continue to view the board, but no one can make any changes:

Board waiting for new owner
Board waiting for new owner
Board frozen while waiting for new owner
Board frozen while waiting for new owner

If you change your mind, you can cancel the request before it has been accepted.  This can be done by selecting the board from your Home Page:

Cancel ownership request
Cancel ownership request

You can also find your pending request in your Sentbox, and cancel it from there:

Cancelling pending request
Cancelling pending request

Note: once a board’s transfer is complete, it can’t be undone by you. If you really need to get ownership back of a board, you will need to ask the new owner to transfer the board to you.

An important caveat for Kerika+Google users

We try to ensure that files attached to a Kerika+Google board have their ownership changed at the same time as the board itself is transferred, but there are some limits to how Google will allow for a change in ownership:

All Kerika-related files are stored in a set of folders in a user’s Google Drive, organized by account and board.

Google let’s us change the owner of a folder, so we can make sure that when a board is transferred the ownership of the associated Google Drive folder is also changed.

However, for the individual files contained within the folder, Google only allows for a change of ownership of files that are part of Google Docs: documents, spreadsheets, presentations, forms, etc.

Files like images (.jpg, .png, .gif), zip files, and PDFs, for example, retain their old ownership between the Google API doesn’t let Kerika change the ownership of these “non-Google-formatted” file types.

An easier way to hide or show columns

We are extending the Column Actions menu (featured in a previous post) to provide a quicker, easier way to hide (or show) individual columns on your Kerika Task Boards and Scrum Boards:

Option to hide column
Option to hide column

When a column is hidden, it’s name is shown vertically, so you can easily remember which columns you have hidden at this time.

Hidden columns
Hidden columns

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.

Handling the different timezones in a distributed team

When you schedule cards on a Kerika Task Board or Scrum Board, we offer a simple way to pick a date:

Setting due date
Setting due date

We don’t support setting a specific time (e.g. 5:00PM) along with the time: these times are generally useless in most work settings and add unnecessary complexity to the user experience.

And, yet, it’s possible that Kerika reports a specific time for a due date, like in this example:

A specific time for a due date
A specific time for a due date

So, how did happen?

Well, Kerika took note of the fact that person making that time commitment (“I will get it done today”) was based in India.

And midnight in India is 11:30AM in Seattle — at least now, with Daylight Savings Time in effect.

So Kerika shows the Indian team member’s commitment  of “I will get it done today” in terms that make sense to a colleague in Seattle:

Handling timezone differences
Handling timezone differences

11:47 AM Pacific Standard Time with Daylight Savings Time in force is 12:47PM Indian Standard Time; something that Kerika figures out automatically.

This simple, elegant way of handling timezones eliminates the frequent disagreements over “I meant my today, not your today…”

An example of the incredible attention to detail that Kerika brings to the needs of distributed teams.

Kerika at Lean Transformation 2016

Arun Kumar, CEO of Kerika, and Joy Paulus, Senior Policy and Program Manager for the Washington State Office of the CIO, delivered a joint presentation at the Lean Transformation 2016 Conference.
IMG_2224

The subject of the talk was “Collaboration Across Organizations: Big Results with Small Teams”. Here are the slides from the talk: