Category Archives: Technology

Posts related to technology in general

Box vs. Google: what’s different, if you are a Kerika user?

Technology, Usability,

We got an email this morning from a user that we decided to answer here, because the topic is relevant to many of our old users…

We are wondering what the differences between Box vs Google are going to be. Also, if we move over to a Kerika+Box account, will we have to rebuild what we have set up in Kerika+Google?

To answer the first question: the Kerika user interface is the same, whether you use Kerika+Box or Kerika+Google.

And, we fully intend to keep the user interface the same across these two cloud storage platforms — and any others that we might support in the future.

That said, the Kerika user experience, which is more than just the user interface, is a little different due to the quirks of Box vs. Google.

For example, Box makes it really easy to sign up as a new user, and keep your old email account.  You can do that with Google, too, but it’s a lot more cumbersome.

Box also works really well with Microsoft Office files: Box doesn’t try to convert your files into it’s own proprietary format, i.e. it doesn’t have its version of Google Docs, so if you like working with Microsoft Office, Kerika+Box is probably the better choice.

(Note: it’s possible to use Kerika+Google and not have your files converted to Google Docs, by setting a user preference, but that kind of misses the point of using Kerika+Google in the first place…)

If you like to view and edit your files right in the browser, then Kerika+Google is the better choice because Google Docs is getting better all the time.

For both Kerika+Google and Kerika+Box, we try to make sure all your Kerika-related files are neatly stored within your own cloud platform, but that’s a little better on Kerika+Google than with Kerika+Box:

Google allows Kerika to create as many nested folders as we need, which means that you only see a top-level folder called “Kerika.com” when you view your Google Drive, and all your projects, across all the accounts you work with, are all stored inside here.

Box doesn’t allow us to create nested folders in the same way, so you will see a lot more top-level folders in your Box account as your Kerika collaboration network grows.

So, the same user interface for both Kerika+Google and Kerika+Box, but a slightly different user experience with pros and cons for both Google and Box.

And the user interface will remain the same in the future: we have no intention of adding features that will only work with Google or Box — only features that will work well with both.

Now, for the second question: if you create a new Kerika+Box account, you will need to create new projects in this account because it is not connected in any way to your Kerika+Google account.

This may be a bummer for some of our old users who have a lot of projects built up using their Kerika+Google accounts, and now want to switch over to using Kerika+Box.

The reason this limitation exists is that the underlying cloud platforms are completely different, and come from two companies that are competing with each other rather than collaborating in any way.

This makes is impossible for us to move content from a Kerika+Google account over to a new Kerika+Box account, even if they are owned by the same user, since even if we tried to move over all the cards, boards and canvases, we wouldn’t be able to automatically move over any related files.

Sorry about that :-(

Partial searches just got easier in Kerika

Technology, Usability,

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

Technology

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

Microsoft Project for Agile?

Kerika, Technology,

On LinkedIn’s Scrum Alliance group someone recently posed this question:

Which is more effective agile software project management tool MS Project or a agile software project management tool for implementing scrum?

Here’s my response:

I started using MS Project around 1989 — must have been close to v1.0, I imagine — and even back then, when it was a relatively simple tool, it never delivered enough utility to warrant the immense hassle of trying to keep it updated so that it actually reflected the reality of a fast-moving project.

The phrase that came to mind often was “I have to feed the beast again“, i.e. I have to spend hours each day trying to map all the real-time changes that were happening in the real-world to the fake world modeled in MS Project.

The MS Project world wasn’t fake because I was incompetent: it was fake because it was always instantly out-of-date.

And as MS Project has gotten larded with more bells and whistles, it has never been able to address its fundamental shortcoming: it is a theoretical model of what you would like your project to be, rather than a practical/actual reflection of what your project is.

So, even back in the 1980s, before people were talking about Agile and Scrum, we were all actually living in an Agile/Scrum world; we just didn’t have that realization, and we didn’t have the appropriate tools to deal with a fast-changing project environment.

At  Kerika, we live and breathe in a distributed Agile world: our team is spread out between Seattle and India, which means we never have any overlapping time, but by using Kerika scrum boards we are in perfect synch with each other.

We know exactly what everyone else is up to, and we are able to process, on average, 10-12 cards per week, per person, on a sustained basis.

Kerika also has a whiteboard capability so we are able to do brainstorming and design work.

Is MS Project useful for anything at all? Yes, if your project…

a) Is considered immutable from the very start.

An example would be a government contract which is negotiated up-front in painful detail, and your success is defined only in terms of whether you delivered exactly what was specified, not whether the final product was useful. (Business-as-usual for most Federal contracts.)

b) Every aspect of the technology has been prototyped, tested, and proven already, so uncertainties are minimized.

This is an interesting use-case of mixing Scrum and Waterfall that’s not explored very often, where you use Agile to do your R&D and figure out workable solutions to your biggest uncertainties, and then use Waterfall to build the final version.

How can you handle defects that are found after a user story has been accepted and released to Production?

Agile & Scrum, Technology

In a recent post on the Scrum Alliance forum at LinkedIn, a member asked this question:

How do teams handle defects that have been found after a user story has been accepted and released to Production?

My first thought was to just log a defect against the user story, but that screws up reporting as it removes the Accepted status. Executives do not want to see that. I am thinking we should just create a new user story and slate it for the next Sprint. ?

My answer:

Defects are bound to be found after a story has been accepted and released to production; that’s just a very normal part of software development, so it makes sense to add them to the Product Backlog to prioritize for a future Sprint.

There isn’t any need to take the “Accepted” status off a story that was already considered done within an older Sprint: “Accepted” doesn’t mean “super-excellent and done for all time”; it just means it was considered good enough by the Product Owner at the conclusion of the Sprint, and therefore accepted.

To “un-accept” stories post facto would not just screw up your reporting; it would start to create an unhealthy dynamic between the Scrum team and the Product Owner, where the Product Owner starts to believe he can reject stories post facto.

For Scrum to work well as a process, you need to get everyone to buy into the core idea that stuff gets done in iterations; new stuff gets done in new iterations; old stuff gets improved in future iterations.

On a more tactical level, Kerika lets you link together individual cards or even entire Scrum Boards, because every board, every card, every canvas has a unique URL that you can reference anywhere in the system to create dynamic links between stories and boards.

So, if we find a bug in a previously accepted story, we create a new card for that and simply reference the old card in the new card’s details.  Here’s a video that shows how that’s easy with Kerika.

Consider killing some of your bright ideas

Technology, Usability

Something that we have learned in the course of making Kerika the best designed tool for work management: don’t rush to implement all of your bright ideas!

When we observe a usability problem, we tend to get riled up rather quickly because we take such pride in our work.

The result is a bunch of really good ideas about how to fix the problem.

And to improve the fix.

And to make the fix even better.

(You can probably see where this is going…)

It’s really easy to over-fix a usability problem, by applying too many fixes, too fast.

Here’s another approach you can try:

  • Collect all your bright ideas.
  • Sort them, so you have only really good ideas.
  • Now, implement the smallest change that you think will fix the problem.
  • And then, eat your dogfood: use the improved product for a week at least, and see if the small change was sufficient.

We have found this is a good remedy to the more common problem of over-designing a solution: rather than build an unnecessarily complex change, or one that creates its own usability problem — often by making a subtle change in the UI metaphors that the user has already learned by mastering other parts of the product.

Paying down technical debt when working with a Scrum team

Agile & Scrum, Kerika, Technology,

Another question answered on LinkedIn’s Scale Agile group: The team is facing a high Technical debt before adopting Scrum. Now, they want to fix this. How could they include this in the Sprint?

If you already have a lot of technical debt, I would recommend that the first few Sprints do nothing but clear the most expensive debt.

The trick is to persuade the Product Owner that this is necessary, because it means deferring any delivery of “real features” while the debt is paid down.

Note that I say “paid down” rather than “paid off”: in my experience, there is rarely an opportunity to completely pay off technical debt and have a clean Product Backlog with nothing in it but nice user stories that deliver tons of end-user functionality.

At Kerika, we have found that we accumulate some debt almost continuously, and that this is unavoidable even though we are using Scrum.

Purists might argue that a true Scrum model eliminates technical debt, but this is unrealistic when you are dealing with a fast moving market and are focused on rapidly improving your product.

Periodically, we devote an entire Sprint to paying down technical debt. We did one fairly recently because we are in the process of adding some substantial new functionality: Kerika will now become the first Scrum/Kanban/Scrumban tool that has full integration with both Google Drive and Box for sharing project files within distributed team ;-)

Because this was a major platform enhancement, we took a 3-week Sprint to pay down our technical debt by clearing a bunch of bugs and server exceptions that individually were never going to make it to the top of the Product Backlog.

The Kerika tool makes it really easy to tag items, so it was easy for us to find all the bugs that were in our (rather large) Product Backlog and we cleared nearly 50 items.

Actually, this was our second debt payoff Sprint this year: in April, the Heartbleed scare prompted us to do a full internal review of our security processes, which morphed into a full review/overhaul of our QA and other software development infrastructure/process stuff, and we spent an entire Sprint to significantly clean up a bunch of stuff that had been moldering a while.

For what it’s worth, we generally do an all-hands-on-deck Sprint to pay down debt: we don’t try to sneak in any new product features because I find that it sends a confusing message to the team about the importance of paying down the debt.

I said earlier that often the big challenge is convincing the Product Owner of the need to devote a Sprint or two to pay down debt; in our case that’s relatively easy because I am the founder/CEO and buy into the idea ;-) but I do believe that if you are going to pay down debt, you need to do it with serious intent and get everyone focused on that, which means the Sprint is all about debt, not new goodies.

Is Kanban a better way to manage support/maintenance work than Scrum?

Agile & Scrum, Kanban & Lean, Kerika, Technology, , ,

Hi folks!

I recently offered my thoughts to the Scrum Alliance group on LinkedIn, on the discussion thread on whether
Kanban is a better way to manage support/maintenance work than scrum. I thought you might find it interesting:

Kanban is generally a better model for support/maintenance: these tasks tend to trickle in, so trying to handle them with a conventional Product Backlog is often awkward.

Support/maintenance tasks are also usually unrelated to each other: one bug fix may have nothing to do with another.

This makes for a different metaphor than Scrum/Product Backlog where there is some presumption that user stories and tasks, while perhaps independent, are at least part of a larger product or release theme.

If you did support/maintenance tasks in a Sprint, that Sprint would have no overarching theme which I strongly believe is essential for success with Scrum teams.

And if any team doing support/maintenance with Scrum will quickly realize their Sprints are unlike those of other teams that are doing product development with Scrum.

I would view your questions about swimlanes as arising from a misfitting metaphor: instead of using swimlanes, you would be better off using tags, and then filtering your board as needed to see all support/maintenance tasks related to a particular subsystem or process or person. E.g. “show me all the tasks related to the database schema”.

We use our own product (Kerika) of course, and we do all of our new product development with Scrum Board, and support/maintenance with Kanban boards since Kerika lets you easily have both kinds of boards.

We use multiple tags on each card on both the Kanban and Scrum Boards, so we can filter and search, e.g. “show everything related to our Google Drive integration”.

These filtered views are much more effective and flexible than trying to organize your board with swimlanes, because each card can have multiple tags, whereas with swimlanes a card would be in only one swimlane at any time.

Also, this arrangement gives us flexibility to move from Kanban to Scrum and back: for example, if a support/maintenance card that originally landed on a Kanban board is later deemed to be significant enough to handle as part of product development, we can just cut-and-paste that card from the Kanban board to the Scum Board, and Kerika brings along all the content, history, attachments, chat, etc.