Category Archives: Technology

Posts related to technology in general.

More ways for Project Leaders to get smart email notifications when changes take place on your projects

Technology, Usability

We are adding a bunch of new ways in which Project Leaders can choose to get email notifications when there are important changes taking place on their project boards; these include the following:

  • Email me when cards are added to my project: if new cards are added to a board where you are one of the Project Leaders, you can get an email notification. By default, this is turned ON: it’s a useful way for Project Leaders to know when the work expected of the team, particularly in Scrum projects, is increasing. (Team Members never get emailed when new cards are added.)
  • Email me when cards on my projects are marked Done: if any cards are moved to the Done column on a Task Board or Scrum Board, the Project Leaders can get notified by email. By default, this is also turned ON. (And Team Members never get emailed.)
  • Email me chat messages on cards in my projects: this is actually a two-part change that we are making. Previously, everyone who was part of a project got an email if there was any chat on a card. Now, this is more targeted:
    • If a card is assigned to one or more people, chat messages are emailed only to the assigned people. This reduces the overall volume of emails sent by Kerika by targeting only those folks who care the most about a particular card.
    • If a card isn’t assigned to anyone, chat messages are sent to everyone who is part of the team. Here, our assumption is that if you are writing a message about an unassigned card, you would like to get everyone’s attention with that message. For example, you might be suggesting a path forward for an unassigned card, or calling attention to an issue that isn’t assigned to anyone to fix.
    • Project Leaders can choose to be part of the chat notifications for all cards, even if they aren’t assigned to these cards, and this is a new preference setting that we have created with a default value of Off. So, if you are a Project Leader that would like to know about each and every chat message on your project boards, you could turn this preference On.
  • Email me general chat messages: this refers to chat that takes place on the board itself, that isn’t tied to any particular card. Chat that takes place on the board itself is usually intended for the entire team, so this preference setting applies to Project Leaders and Team Members. By default, this is turned On.
  • Email me when cards in my projects are reassigned: when a card is reassigned, i.e. an old team member is taken off a card, or a new person added, everyone affected by the change is notified by email: the people who were formerly assigned the card, and the new people. This is an easy way for you to know when someone expects you to handle some new work, or, conversely, if someone else is now expected to do the work that had previously been assigned to you. We have added a new preference setting for Project Leaders to be told, by email, when cards are reassigned: this is an easy way for you to know that your team has self-organized itself to handle its work differently.

All these changes means that your Preferences page, which is always found at https://kerika.com/preferences, now looks like this:

Your new Kerika preferences page
Your new Kerika preferences page

We have been using these new features internally for the past couple of weeks, and have found them to be really useful!

Card history on project boards in Kerika

Technology, Usability,

The next release of Kerika will include a bunch of bug fixes and usability improvements, as usual, but a big new feature that we hope you will find useful is Card History: every card will contain a succinct history of everything that’s happened to it, since it was created.

Here’s an example:

Card history
Card history

Our implementation of this new feature is actually kind of clever, under the covers (of course!): rather than log every action immediately we wait a little to see if the user changes her mind about the action.

So, for example, if a user moves a card to Done, and then moves it back to another column soon afterwards, the Card History doesn’t show the intermediate action since the user clearly changed her mind about whether that work item was actually done or not. In other words, the system is forgiving of user errors: an important design principle that we have tried to adopt elsewhere as well.

Because the Kerika user interface makes it so easy to make changes to your task board, a built-in delay in the history is necessary to avoid creating a “noisy” or “spammy” history.

From a technical perspective, the most interesting aspect of creating this new feature was that we expanded our infrastructure to include Amazon’s DynamoDB.

DynamoDB is a fast, fully managed NoSQL database service that makes it simple and cost-effective to store and retrieve any amount of data, and serve any level of request traffic. This is our first foray into using NoSQL databases; up to now we had been exclusively using MySQL.

 

The most baffling shortcoming of Apple’s Maps

Technology, Usability

Of all the many shortcomings of Apple’s Maps program, the one that we find most baffling is that it doesn’t seem to use GPS for its most basic function: looking up an address.

Here’s an example: we make an appointment in our (Apple-made) Calendar program on our (Apple-made) iPhone, that references the local office of one our users.

The original calendar entry

In King County, Washington, every address is based upon a giant coordinate system, so it isn’t really necessary to specify the city of an address. The “NE” in the street name refers to “North East”, not Nebraska, and no one in King County would ever think of looking up a street address by first considering Nebraska as a possibility. And, yet, that’s precisely what Apple’s Maps program suggest: rather than using the GPS that’s built into every Apple iPhone ever made, it assumes that our next appointment is probably 15 states away, rather than 15 minutes away by car:

Apple Maps

Google’s Maps program, on the other hand, is very much GPS-aware, and the suggestions it offers are locations that are closest to where the phone is, not furthest away:

Google Maps

Why on earth (no pun intended) would Apple produce a map program for its phones that doesn’t make use of the phone’s most important feature — it’s ability to know where it is?

Security screening of new employees: a new process template, brought to you by HISPI

Technology

We are exploring a collaboration with the Holistic Information Security Practitioner’s Institute (HISPI) to create Kerika process templates focused on best practices in security.

The first of these is now available: how to do a security screening for new employees.

This template is available to all Kerika users, of course, and will be improved in the future as we continue to work with HISPI.

 

Facebook Home on Android: a great way to monetize the addicts

Ephemera, Technology

In many industries, a small proportion of the users will consume a disproportionate amount of the product, and will provide the vast bulk of a company’s profit.

This is true in the beer business for example: the beer companies have long known that a small percentage of their customers will drink a vast amount of beer every day. (This factoid used to be a staple of marketing classes in the 1980s, when it was offered as an example of the 80:20 rule — 20% of the consumers will drink 80% of the beer. Which actually amounts to about a case of beer a day…)

It is also true for Software-as-a-Service (SaaS) businesses: Forbes reported in 2011, for example, that just 4% of Dropbox’s users pay for the service, and yet Dropbox is a growing, profitable company! The other 96% contribute indirectly, by adding to the network effect and recruiting others who have a 4% probability of becoming a paid-up subscriber of Dropbox.

These percentages can seem small, but they can quickly add up when you have millions of users.

Facebook has a similar profile of users: a small number of people are logged in obsessively, and these will provide the bulk of their advertising revenues — not just because they are more like to see the advertisements, but because they are more likely to view Facebook as a trusted source of useful content.

In this context, creating Facebook Home on Android makes a lot of sense: it doesn’t matter whether a very large proportion of your user base never uses it, if you can get the addicted segment to be logged in all the time. These people will drink all the beer you are selling.

How Kerika integrates with your Google Contacts

Technology, Usability

When you sign up for Kerika, using your Google ID, you get sent to an authorization screen where Google asks whether it is OK for Kerika to access some of your Google-related information. One part of this involves access to your Google Contacts.

We often get queries about this, so we thought we would clarify something that’s really important: we don’t use your Google contacts to spam your friends and coworkers!

The Google Contacts are used for one reason only: to provide an auto-completion of names and email addresses when you are adding people to a project team. Here’s a simple illustration:

Adding people to a project team
Adding people to a project team

To add people to a project team, you would click on the People button, which appears on the top-right corner of the Kerika application, and this would show a display similar to the example above, where all the members of your project team are listed (along with their roles). To add a new person, you would click on the +Member link at the top, and then start typing in a name or email address:

Enter a name or email address
Enter a name or email address

As you type in a name or email address, we pass on this string to Google which tries to match it up with entries in your Google contacts. These entries start showing up immediately, and get filtered progressively as you type in more characters:

Matching names against your Google Contacts
Matching names against your Google Contacts

This matching of names and emails is done by Google, which means Kerika never has direct access to your Google Contacts!

This auto-completion is a handy feature: it eliminates a major source of errors, which is mistyping email addresses. This means that the chances of you inviting the wrong person to your project are much lower!

 

 

A new template for our users: The Business Model Canvas

Technology

We have added a new template for our users: The Business Model Canvas.

The Business Model Canvas is an increasingly popular tool for startups to systematically analyze their proposed business model by identifying:

  • Key Partners
  • Key Activities
  • Key Resources
  • Value Propositions
  • Customer Relationships
  • Channels
  • Customer Segments
  • Cost Structure
  • Revenue Streams

Using this template is easy: when you start a new project, you will find “Business Model Canvas” among the choices for Task Board projects:

Selecting the Business Model Canvas as the template
Selecting the Business Model Canvas as the template

You can also access the template directly at https://kerika.com/m/GFXC, and click on the “Use this template” button on the upper-right corner to get started fast.

Once you start your new project using this template, your task board looks like this:

Using the Business Model Canvas
Using the Business Model Canvas (Click to enlarge)

Each of the main sections of the Business Model Canvas are presented as columns on this task board, and you can customize this as you like:

Customizing the Business Model Canvas
Customizing the Business Model Canvas

Individual cards on this task board are setup and ready for you to fill in; here’s an example:

Individual cards for the Business Model Canvas
Individual cards for the Business Model Canvas (Click to enlarge)

The card shown above, as an example, can be used to identify one of your key suppliers. For this supplier (and for all of your other key suppliers), you should identify the motivations of this supplier: why this supplier would want to do business with you? Motivations could include:

  • Supplier is seeking optimizations and economies of scale
  • Supplier is seeking to reduce risk and uncertainty
  • Supplier is looking to acquire particular resources and activities.

For each supplier, you should identify the key activities that will be performed: this can added to a simple Google Doc, and attached to this card. (We have provided Google Docs templates for individual cards.)

And, finally, for each supplier you should identify the key resources that will be acquired; this can be added to the same Google Doc, or listed separately.

In this way you can easily work through the business model canvases various steps.

Using a process template like Kerika’s is vastly superior to simply printing out a large poster of the canvas, because the cards in the Kerika process template can be used to support conversations, manage content, track status, and collaborate across multiple locations: and that’s just not possible with a paper canvas!

The Business Model Canvas is also gaining popularity within larger organizations that are seeking to adopt (and adapt?) lean startup principles, so we expect that this new template will be of interest to a wide variety of users. And, by the way, creating this template is just part of an ongoing process here at Kerika, to capture and present best practices for a variety of professions and industries!

Agile for large and distributed teams: conversations with Al Shalloway, Mike DeAngelo and the Wikispeed team

Kerika, Team Collaboration, Technology

Three great conversations about Agile and Scrum in recent days, with Al Shalloway of the Lean Software and Systems Consortium in Seattle; Mike DeAngelo, Deputy CIO of the State of Washington; and Clay Osterman and Joe Justice from Team WIKISPEED in Lynnwood. Common threads in these conversations:

  • Scaling up Scrum to large projects (e.g. the global WIKISPEED team numbers close to 300 people), and
  • Adapting Scrum for distributed teams (where people are located in multiple offices).

Agile purists might well recoil at the prospect of Scrum teams that can’t be fed with a single large pizza (the traditional rule-of-thumb for the optimal team size, still followed at companies like Amazon) or having to deal with people in multiple locations that can’t have face-to-face contact., but these are real-world problems for many organizations, and simply saying “No”, because the idea of very large or distributed teams offends one’s theology about Agile, isn’t a useful stance to take.

Increasingly, large organizations are distributed across cities, timezones, and even continents, and complex systems require large delivery teams. A pragmatic approach is necessary, not a purist one: we need to consider how we can adapt the basic principles of Scrum to meet the real-world needs of large organizations. Here are some lessons learned over the years in how to adapt Scrum for large or distributed teams:

  • Let multiple project teams push/pull items from a single Backlog, so that many small teams can work in parallel on a single system, rather than a single, large team take on the entire Backlog. This requires coordination among the various teams through a “Scrum of Scrums”: each individual team does it’s Daily Standup, and then the Scrum Masters of each team participate in a second meta-Standup where they report to each other on their particular teams’ progress and impediments.
    To succeed, you need project tools that make it very easy to have multiple teams push and pull items from a single Backlog. The project management system must make it easy for any any member of any team to have real-time visibility into the progress of every other team, so that the task of managing dependencies can be pushed down to individual team members rather than concentrated within the Scrum Masters. (Leaving it up to the Scrum Masters alone to manage all the inter-dependencies leaves you with the same single-point-of-failure that you have with traditional Waterfall approaches.)
  • Try stay within the “1 large pizza” size for individual teams. There’s a simple, practical reason why you should avoid having individual teams become much more than 8 in number: the Daily Standup takes too long, and people start to either under-report, or tune out much of the discussion.

    If a team has 20 people for example, and each person simply took 30 seconds to say what they had done, 30 seconds for what they plan to do next, and 30 seconds to describe impediments, that still adds up to a 30-minute long Standup!

    When faced with a Daily Standup that has become something of an ordeal, people tend to under-report, as a coping mechanism, and, frequently, what they under-report (under-discuss?) are the impediments.

    This can be fatal to the team’s overall success: problems and worries are not discussed very well, and eventually accumulate to the point where they become fatally large.

  • Split up the work, not the team. If your people are distributed across multiple locations, it is far better to split up the work rather than the teams: in other words, give each location a different set of deliverables, rather than try to get people working in several locations to work on the same deliverables.
    Too many organizations, particularly when they first built onshore-offshore teams, cling to the myth of “following the sun”: the idea that a team in India, for example, could work on a deliverable during Indian working hours, and then hand that work off at the end of the day to a California-based team that is conveniently 12-hours away.

    This is the myth of continuous work: the notion that the same deliverable can effectively be worked on 24 hours a day, by having two shifts of people work on it in non-overlapping timezones.This simply doesn’t work for most knowledge-intensive professions, like software development or product design.

    A huge effort is needed to hand over work at the end of each workday, and invariably there is a significant impact upon the work-life balance of the people involved: either the India team or the California team, in our example, would have to sacrifice their evenings in order to accommodate regular phone calls with the other team. Eventually (sooner rather than later), people get burned out by having their workdays extend into their evenings on a regular basis, and you are faced with high turnover.
    Splitting up the work means you can have loosely-coupled teams, where there isn’t the same burden of keeping every person aligned on a daily basis. A project tool that makes it easy for everyone to have a real-time view of everyone else’s work is essential, of course, but you no longer have to have Standups that would otherwise easily take up an hour each day.

What do you think? Let us know your best practices!

Another week, another update: this time, it’s mostly styling (and better user management)

Kerika, Technology, Usability

We are trying to get back to a faster rhythm of releases. Our goal is to have releases within 3 weeks: we want to complete our development and QA within 2 weeks, and then use the third week for “dogfooding” the software.

(As you might expect, we are fervent users of Kerika! Everything related to our business is done using Kerika project boards, and to make sure we are putting out the best possible product, we use a daily build of the software on a test server. This keeps us firmly on the bleeding edge of our own software development: it means that we get to try out our software in a real-life scenario — one that is absolutely mission-critical for the company! — before we pass it on to our users.)

Our newest version, released today, contains a number of under-the-hood fixes that will help us manage our growing number of users. And, we are happy to report, our users are indeed growing: we are adding new users in March at twice the rate we did in February!

From your perspective, it’s mostly some styling and minor user interface changes that will be visible. We have a better way to expose the Cut, Copy, Paste and Delete functions for cards, having heard from too many users that they couldn’t easily figure out how to delete projects, we have more uniform use of colors, and there is a right-click menu for dealing with project cards as well as task cards.

The more uniform use of colors is a step towards a larger update/refresh of our look-and-feel. We have been hearing from users that our user interface is “too grey”, and we are working on that issue. We are also looking at improved notifications, both onscreen and through emails. Stay tuned!

A comprehensive template for implementing an Electronic Health Records system

Kerika, Technology

With help from Paul Seville, MD, MBI, CSM, (who, by the way is a very impressive guy: experienced physician turned informatist!) Kerika is now offering a comprehensive process template for medical practices that need to implement an Electronic Health Records system: the template deals with all the stages of an EHR implementation, as recommended by the authoritative folks over at HealthIT.gov:

  • Stage 1: Assess Practice Readiness. This comes with 7 cards, representing the key work items needed to complete this stage.
  • Stage 2: Plan your Approach. 9 work items that include document templates for analyzing and mapping your practice’s current and future workflow.
  • Stage 3: Select or Upgrade to a EHR. 8 cards along with templates for evaluating vendors.
  • Stage 4: Conduct Training & Implement EHR. Checklists and templates for test plans for the implementation stage.
  • Stage 5: Achieve Meaningful Use. This is the most critical phase of implementing an EHR, of course, and we have cards for each of the 15 “Core Measures” and each of the 10 “Menu Measures” recommended by the government.
  • Stage 6: Continue Quality Improvement. This includes templates for conducting patient surveys.

This is the master process template for health informatics: over the coming days we will be providing more focused templates for each of the sub-projects involved in deploying an EHR: for example, templates for each of the Meaningful Use measures.

This project template includes a large number of document templates for the individual work items (e.g. a spreadsheet that you can use to evaluate EHR vendors). All document templates are available in Microsoft Office format as well through Google Docs.

These templates are available to everyone, right now: when you start a new project, you will find “Implementing an EHR” among the choices for Task Board projects:

Selecting a process template
Selecting a process template

When you use a Kerika project template, you also get copies of all the document templates that are part of the project template. These are copied into your own Google Drive account, and can be shared with others on your project team.

Please let us know know what other templates you would like to see! (And our thanks to Dr. Seville for help with this particular template.)