Category Archives: Technology

Posts related to technology in general.

A new template for tracking bugs and defects

We just added another project template, for Kanban / Task Boards, that you can use to track and manage bugs/defects in a software or hardware product.

Bug Tracking Template
Click here to view this template

Here’s how it works:

  1. As new bugs/defects are found, add them to the Pending column. This is a holding area for new defects, before they get evaluated and prioritized.
  2. On a daily basis the Product Owner should evaluate items in the Pending column, considering both severity and priority.

    Severity is not the same as Priority: if a defect has a serious consequence, e.g. a software bug that causes data loss, then it would have a high Severity rating.

    But, some defects show up only rarely. So, you might have a defect with a serious consequence that happens very rarely, or affects very few users. In that case, you may want to reduce its priority.

    On the other hand, you may have a defect that is trivial, e.g. a confusing term on a website, but is a real annoyance for everyone. This bug could low severity, but high priority — because fixing it would immediately benefit a lot of your users.

  3. As the Product Owner evaluates each bug, it gets moved to the appropriate column: Fix Immediately, Fix Soon, or Deferred. Within each column, you can further prioritize bugs by moving the most important ones to the top of the column.

    Fix Immediately is for the most critical bugs; typically these need to be resolved with a day or two, and the software update may need to be delivered as a hotfix if the normal release cycle is too long.

    Fix Soon is for bugs that you definitely need to fix, but which are not super-critical.

    Deferred is for bugs that you are not likely to fix anytime soon. (If you don’t plan to fix a bug at all, move it to the Trash.)

  4. As each bug is picked up by a team member, move the card to In Progress, and assign the card to the team member: once someone’s face shows up on the card, it’s clear to everyone that the bug is being worked on, and by whom.
  5. As appropriate, use review processes to review and test the fix before moving it to Ready for Deployment.
  6. Use tags that make sense: we have set up some sample tags for this template; if they don’t make sense, use whatever tags will work best for your team! (There’s a short video on how tags work, attached to this card.)

Another round of bug bashing…

Our current release (Sprint No. 37 since we moved to a Scrum methodology!) is focused on bug bashing: mostly server-related bugs, and a few that users might have observed themselves.

This is fairly typical of our development cycles: while we fix major bugs in every release, every once in a while we spend an entire release on just general bug bashing and cleanup.  These offer opportunities to catch up on infrastructure improvements, getting our test cases in better shape and other administrative work.

Release 37 should be done, with testing, by the end of the week: it will have about 65 work items completed, with another 21 items that were trashed.

Trashed items are usually duplicates of bugs: different symptoms with the same underlying cause.

More fonts for Whiteboards

We have expanded the selection of fonts that are available for Whiteboards and canvases:

New fonts
New fonts

The list of available fonts now includes:

  • Arial
  • Armata
  • Audiowide
  • Calligraffiti Regular
  • Cinzel
  • Dancing Script
  • Indie Flower
  • Josefin Sans
  • Kaushan Script
  • Lato
  • Lobster
  • Montserrat
  • Nothing you could do
  • Oswald
  • Pacifico
  • Permanent Marker
  • Pinyon Script
  • Raleway
  • Rock Salt
  • Shadows into light
  • Times New Roman
  • Verdana

 

Dropping the “Render Server” feature

One of our oldest features has outlived it’s usefulness…

(No, we didn't shoot this dog. Or any other dog.)
(No, we didn’t actually shoot this dog. Or any other dog.)

We have something we call the “Render Server”: it’s a separate server from the rest of Kerika, and it’s sole purpose has been to create thumbnail images of Whiteboard projects.

This feature was originally built to make it easier for people who created rich, layered Whiteboards — boards where canvases are contained with other canvases, like the amazing Foundation for Common Good Whiteboard project created by Charles Fraser‘s team (in the UK, and worldwide) which looks something like this:

Foundation for Common Good
Foundation for Common Good

This is just a partial view of the top-level of a series of canvases, layered within each other to create a rich, multi-media world.

The Render Server helped people understand that some shapes on a canvas contain other canvases within them: for example, if you hovered your mouse over one of the circles on this canvas, you could see — somewhat dimly — a thumbnail of the canvas that was contained within that page:

Showing layered pages
Showing layered pages

This feature was also used when you added canvases to cards on Task Boards and Scrum Boards: the card details dialog would show a thumbnail of the canvas, like this

Thumbnail image of a canvas attached to a card
Thumbnail image of a canvas attached to a card

This feature was cool, and made for great demos, but it was ultimately not all that useful in a practical sense.

(And that’s true for a lot of cool ideas: things that make for great demos don’t always provide great utility in regular use.)

The thumbnails were too small to be of much use on Whiteboards, and when shown on card details for Task Boards and Scrum Boards they just took up too much space.

So, it’s buh-bye to the Render Server: a cool idea, whose time seems to have passed.

(No, really: we didn’t shoot the dog! We promise!)

 

A shift towards short-lived cookies

In an earlier blog post we noted that Google is making it increasingly hard for people to create and maintain distinct Google IDs, and this is creating more problems for Kerika users, forcing us to rethink our “cookie strategy”. Here’s the background:

Long-lived and short-lived cookies

When you sign in to Kerika, you do so using your Google ID: the Kerika server gets an authorization token from Google and places a cookie on your local computer so that you don’t have to sign in again, if you close and then reopen your browser.

We had been using what’s known as a “long-lived cookie”: one that doesn’t automatically expire when you close your browser. That made Kerika more like a news site than a banking site: when you login to a news site as a registered user, you get a long-lived cookie so that you don’t have to login again, even after you have closed your browser (or even restarted your computer).

Banking sites, on the other hand, use “short-lived cookies”: if you close your browser tab, open a new one and try to access your bank account again, you will be asked to re-login.

Short-lived cookies are generally used for more sensitive websites, like banking, because there is a big tradeoff in terms of user convenience. Kerika had previously opted for long-lived cookies because we wanted to make it really convenient for people to get back to their Kerika boards after having closed their browser.

The problem we face

The problem we are facing now is that it is increasingly more likely that your Kerika login is out of sync with your Google login. There are at least two ways in which this could happen, one of which was always a risk, and the other a new risk resulting in the shift in Google’s approach to user IDs:

  • The old problem: people with multiple Google IDs would frequently switch between them, without logging out of Kerika. For example, someone has two Google IDs: A and B. She may have signed up with Kerika while she was logged in as User A. Since we were using long-lived cookies, a Kerika cookie identifying her as “User A” will stay on her machine until she logs out of Kerika.
    But, in the interim she may have separately logged out of Google as User A and logged in as User B (perhaps to check her Gmail on a different ID). This would result in a situation where she is known to Kerika as User A, and currently logged into Google as User B. In this scenario, she would be unable to open any files attached to her projects because of the mismatch in IDs.
  • The new problem: Google is making it easier for people to be logged in as two different IDs, using the same Chrome browser. (Note: this is true only with the Chrome browser; not true with Safari, Firefox or IE as far as we know.) This considerably increases the odds that a user is currently logged into Kerika as User A, and simultaneously logged into Google as User B.
    Because the user never consciously logged out from Google – just switched IDs while on YouTube or Gmail or somewhere – she may be unaware that she isn’t who she thinks she is…

The short-term solution

We can mitigate this problem by switching over to short-lived cookies. This makes the user experience a little more annoying, in our opinion (because you have to login more frequently to Kerika, or remember to keep your browser alive), but it should help reduce the odds that your Kerika ID is out of sync with your Google ID.

The long-term solution

Allow users to sign up directly at Kerika, without using their Google IDs!

Teams distributed by time, not location

We are often asked to advise our users on workflow: it isn’t a primary business of ours – we prefer to build partnerships with process consultants who can provide great services – but the insights we garner from these brief, often unofficial engagements do heavily influence our product design and roadmap planning.

Recently, we have been helping a large industrial company rethink it how it processes requests that come into its various engineering teams, and as a result reorganize its workflow so that there is optimal flow of work across its various design and engineering teams.

Background:

The company is based in North America, and operates on a 24×7 basis all year around, which isn’t unusual in industries that need continual production in order to fully utilize their very expensive equipment. As a result, their “distributed team challenge” was a little unusual: the teams weren’t distributed by location, but by time.

Every aspect of the companies design and engineering functions – which involved highly specialized teams – needed to be replicated in a day shift and a night shift so that work could be handed off continuously throughout the 24-hour cycle. And, that extended to weekends as well: some folks got a “regular weekend” (i.e. Saturday and Sunday off), while others got “staggered weekends” (e.g. Monday and Tuesday off).

Challenges:

In many respects, these teams had collaboration challenges that match those of a US-India distributed team, e.g. a team based on the US West Coast trying to collaborate with a team based in India, and having to deal with a 12.5-13.5 timezone difference (the variation comes from Daylight Savings Time, which isn’t observed in India.)

This 24×7 challenge was relatively straightforward: we have a lot of experience with helping US-India distributed teams work efficiently – based on our own experience, of course.

A different challenge had to do with streamlining the work of the multiple design and engineering teams involved: work requests were coming in from all directions, some through official channels like project planning meetings, and others through unofficial channels like hallway conversations, and in the absence of a clearly defined process to triage new requests, the various teams were feeling randomized.

All these requests were coming in, unfiltered and without any prior review, into a combined backlog that was being used by multiple teams, each of which would normally work independently, often in parallel with each other, and sometimes sequentially (serially) with each other.

Solution:

The solution we proposed was to create another Kerika board that sat upstream of the main engineering board.

This board was used to capture ideas and triage them, and ensure that only complete, appropriate requests made it to the main board’s backlog. This upstream board also helped divert single-team requests to other boards that were created for handling work items that were not cross-team or cross-functional.

The entire process was captured as a Kerika Whiteboard, as illustrated below:

Workflow for a multi-team industrial company
Workflow for a multi-team industrial company

Let’s take a look at this entire flow, piece by-piece:

At the top, we have requests coming in: formal requests initiated at project planning requests, and informal requests that originated in stray emails, unexpected hallway conversations, etc. All of these are captured as cards on a Planning Board organized with these columns:

New items :: Under Review :: Accepted by Business :: Accepted by Project :: Needs Rework :: Rejected

We recommended that a single person be designated as Business Owner, and tasked with doing the initial Business Triage of new cards:

Initial Business Triage
Initial Business Triage

The scope of Initial Business Triage is fairly limited: the Business Owner was asked to examine each new card, on a daily basis, and determine whether it qualified as Accepted by Business, Needs Rework, or Rejected.

Enough new ideas came into the organization that a daily review was recommended, and, importantly, the Business Owner was asked to move cards from New Items to Under Review so that people visiting the board at any time (of the day or night!) could see that their requests were in fact being worked on.

And, equally importantly, people could see the overall volume of requests coming into the organization, and adjust their expectations accordingly as to how promptly their own requests might be processed.

To further emphasize transparency and build support for the engineering teams, we recommended that the Planning Board include as many stakeholders as possible, added to the board as Visitors.

As noted above, the goal was to determine whether a card could be Accepted by Business or not, and for this the card needed:

  • A sufficiently complete description for the work to be handed off to the engineering teams;
  • To be within the plant’s overall scope and mission (as with most industrial companies, there were several large plants, each with a distinct mission);
  • Have budget clearance.

This arrangement helped us achieve two important goals

  • Encourage the promiscuous sharing of ideas, while simultaneously
  • Ensuring new ideas met a minimum standard of completeness and relevance.

If an idea was within the organization’s scope/mission, but lacked sufficient detail or the appropriate budget approval, it was marked as Needs Rework. And if an idea was clearly outside scope, or had no chance of being funded, it was Rejected.

Another key consideration was to discourage people from setting Due Dates on cards early in the process: delaying the setting of deadlines, until the work reached the teams that would actually commit to delivery, helped preserve flexibility in scheduling and allocating resources.

Once the Business Owner did her initial triage of new work, cards were picked up by the designated Project Manager:

Initial PM Triage
Initial PM Triage

The Project Manager worked off the same Planning Board as the Business Owner; she picked up cards that were Accepted for Business. Her goal was to determine the likely impact of each work item, and, critically, to channel the work to either one of the single-team boards, or to the Joint Production board:

Channeling work to the appropriate boards
Channeling work to the appropriate boards

The Project Manager’s review focused not on business utility (since that was handled earlier by the Business Owner), but rather on identifying whether the work request was likely to affect a single team, or multiple teams.

If the work was likely to affect only a single team, the card was moved to that team’s Kerika board using a simple Cut-Paste operation.

If the work was likely to affect multiple teams, it was moved to the Joint Production Board, which was organized with these columns:

Backlog :: In Progress :: This Week :: Today :: Commission

Tags were used to identify the team involved; since the Joint Production Board typically had hundreds of cards at any point in time, and dozens of team members, this was essential for quick reviews by individual Team Members who wanted to filter out their team’s work items.

  • As team members became available, they looked first to the Today column to see if anything was marked as Ready to Pull.
  • If there was nothing in the Today column that was appropriate for the individual person’s skill sets, the person then looked to the This Week column for items that were Ready to Pull.
  • As an item was taken up by an individual Team Member, she would put her face on the card, to signal to the rest of the team that she had taken ownership of the work.
  • As work got done, the work product (design documents, engineering plans, etc.) were attached to the cards.
  • As questions arose, or handoffs were made between team members or entire teams, Kerika’s integrated chat was used to communicate on the cards themselves. (And this is where the 24×7 operation really started to hum!)

Where appropriate Due Dates were set. We had noted earlier that we discouraged people from setting Due Dates at the time they requested new work, to preserve flexibility for the production teams; at this stage it was now appropriate for the teams to make date commitments.

Since all the work that reached the Joint Production Board involved multiple teams (by definition), the card details were updated to reflect the interim deadlines, e.g. the deadline for the Design Team to hand-off something to the Electrical Engineering team.

Once work was completed on a card, it was moved to the Commission column where the final deployment was handled. After that, the card would be moved to Done, and periodically (once a week) the Done column was swept off to another Project Archive board.

Occasionally, work would be shunted off to Reserve Backlog: this contained ideas and requests that were plausible or desirable in general terms, but had no realistic chance of being implemented in the short-term.

Workflow for a multi-team industrial company
Workflow for a multi-team industrial company

Key Lessons Learned

Some aspects of this workflow design should be of interest to teams in other industries and sectors:

  • The use of a Planning Board to act as a way station for ideas and work requests, so that the main boards of the individual teams, as well as the Joint Production Board were not disrupted.
    • The way station helped ensure that only complete work requests went on to the engineering boards.
    • The way station encouraged people to contribute ideas and improve them before they were sent to engineering.
  • Encouraging people to contribute ideas, by making the Planning Board open to a wide group of people who were given Team Member rights (i.e. the ability to add and modify cards).
  • Separating the roles of Business Owner and Project Manager, so that the business evaluation was distinct from the implementation evaluation.
  • Separation of individual team boards from the joint production board, so that single-team requests could get processed faster than they would have, if everything had gone through a single pipeline, on a single joint production board.
  • The user of a Reserve Backlog, to hold on to ideas that the teams might wish to revisit in the future.

What do you think?

We would love to hear your thoughts on this case study!

Global, distributed, Agile: Kerika & WIKISPEED

Global, distributed, agile: words that describe Kerika, and WIKISPEED.

WIKISPEED is a volunteer based green automotive-prototyping company that’s distributed around the world and coming together on a Kerika board to design and build safe, low-cost, ultra-efficient, road-legal vehicles.

We first visited WIKISPEED in the summer of 2012, as part of our research into the needs of distributed, agile teams.

We found huge walls covered with sticky notes:

WIKISPEED's walls

IMG_0439 IMG_0440

Dedicated volunteers….

Volunteers

And the irrepressible Mr. Joe Justice himself:

Joe Justice

Today, WIKISPEED uses Kerika’s Scrum Boards to organize itself (you can see them at kerika.com/wikispeed):

From physical to virtual

This transformation has helped knit together folks from around the world: the Kerika boards are now used by WIKISPEED volunteers in the United States, Canada, Europe and New Zealand to communicate and collaborate. A great example of how Kerika can help bring together a globally distributed agile team!

Success!

(And, by the way, Kerika was a proud sponsor of the WIKISPEED car that was built for the Future of Flight Aviation Center in Everett, Washington ;-))

Arun Kumar, with the WIKISPEED car at the Future of Flight Aviation Center