Category Archives: Team Collaboration

Posts related to collaboration within distributed teams.

How Project Settings Work in Kerika (A Preview of Coming Attractions)

Here’s a teaser video of the new Kerika user interface, which we are getting close to releasing…

Among other things, we will consolidate and improve a bunch of project management features under a new “Project Settings” button.

Check it out:

Showing Due Dates in local times

Many of our users work in globally dispersed teams; our own team is spread out between Seattle and India.

With multiple timezones, particularly when they are widely spaced apart, commitments like “I will get this done today” become a little tricky to understand.

If someone in India says “I will get this done today”, is that India time or Seattle time? Well, that depends upon where you are, when you log into Kerika.

Kerika automatically factors in differences in timezones when showing due dates: someone who commits to getting something done “today” in India is actually committing to get it done by 11:30AM Pacific Standard Time, now that the US is in Daylight Savings Mode.

So, the due date is shown in a way that’s relevant to the user’s local time: our Seattle folks see an Indian’s commitment like this

Local time due date
Local time due date

These timezone differences automatically adjust for Daylight Savings Time: there’s nothing you need to do to see when a commitment is actually due.

Except, perhaps, notice that the item is now overdue, as indicated in red in the example above…

Kerika @ Kerika: How we use our own product

We are often asked how the Kerika team itself uses Kerika, and we freely share this through demos we have done in person for potential customers and at various events. For those who we haven’t met in person, here’s a blog post instead..

1. Kerika runs on Kerika.

Pretty much everything we do, from the smallest, tangential effort to our main product development is done using the Kerika software.

(It shouldn’t surprise you to hear that, given that we are a distributed team ourselves — spread out between Seattle and India.)

2. No email, limited phone calls

In fact, we gave up using internal email back in Dec 2013. (Email sucks, and Kerika is the smarter alternative to spam.)

Because our team is spread out over 10,000 miles, we do occasional phone calls, using Skype or Google Hangouts, to discuss product strategy, but we don’t have daily phone calls as a matter of routine.

We have a phone call only when there is something substantial to discuss, never to catch up on routine status. In other words, all our phone conferences are about interesting topics, like “What do you think about this idea…?” or “I met a customer today who brought up this problem…”; never about “Where are you with Task X?”.

Kerika keeps us in perfect sync across these 10,000 miles on all matters of routine status and project management, so our phone calls are all strategic in nature.

3.  Scrum for Product Development

We work with a 2-week Sprint Cycle for the most part, although we have occasionally deviated from this — never with great results, so sticking to the cycle is usually a good idea!

We capture all of our product ideas and feature requests in one large Scrum Board, which we call, simply, Product Planning.

This board organizes our ideas into various buckets, like Valuable for Enterprises and Valuable for Individuals:

Product Planning buckets
Product Planning buckets

You might notice that the Backlog column is relatively small: only 54 items. That’s because not everything in the other buckets is ready to go into the Backlog, either because a feature isn’t well defined enough, or it isn’t considered important enough to deal with in the short-term.

(We have a lot of ideas that sit and gestate for months, even years!)

It’s also worth noting that the Trash contains 62 items: this means we reject as many ideas as we pursue!

4. A Shared Backlog

As ideas for various features get prioritized — and, more importantly, defined clearly enough to be analyzed in detail by our developers — they get moved to the Backlog.

This backlog is shared by all the individual product development Scrum Boards:

Product Planning process
Product Planning process

(And, by the way, the screenshot above is from a Kerika Whiteboard that we use to map out our product planning process.)

Each Sprint is organized as a separate Scrum Board, pulling items from the common Backlog.

As items get done (or not, as the case may be), the Backlog slowly shrinks over time.

But, as ideas for new features gets firmed up on the Product Planning board, this keeps feeding more stuff into the Backlog. So, the net result is that our Backlog has remained the same size for years: about 50-60 items.

We have been doing this for a while now, and are currently wrapping up Sprint 55, with each Sprint taking at least 2 weeks, and several taking 1 month to complete.

Here’s an example of one of our Scrum Boards:

Scrum Board
Scrum Board

5. Kerika’s Smart Notifications

So, if we are a distributed team that doesn’t use email, and not that much phone either, how do we keep up with what’s happening? The answer is: Kerika’s smart notifications help each of us easily keep track of changes taking place across literally hundreds of cards each day.

Here’s an example:

Smart notifications
Smart notifications

At a glance we can tell that this card has

  • Moved
  • Has a new due date
  • Has new attachments
  • Has new (unread) chat messages
  • And, unfortunately, needs rework 🙁

These smart notifications replace dumb email with a much more efficient mechanism for keeping everyone on the same page.

6. The Development Process

If we open up one of these cards, we can get a glimpse of the Kerika development process. Let’s start with the chat thread on this card:

Example of new chat
Example of new chat

This chat shows a typical interaction between a junior developer and a technical lead: after writing the code for a particular feature, the developer has passed it on to the tech lead for code review.

The code review itself is attached to the card, as an attachment:

Adding code review to a card
Adding code review to a card

For each feature we develop, our engineers create a small work plan that outlines their design thinking.

This design/work plan is a critical artifact for good software development: it ensures that people can review the work more easily and effectively, and it also provides a reference for the future — if ever a bug is found in this particular feature, we can go back to the work plan to see where the design flaw may have originated.

The code review is typically very short, and attached (in this case) as a Google Doc:

Example of code review
Example of code review

 

7. Card History

Each card in Kerika keeps track of its own history, which makes it easy for a distributed team to keep track of everything that happened. Frequently, a number of changes may have taken place on a single card during a workday, and someone who is 10,000 miles away is also about 13 hours away in terms of timezones, so the history feature is useful for understanding all the changes that took place when you weren’t looking.

History of the work
History of the work

 

So, that’s a typical card, on a typical board. And, in a typical 2-week Sprint Cycle, our development team handles 175-200 cards!

We love Kerika, not just because we have built it, but because it makes our distributed team so very effective!

When you copy and paste a project, do you want the team too?

Here’s a new feature we are adding: when you copy and paste an entire project from one account to another, you can decide whether to take the team as well.

Consider these two scenarios:

  • Alice makes a copy of a project that she owns and pastes it right back into her own account. (Why? Well, maybe she wanted to make a backup copy, or maybe the actual project was going to split into two parallel efforts and so copying-and-pasting the entire project makes sense.)
  • Bob makes a copy of a project that Alice owns, and pastes it in his own account. (Of course, to do this Bob would need to have access to Alice’s project in the first place.)

In the first scenario, the duplicated project is showing up in the same account as it was before, so Kerika assumes that the team should be copied as well: in other words, “Project A” and “Copy of Project A” will both have the same team, at least to start with although each version of the board may then change its project teams independently of each other.

In the second scenario, however, it’s a little more murky: did Bob just want to copy the cards and canvases of Alice’s project, or is he trying to actually set up the same project in his own account? It’s hard for Kerika to make a really good guess in this scenario, so the system asks you:

If Bob responds “Yes” to this question, his copy of Alice’s project will also come with all the team members who were originally working on Alice’s project.

Of course, this might mean that Bob is now adding some folks to his account team: people he hadn’t worked with before.  These people are added automatically to Bob’s account team if he wants to take the team along with the project.

Our smart highlights are now even smarter

One of the coolest features in Kerika is how well the system alerts you to changes made on your Task Boards and Scrum Boards that you haven’t seen — i.e. because you were working on another board at the time your coworkers made changes, or maybe because you were fast asleep in a different timezone!

Whenever a coworker makes any change to a card that you haven’t seen — moving the card to a different column, changing its description, changing its tags, leaving some chat, etc., the change is highlighted on the card using orange.

Smart highlights
Smart highlights

And when you catch up on that change, e.g. open the card and read the new chat, the orange highlight gets turned off automatically.

(You can also mark a card’s changes as “read”, using the right-mouse-click menu.)

These smart highlights are great for distributed teams, and indeed for any person who is involved with multiple projects because it lets you catch up on what’s changed while you weren’t looking.

Now, these smart higlights are even smarter: if a card has multiple changes to it that you haven’t seen, e.g. it has a new attachment and it has new chat, Kerika keeps track of which changes you have caught up with, and which ones you haven’t.

In this example, if you read the chat, the orange highlight of the chat icon will go away, but the orange highlight of the attachments icon will remain until you catch up on the new attachments as well.

Kerika: getting smarter every day…

Kerika at the PMI Olympia Chapter

Arun Kumar, CEO of Kerika, and Beth Albertson, Solution Architect at Washington State’s Dept of Social and Health Services, gave a joint presentation at the Project Management Institute (PMI)’s Olympia chapter yesterday.

Beth talked about her experience in moving away from Microsoft Project to online task boards, and Arun talked about the general use of online task boards for distributed teams, Lean teams, and Agile teams, with a special focus on the public sector.

It was a great evening, with dinner served and some great Q&A afterwards!

Too bad we forgot to take pictures 🙁

Using Kerika to help fight Ebola

James Gien Varney-Wong is putting together global brainstorming team to work on creative solutions for fighting Ebola, and Kerika is helping the team share their ideas and content.

You can learn more about this effort at OpenIDEO, where James has embedded a small part of a massive Kerika Whiteboard that people from many countries are using to share their ideas:

Ideas for fighting Ebola
Ideas for fighting Ebola

It’s an exciting, large-scale use of Kerika Whiteboards, reminiscent of the work done by Charles Fraser for the Foundation for Common Good; you can see that Whiteboard page — as a regular Web page! — by clicking here.

Foundation for Common Good
Foundation for Common Good (Click to see the Whiteboard)

 

A great response at the Lean Transformation Conference

Our presentation on Distributed Lean & Agile Teams in the Public Sector at the Lean Transformation Conference last week was very well received: the presentation was given on both days of the conference, and attendees were polled by the conference organizers on whether they liked the talks, or not.

  • Session 1 (Tuesday): 100% of the attendees who provided feedback gave Arun‘s talk a thumbs-up.
  • Session 2 (Wednesday): 96% of attendees who provided feedback gave Arun’s talk a thumbs-up!
Arun at Lean Transformation Conference 2014
Arun at Lean Transformation Conference 2014

The Results Washington folks have produced a short video featuring attendees at the conference — we recognize a user or two 🙂