Tag Archives: Workflow

About project and process workflows.

Kerika’s internal product development workflow

It will come as no surprise to our users that the Kerika team uses the software for every aspect of the company’s internal operations, including, of course, our product development.

(There really isn’t anything better on the market for planning and executing product roadmaps — we know, because we have checked and made sure we are better than everybody :-))

We are sometimes asked about our own internal workflow: how we plan releases and manage our Sprints, and in particular how we have gone without using regular old email for over 4 years now!

Well, here’s a glimpse at our internal workflow:

Kerika internal workflow
Kerika internal workflow

We work in two-week long Sprints; we have found two weeks to be the ideal Sprint length since it provides enough time to produce something — at least some usable part of a new feature — while not being so long that we forget we are supposed to be working as a Scrum team.

Planning

Whenever we plan a new Sprint, we are always also looking forward as well: hence the columns titled “Sprint +1” (i.e. the Sprint that will come after the current Sprint), “Sprint +2” (the Sprint that will come after the next Sprint), etc.

This gives a view into the next several weeks of our product roadmap which makes sure we don’t approach any single work item with tunnel vision.

Now you might notice that “Sprint +3” in the list above is way larger than “Sprint +1” or “Sprint +2”: that doesn’t mean that we expect a sudden spurt in productivity (i.e. increase in team velocity) in 4 weeks time.  It just means that as we go further out in our planning there is more uncertainty about priorities and so the Sprints that are well into the future are not well defined — and that’s perfectly OK.

Quality Assurance

Within each Sprint we have a fairly conventional flow: Planning, Development and QA.  The QA step actually consists of three separate stages:

  • Code Review: we try to make sure we review all the code we are writing in any Sprint, unless it is a really trivial change we are making (e.g. changing the label on a button).
  • Deploy to Staging: we have a separate set of servers where we test our new releases.  This also happens to be where we have all our real projects running: we believe very much in the idea that “developers should eat their own dogfood”, so we run out entire business on the latest build that went past Code Review.

    This can be a little scary or frustrating at times: if there was a bad release to our staging environment, it can bring every project and board to a screeching halt.  But, from our perspective, that’s the whole point: make it everyone’s business to ensure that we produce high-quality code, and make it everyone’s priority to fix any problems that come up.

    This model of living on the bleeding edge of our product gives us a really good incentive to write good quality code!

  • The final QA step is Show & Tell, where the team formally presents the new features or bug fixes to the Product Owner.  With each new feature we will have identified a set of test cases, as part of the Planning phase, and these are used to formally check the new feature in a meeting attended by everyone on the team.

    Very occasionally something will get rejected at the Show & Tell stage, in which case the card gets moved back to Planning or Development and flagged as “Needs Rework”.  It’s more common for work to get rejected at the Code Review phase, not because it is buggy, but because it might not meet our internal coding standards.

Deployment

Once a feature or bug fix has passed Show & Tell, it is ready for Deployment to Production.

We have a continuous integration process for handling code changes — pulling them from our internal git code repository — but we don’t do continuous deployment. Instead we prefer to deploy on the last day of each 2-week Sprint.  We usually time this for Friday morning, Indian Standard Time, so that our developers in India can take one final look at the system working in production.

Documentation

We have an unusually strong emphasis within the team on creating documentation at the same time as we write code.  Many small companies skip documentation because they think it will slow them down.

In our own (sometimes bitter) experience, skipping documentation is false savings: if there are problems to be fixed later, or even if a feature simply has to be extended in the future, it’s very hard for even the original developer to recall the logic that she used to write the code in a particular way.

What’s important to note, however, is that we don’t have very big documents: most documents are less than a page long, because they refer to very specific work items.  But we have thousands of these small documents, since every feature we have ever produced, and every bug we have fixed, has been documented.

And thanks to Kerika’s very cool integration with Google Docs (we use Kerika+Google), managing these thousands of documents is very easy: just open the relevant card for a specific feature or bug fix and you will find all the relevant documents as well:

Documents attached to cards
Documents attached to cards

For new features we always have a short Planning Document that identifies any existing modules that will be affected and provides an outline of the new code that will be written. Here’s an example:

Example of a Feature Planning document
Example of a Feature Planning document

There may be other documents created, depending upon the complexity of the new feature, but even the smallest new feature will have at least one planning-related document that’s written before the code is written.

Bug Fixes

For bug fixes, we have a Repro, Cause & Fix document that methodically analyzes the cause of a bug:

Root Cause Analysis
Root Cause Analysis

The most important section of this document is the Introduced Since piece, where we trace the origin of the bug back to its source, to understand what new feature or bug fix we were originally working on that resulted in this new bug appearing.

This methodical root cause analysis, which we do for even the most minor bugs, helps us identify patterns in our code writing that we need to improve.  Sometimes it can even point to bugs that we haven’t discovered yet: the root cause analysis may identify an assumption that we have applied in other places, all of which need to be looked at to make sure there aren’t other variations of the same bug that haven’t been identified yet.

After the bug has been fixed, the Repro, Cause & Fix document is updated to reference the git branches where the code fix can be found.  This completes the circle of careful analysis, careful execution, and methodical review that we strive to adopt (and improve continuously).

The End of Email

We stopped using regular email towards the end of 2013. There was never any formal decision to renounce email; instead there was a formal decision to “eat our own dogfood” in a very serious way.

And as we started to build our entire company using our own product, we found that using Kerika is so much better than using email that there really wasn’t any need for email any more.

So people simply started drifting away from email. There was no explicit decision or formal movement to do so, people just realized, on their own, that email is an exceptionally poor way of managing work within a distributed team.

Conclusion

Considering the size of our team — and entire company, for that matter — you may be surprised by the degree of formalism we have adopted, and the heavy emphasis on analysis and documentation.

We spend at least as much time on analysis and documentation as we do on “pure coding”, and if we add in the Code Reviews and other elements of formal QA, the actual coding time is a relatively small portion of our total expenditure.

But trying to skimp on analysis and documentation really doesn’t pay off, in our experience: if you are building a company and product for the long-run, as we very assuredly are, you need to build it right, not just fast.

New feature: we made it easier to use Card URLs

Every card (and every canvas) on a Task Board or Scrum Board in Kerika has a unique URL, but most of the time you might not notice the URL shown in your browser’s address bar is changing as you open one card after another.

(And if you are using Safari on Macs, you definitely won’t notice this since Safari hides most of the URL anyway.)

These URLs can be helpful in many ways: Kerika recognizes them as pointing to other cards or canvases, and makes these links an easy way to connect up different work items.

Here’s an example of a card URL that’s referenced in a chat message:

Referencing Card URL in Chat
Referencing Card URL in Chat

Any URLs that are included as part of the chat or details of a card, that reference other cards, canvases or boards within Kerika, are automatically recognized and presented as useful links as you can see from the first chat message shown in the above example.

To make it easier to get these card URLs (and to help you notice that they are important in the first place), we have made it possible to grab any card’s URL with a single click:

Card URL button
Card URL button

Clicking on the new Card URL button that appears on the top-right of each card’s detail view makes it possible to see, and copy, the card’s URL with a simple click:

Getting Card URL
Getting Card URL

We have made it easier to grab the URL of an entire board as well, from your Home Page:

Board URL
Board URL

Try this way of creating links between related work items, across all your Kerika boards.

Helping people parachute into projects faster

In many of our customers, we find there are specialists who get pulled into many different projects (boards) at the same time, to do very specific tasks.

An example would be an security specialist who is called in to do a vulnerability assessment on every development effort that’s underway within an IT organization. Or, corporate counsel who are asked to review final drafts of every contract, after everything else about the negotiation has completed.

In all situations it’s important to help new team members come up to speed as quickly as possible, but for situations where people are parachuting in to handle specialist tasks, the motivations are a little different: the specialists often don’t care about every detail of the board — which means they don’t care for most of the cards that are already on the Task Board or Scrum Board.

Instead, they want to quickly see what’s been assigned to them, get these work items done, and (hopefully) get out quickly.

So, how can Kerika help people who parachute into projects in mid-stream? By drawing their attention to what’s expected of them.

Here’s how it works:

When you invite someone to join a board’s team, their status is shown as Pending invitation in the Board Team dialog:

Pending Invitation
Pending Invitation

Kerika lets you pre-assign cards while you are waiting for the new team member to join: in the example above, Dennis could be assigned cards while the team is waiting for him to act upon the invitation.

When Dennis does accept the invitation, the Kerika welcome dialog works to guide him to a fast start in his new project:

Welcome message for invited users
Welcome message for invited users

The welcome dialog starts by giving the new team member a quick overview of the project’s state: how long it’s been going on, how many cards are on the board — and, critically, how many cards are already assigned to the newly arrived team member.

Clicking on the See My Cards button in the welcome dialog provides a fast way for the new user to see what’s expected of him/her in this new project:

Highlighted cards
Highlighted cards

This feature will be especially useful for specialists who are called in to handle specific tasks on many simultaneous projects: they won’t care about all the cards on each board, just what’s assigned to them.

Get in quick, get your work done fast, and then get out again.

Starting new boards in Kerika: an alternative for experienced users

For experienced users who don’t need as much help in starting new boards, we are providing a faster mechanism that skips some steps that are currently shown to new users.

You can access this faster mechanism by clicking on the Skip Suggestions link in the current Start New Board dialog:

Skipping Suggestions
Skipping Suggestions

Once you click on Skip Suggestions, Kerika will recognize you as an experienced user who prefers a path like this:

Starting a New Board
Starting a New Board

Once you pick the kind of new board you want — Task Board, Scrum Board, or Whiteboard — you can immediately name your new board:

Starting a new Task Board
Starting a new Task Board

Kerika will assume your new board will use the same template that you last used, but if you like you can change to a different template by clicking on the Change Settings link:

Selecting a Template
Selecting a Template

This should save our experienced users a few clicks when they want to start a new board…

We made it easier to sync your Kerika Due Dates with your Calendar

We made some user interface tweaks to make sure people are aware of a really great feature in Kerika that’s existed for a while, but was buried in a Preferences screen that not everyone paid attention to: you can have your Kerika Due Dates automatically show up on your Google, Microsoft or Apple Calendar.

Well, that’s buried no more: we have added a Calendar Synch button in a more prominent place on the top-right of the Kerika app:

Calendar button
Calendar button

Clicking on this button will let you choose the type of calendar you want to synch with:

Calendar choices
Calendar choices

(Hint: you can have your Kerika Due Dates synch with more than one calendar, if you like.)

Pick your favorite calendar type, and you will see detailed instructions on how to set up syncing of your Kerika Due Dates. Here’s an example of syncing with Apple Calendars:

Calendar instructions
Calendar instructions

The URL is personal, and should be kept confidential. (That’s why we aren’t showing it in the illustration above.)

The URL is long and random so it will be impossible for others to guess, but it’s not a good idea to share it with others unless you really want them to know all your Kerika Due Dates, e.g. if you have an assistant or delegate that helps manage your daily schedule.

 

We aren’t going to support Highlights in the Planning Views (at least for now)

Most of the time, users are in what we call the Workflow View of their Task Boards and Scrum Boards:

Workflow View
Workflow View

It’s in the Workflow View that our new Highlights feature proves really useful:

Highlights in Workflow View
Highlights in Workflow View

In the Planning Views, however, Highlights are not as important since we expect the Planning Views to be used primarily for quick scheduling:

Planning View
Planning View

(The Planning Views, by the way, are what we refer to as the views that Kerika provides over the next few days, next few weeks and next few months.)

Is this a good assumption on our part? If not, let us know and we will add Highlights to the Planning Views as well.

Preferences

New options for the 6AM Task Summary Email from Kerika

Welcome to 2017! We have a big bunch of goodies lined up for release in the coming weeks and months, and we are going to start off with some nice improvements to the 6AM Task Summary email that you can (optionally) get from Kerika:

You now have two options: you can get all your overdue and due items sorted by date, or by board. Or both.

To turn this on, go to https://kerika.com/preferences, and check these boxes:

Preferences
Preferences

We have also improved the “group items by date”: instead of showing what’s due today and tomorrow, this email now includes What’s Due This Week and What’s Due Next Week.

“This Week” is adjusted automatically as the week progresses to keep track of what’s left for the current week, which always ends on Sunday.

Enjoy.

Repro, Cause & Fix: Using Kerika to Fix Bugs

Interested in using Kerika for software development? Here’s a practical example, taken from one of our own boards, that highlights best practices for tracking, investigating and fixing bugs.

First, a look at our Workflow

Every software development team will want to set up its own workflow, of course, reflecting its internal dynamics and available resources.  Here’s the Scrum Board workflow we use in our team:

Scrum Workflow
Scrum Workflow

Our Scrum Boards are organized with these columns:

The Backlog contains all the ideas, large and small, that we have on our product road map: in Scrum terminology, it’s our Product Backlog.

The Sprint Backlog is the set of cards that we pulled from the Backlog at the start of this Sprint: right now, only 4 items are left as we are close to the end of our 2-week Sprint Cycle.

Within each Sprint, cards are picked up developers and first moved into the Planning column, where detailed analysis of the work to be done is completed.

Depending upon the complexity of a particular work item, a developer may request a design review before moving the card further into the Development column.

Developers do their own unit testing as part of the Development phase, but then the work item moves further down to the the QA column which frequently includes formal code review.  (More on that below…)

After a bug has been fixed, had its code reviewed and passed unit testing, it gets Deployed to the Test environment.

We usually wait until the 2-week Sprint is over before asking the entire team to present the entire Sprint’s output to the Product Owner for the Show & Tell; this avoids distracting the team midway through the Sprint.

Once the output of a Sprint has passed the Show & Tell, it can then be Deployed to Production.

The Done column shows all the work that got done in this Sprint.  That’s where all cards are supposed to go, but sometimes a work item is abandoned and moved to the Trash.

(Side note: we sometimes use WIP Limits to make sure that people are not over-committed to work, but this is not a consistent practice within our team.)

Logging the bug

Now, let’s take a look at an example of an actual bug card that was worked on by our team:

Example of a bug tracked as a Kerika card
Example of a bug tracked as a Kerika card

(This particular bug doesn’t have a lot in the details, because it is related to another task that is currently underway, and Kerika makes it easy to link cards, canvases or boards.)

Some bugs go into the Product Backlog, if they are not considered especially urgent, but others go straight into the Sprint Backlog if they represent serious production problems that might affect user’s access or the reliability of their data.

Adding bugs to the Product Backlog lets us process bugs along with other development, e.g. of new features, in the same way: everything can be prioritized by the Product Owner and handled through a consistent workflow.

Documenting the bug

Our bug reports typically come with two attachments; at least one of these should always be included so that the developer has a clear starting point for her work:

  • A screenshot showing the user experience (if the bug can be observed directly by the user.)
  • An excerpt from the error log, if the server reported any errors around the time the bug was observed.
Original bug report documents
Original bug report documents

Kerika makes it easy to attach any kind of content to any card, canvas or board: for bug fixing, particularly in the analysis phase, this is very useful if the user needs to include URLs, material from Sourceforge or similar sites, links to Github, etc.

Repro, Cause & Fix

Before any bug is fixed, our developers always add a standard document we call Repro, Cause and Fix as an attachment to the card:

Repro, Cause and Fix
Repro, Cause and Fix

This document is added no matter how trivial the bug.

Why? Because, on average our team goes through about 30-40 cards a week, and has been doing so for years now.  If we don’t document our analysis now, we will never recall our logic in the future.

Repro, Cause and Fix

Repro, Cause and Fix

Our team adopts a consistent layout of the Repro, Cause & Fix document, which we adhere to even for trivial bugs:

The Repro Steps are the steps needed to trigger the bug: usually they consist of a specific sequence of actions taken by a user that cause the bug to appear, but they can also consist of a sequence of events in the background, like specific server activity or memory/CPU utilization conditions, or overall network traffic, that trigger the bug.

The Expected Behavior helps clarify the developer’s understanding of the how the software should behave in this situation.  It’s not uncommon for a developer who is new to the team to misunderstand how a particular feature is expected to behave, which could lead to more bugs being introduced.  Clarifying Expected Behavior in this document provides an easy way for the Product Owner and the Team Lead to confirm that the developer is not going to go down the wrong track.

Introduced Since: our developers try to pinpoint the specific point in the software’s life where the bug was introduced.  This helps the developers reflect upon how errors are created in the first place: the blind spots lie in their analytical patterns that need to be strengthened.

(In this particular example, the developer has been able to point back to some of her own work on an earlier feature implementation that caused this bug to appear.)

Root Cause is not the same as the Repro Steps.  While a specific sequence of actions or events may reliably display the effects of a particular bug,  they only provide the starting point for the analysis; the Root Cause itself is discovered only when the developer examines the code in detail and determines exactly what is breaking.

Affected Feature: all of our code goes through code review, which we view as one of the most effective QA processes we could adopt, but it can be very challenging when you are processing 30 cards each week, each affecting a different part of the software.

Identifying the Affected Feature helps with the code review process, since the reviewer can consider the bug fix in the larger context of the feature that’s being modified.  Without this, it is doubtful that we could review so many changes each week.

Affected User: in most cases, this is “everyone” we offer the same Kerika  to all our users, whether they are on free trials or have paid for professional subscriptions.

Identifying Affected Users is useful, nonetheless, when dealing with bugs that are browser-specific, or service-specific: for example, determining that a particular bug affects only Kerika+Google users, or only Internet Explorer users.

The Fix: OK, this might seem obvious, but this section really refers to identifying the specific modules in the software that will be changed as a result of the bug fix being applied.

Like many others, we use Git for managing our source code — along with Maven for builds — since our server environment is all Java-based.

Fix
The Fix

The Fix section usually includes references to Git checkins: this helps with future bug fixes, by making it easy to traceback sources of new bugs — part of the Introduced Since section described above.

We use separate Git branches for each feature that we develop so that we can decide precisely what gets released to production, and what is held back for future work.

This helps with the Show & Tell phase of our workflow, when the developers demonstrate the output of the Sprint to the Product Owner, who has the option to accept or reject specific features (i.e. cards on the Scrum Board).

Code Review

All of our code goes through code review, no matter how trivial the change:

Code review
Code review

We really believe that code reviews are one of the most effective QA practices we could adopt: having a second pair of eyes look over code can very considerably reduce the chances of new bugs being introduced.

So…

Kerika is great for distributed software teams: our own team is spread out between Seattle and India (roughly 10,000 miles apart!), and all of our work is done using Kerika for task management, content management and team collaboration.

Of course, an added benefit of “eating our own dogfood” is that we are highly motivated to make sure Kerika is the best tool there is for distributed teams 🙂