Monthly Archives: August 2014

Using status indicators on Task Boards and Scrum Boards: “Ready to Pull”

(The first in a series of blog posts on how you can make use of the status indicators on cards, in Task Boards and Scrum Boards.)

Kerika makes it really easy to flag cards on a board, if you need to alert your team members; here’s an example:

Examples of status flags on cards
Examples of status flags on cards

There are several statuses that you can report on cards (in addition to “Normal”, the default setting), and we will try to provide some advice in these blog posts on how best to use them.

First up: “Ready to Pull”

Setting status
Setting status

Ready to Pull is great if your team works in a “pull” environment, rather than a “push” environment. Here’s the easiest way to differentiate between the two:

  • In a “push” environment, work gets pushed onto people — quite literally. For example, Project Leaders (or even Team Members) decide that a particular card should be handled by a particular person, and they assign that card to that person: in other words, they push that work onto people.
  • In a “pull” environment, people only assign work to themselves: as they get freed up from whatever they are working on, they look at the board and pick up whatever task is waiting to be pulled (i.e. done) — in other words, they pick up a card that is marked as “Ready to Pull”.

There are advantages and disadvantages to both models, and it’s really a question of how your team prefers to work.

Particularly in organizations that are still transitioning from traditional (Waterfall-style) project management, the push model can be the easiest way to adopt a tool like Kerika: it helps retain the traditional role of a Project Leader as someone who is responsible for the assignment of work among the team.

This is definitely the easiest pathway for organizations that are still in the process of transitioning to a Lean or Agile model — a process that can take months in most cases.

There are, however, some disadvantages to the push model:

  • It can delay the organization’s cultural transformation to Lean/Agile: people feel less empowered, and can be more passive if they wait for work to get pushed to them by others.
  • A less empowered team is often slower to take the initiative.
  • Someone who has had work pushed onto them may feel less ownership of the outcome.
  • It provides a misleading picture of what’s actually getting done: this, in our experience, is the biggest shortcoming of the pull model!

When work gets pushed onto people, you can find that individuals have 10 or more items currently assigned to them. There’s no way they could be working on all 10 items at the same time, so one of the biggest advantages of Kerika — providing an accurate, real-time view of what’s getting done, and by whom — is somewhat negated.

The pull model is truer to the spirit of Kanban: it allows people to work at their own (true) pace, and empowers them to pick up new work as they get freed up — or blocked.

The Kerika team itself has transitioned from push to pull: with push we never had a true sense of what’s getting done; with pull, we do!

There are disadvantages to the pull model:

  • It requires more training and cultural change up-front: even for a team that generally feels empowered, it is a big shift in thinking and process to move from push to pull.
  • It can require a more complex workflow: for example, here’s a partial (!) view of the workflow that we adopted as part of transitioning to Pull, to make it work within our constraints:
Understanding the Pull Model
Understanding the Pull Model

Pull is best implemented in conjunction with Work-In-Progress (WIP) Limits, which is a feature that we will be adding shortly to Kerika.

So, how should you use “Ready to Pull” as a status indicator?

If you are working in a push model, there’s nothing to do: you don’t need this feature.

If you are working in a pull model, whenever a user is done with a piece of work, she should mark it as “Ready to Pull”, and then take her name off the card.This will clearly signal the rest of the team that the work item is ready to be taken on by someone else.

All posts in this series:

Partial searches just got easier in Kerika

Thanks to feedback from users at Washington State’s Department of Fish and Wildlife (hat-tip to Ryan Koval & team!) we improved our Search feature to make it easier to do wild-card searches.

Wildcard searches let you easily find anything, anywhere in Kerika, by just typing in a little bit of text — as little as a single character — and get back results that match on that text.

(Of course, typing in just a single character will return too many results to be useful… :-) )

In general, there are two ways to do partial searches:

  • By implementing wildcards in the query that the Kerika user interface delivers to the Solr search engine that we have implemented.
  • By using a NGram Filter or an EdgeNGram filter.

Using filters could result in a huge increase in disk space utilization, and a significant drop in performance, so we opted for the wildcard approach instead.

To implement the wildcard query, we manipulate two variables in Solr: PARTIAL_MATCH_BOOST and EXACT_MATCH_BOOST.

  •  If you search with just one keyword, we show you the exact matches first, and then partial matches: we use PARTIAL_MATCH_BOOST and don’t use EXACT_MATCH_BOOST.
  • If you search with multiple keywords, we show you the results that match across all keywords first, using EXACT_MATCH_BOOST, and don’t use PARTIAL_MATCH_BOOST.

There are more ways of fine-tuning search, of course, but for now we seem to have made enough of an improvement to keep our users happy!

Internet Explorer remains the odd man out on tablets

We have been putting in a ton of effort to improve the Kerika user experience on tablets: while Kerika runs OK in the Safari and Chrome browsers on iPads, the experience is somewhat uneven across other tablets, particularly Android and Windows tablets and “convertibles”.

It’s a little frustrating to find so many oddities about Internet Explorer 11 (the latest, greatest version from Microsoft) when it comes to Windows 8.1 tablets and convertibles.

Looking at our internal Scrum Board for our tablet work, we are struck by the many ways in which the touch and swipe gestures in Internet Explorer are different from the Webkit-based browsers (Safari and Chrome):

IE11 problems

I met my old lover
On the street last night
She seemed so glad to see me
I just smiled
And we talked about some old times
And we drank ourselves some beers
Still crazy after all these years
Oh, still crazy after all these years

Internet Explorer remains the odd man out on tablets

We have been putting in a ton of effort to improve the Kerika user experience on tablets: while Kerika runs OK in the Safari and Chrome browsers on iPads, the experience is somewhat uneven across other tablets, particularly Android and Windows tablets and “convertibles”.

It’s a little frustrating to find so many oddities about Internet Explorer 11 (the latest, greatest version from Microsoft) when it comes to Windows 8.1 tablets and convertibles.

Looking at our internal Scrum Board for our tablet work, we are struck by the many ways in which the touch and swipe gestures in Internet Explorer are different from the Webkit-based browsers (Safari and Chrome):

IE11 problems

I met my old lover
On the street last night
She seemed so glad to see me
I just smiled
And we talked about some old times
And we drank ourselves some beers
Still crazy after all these years
Oh, still crazy after all these years