Monthly Archives: August 2014

How we work with 2-week Sprints

Agile & Scrum, Kerika, Team Collaboration, Technology, Usability, , , ,

Here at Kerika, we often get asked how we do Scrum as a distributed team.

Here’s the model we have evolved, which works for us mainly because we are the very essence of a distributed Agile team: we have people working together on the same product from locations that are 10,000 miles apart!

And this means that we are the most enthusiastic consumers of our products: we use Kerika to manage every part of our business and we only build what we would ourselves love to use.

Here’s the basic outline of our Scrum model:

Kerika's model for 2-week Sprints
Kerika’s model for 2-week Sprints

Each Sprint is 2 weeks long: that that works well for us; other folks might find that 3 weeks or 4 weeks i better. Pick what works for you.

Each Sprint begins with Sprint Planning, where the Scrum Team gets together with the Product Owner to decide which cards will be pull from our main Product Backlog into the Sprint Backlog.

Each Sprint is organized as a separate Scrum Board: this makes it really easy for us to concentrate upon needs to get delivered in that particular Sprint, without getting distracted by what was done in the past or what remains to be done.

And Kerika makes it really easy to pull cards (literally!) from the Backlog onto a Scrum Board, and then hide the Backlog from view so it doesn’t distract the Team while the Sprint is underway.

Half-way the Sprint, at the end of the first week, we do a gut-check: does the Sprint look like it is going reasonably well? We don’t ask if it is going perfectly: almost no Sprint does; what we are looking for is any indication that the Sprint is going to severely under-deliver in terms of the Team’s commitments to the Product Owner.

We could do these gut-checks every day during our Daily Standups, but in the first part of a Sprint cycle these can often give us false positives: it’s easy to tell early on if a Sprint is going to be disastrous, but it’s hard to tell for sure that it is actually going to end well. But about midway through the Sprint we start to have a more reliable sense for how things may turn out.

In keeping with the Scrum model, our goal is to complete a potentially shippable set of features and bug fixes with each Sprint, although this doesn’t necessarily mean that we will always ship what gets built after each Sprint. (More on that later.)

For each feature or bug, however large or small, we make sure that we have design and testing baked into the process:

  • The document is often just a few paragraphs long, because we always take cards representing large features (or other big work items) and break them up into smaller cards, so that no card is likely to take more than a day’s work. Kerika makes it really easy to link cards together, so it’s easy to trace work across multiple cards.
  • For bugs, the attached document describes the expected behavior, the actual behavior, and the root cause analysis.  Very frequently, screenshots showing the bugs are attached to the cards.
  • For new features, several documents may be attached, all quite small: there may be a high-level analysis document and a separate low-level design document.
  • For all features and bugs, we do test planning at the time we take on the work: for back-end (server) work we rely primarily on JUnit for writing automated tests; for front-end (UI) work we have found that automated testing is not very cost-effective, and instead rely more on manual testing. The key is to be as “test-driven” in our development as possible.

There are several benefits from doing formal planning, which some folks seem to view as being antithetical to an Agile model:

  • It helps find holes in the original requirements or UI design: good technical analysis finds all the edge cases that are overlooked when a new feature is being conceptualized.
  • It helps ensure that requirements are properly interpreted by the Team: the back-and-forth of analysis and reviewing the requirement helps ensure that the Product Owner and the Team are in synch on what needs to get done, which is especially important for new features, of course, but can also be important to understand the severity and priority of bugs.
  • It deliberately slows down the development pace to the “true” pace, by ensuring that time and effort for testing, especially the development of automated tests, is properly accounted for. Without this, it’s easy for a team to quickly hack new features, which is great at first but leads to unmaintainable and unstable code very soon.

At the end of the 2-week cycle, the Team prepares to end the Sprint…

We like to talk about Sprints as “buses”: a bus comes by on a regular schedule, and if you are ready and waiting at the bus stop, you can get on the bus.

But if you are not ready when the bus comes along, you are going to have to wait for the next bus, which thankfully does come by on a regular 2-week schedule.

This metaphor helps the Team understand that Sprints are time-boxed, not feature-boxed: in other words, at the end of every 2 weeks a Sprint will end, regardless of whether a feature is complete or not.  If the feature is complete, it catches the bus; otherwise it will have to wait for the next bus.

And here’s where the Kerika team differs from many other Scrum teams, particularly those that don’t consume their own products:

  • At the end of each Sprint, we do the normal Sprint Retrospective and Show & Tell for the Product Owner.
  • But, we also then take the output of the Sprint and deploy it to our test environment.
  • Our test environment is the one we actually use on a daily basis: we don’t use the production environment as often, preferring to risk all of our work by taking the latest/greatest version of the software on the test environment.

This forces us to use our newest software for real: for actual business use, which is a much higher bar to pass than any ordinary testing or QA, because actual business use places a higher premium on usability than regular QA can achieve.

(And, in fact, there have been instances where we have built features that passed testing, but were rejected by the team as unusable and never released.)

Kerika's model for 2-week Sprints
Click on this image to see the actual Kerika Whiteboard

This is illustrated above: the version of Kerika that’s built in Sprint 1 is used by the team to work on Sprint 2.

This is where the rubber meets the road: the Kerika Team has to build Sprint 2, while using what was built in the previous Sprint. If it isn’t good enough, it gets rejected.

At the end of Sprint 2, we will release the output of Sprint 1 to production. By this time it will have been used in a real sense by the Kerika Team for at least 2 weeks, post regular QA, and we will have a high confidence that the new features and bug fixes are solid and truly usable.

We could summarize our model by saying that our production releases effectively lag our Sprint output by one Sprint, which gives us the change to “eat our own dogfood” before we offer it to anyone else.

You can see the actual Whiteboard project for this process flow here.

 

 

Improving Kerika on iPads

Technology, Usability

Remember: you don’t need an app to use Kerika on iPads: you can simply use Safari or Chrome — just go to to kerika.com, and login just like you would on a desktop.

Kerika on iPad
Kerika on iPad

What’s great about building a pure HTML5 software like Kerika is that many of these improvements are also going to improve the user experience on desktops and laptops.

Here’s the laundry list:

Big changes:

  • You can add photos from your iPad to cards: you can take existing images from your photo library, or simply take a picture on the go and add it to a card.
  • We worked out a bunch of quirks related to Internet Explorer, which, unfortunately, remains sui generis when it comes to browsers.
  • In general, Kerika is now a lot smarter about dealing with laptops that have both mouse and touch interfaces.
  • We have improved performance and responsiveness, across the board.

Usability improvements:

  • We have redesigned our “Max Canvas” view so that it provides the most useful display, when you need the most space available to view a large board. In particular, you can now access Search even when you are in the Max Canvas view.
  • If a column is partially hidden, e.g. at the left- or right-edge of a Task Board or Scrum Board, clicking on the “+New Card” button at the bottom of the column will make the entire column slide into view, so you can clearly see what you are typing.
  • The Yes/No confirmation buttons on the Workflow dialog have been resized, so they are easier to press (unambiguously) with a finger on a tablet. Which, of course, improves usability for laptop users as well, in keeping with Fitt’s Law.
  • On a related note, we rescaled the calendar control used for setting due dates on cards, to make it easier to use with a finger (without making a mistake).
  • It’s easier to scroll through a long list of attachments on a card without accidentally dragging them with your finger.
  • The user interface makes it clearer how you can slide your view of a board, by swiping.
  • The panning motion, when you swipe left/right, is smoother.
  • Frequently, card history can take more than a few seconds to load if the tablet is slow or the wireless connection is slow: if this happens, the user sees an indication that the system is fetching the history.
  • Particularly on tablets, it’s easier to scroll down through long card details.
  • We have added a subtle animation on drop-down dialogs (e.g. for Workflow, Chat, Tags, etc.) to help people understand how these work.

Bugs fixed:

  • On iPad, it’s easier to edit text: the cursor shows correctly when you press and hold your finger, bringing up the “magnifying glass” that lets you move the cursor to a specific character.
  • The “hint text” shown on text boxes, e.g. “Enter the card’s description…” won’t get included when you copy/paste from the tablet’s clipboard.
  • A one-second delay in showing the list of available colors, for setting the color of a card, has been eliminated. (Yes, we care about one second delays…)
  • A one-second delay in showing the Tab Overflow button — the button that appears to the right-edge of all your open project tabs when there are too many tabs to display — has been fixed.
  • It was difficult to select a name from the list of auto-completed suggestions presented to you when you want to add someone to a project’s team. That’s been fixed.
  • A bug related to selecting the colors at the bottom of the list of available colors has been fixed.
  • If you tried to change the curve of a line on a Whiteboard or canvas, a bug that caused shadows to show up has been fixed.
  • A bug related to how the text box toolbar was displaying (the buttons for this were showing up in an untidy way if there wasn’t enough space) has been fixed.
  • On canvases, the thumbnail images of some files were showing up stretched when viewed in Safari, although they were fine when viewed using the Chrome browser; this has been fixed.
  • Also on canvases, it’s easier to swipe across the canvas without moving stuff accidentally.
  • When you are using an iPad in portrait mode (i.e. holding it vertically), card details show up properly centered.

What remains:

A ton of work on Android, unfortunately… Android tablets vary so much in terms of processor capability that even the same browser, e.g. Chrome, can behave very differently on different Android tablets & even tablets from the same manufacturer.

Some Android tablets will work better, as a result of all this work we have done, but we can’t yet guarantee that all of them will work perfectly.

There’s a similar, albeit smaller, challenge with Windows Surface machines

Windows laptops and desktops generally work fine, and so do “convertibles” (i.e. dual-screen machines where you can use the mouse or touch the screen), but Windows Surface is still causing some issues because of weirdness within Internet Explorer.

 

 

 

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 :-(

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 :-(

Using status indicators on Task Boards and Scrum Boards: Done!

Agile & Scrum, Kanban & Lean, , ,

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

In our last post we talked about how to use the “Is blocked” flag; today, let’s take a look at “Done”.

Setting status
Setting status

“Done” is where you want to get to: it’s a special column that’s always to the right edge of every Task Board and Scrum Board.

(You can always chose to hide the Done column, of course, just like you can hide every other column on the board.)

Marking a card as “Done” is simply a quick way of moving it to the Done column, which can be handy when you have a very elaborate workflow — and we have seen folks whose boards have up to 20 columns!

In the near future when we add Work-In-Progress (WIP) Limits for Task Boards and Scrum Boards, the Done column, of course, will not be subject to WIP.

We are also planning on adding more metrics to help Project Leaders and Account Owners understand how well their projects are going, and these will naturally make use of the Done count.

All posts in this series:

Using status indicators on Task Boards and Scrum Boards: Done!

Agile & Scrum, Kanban & Lean, , ,

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

In our last post we talked about how to use the “Is blocked” flag; today, let’s take a look at “Done”.

Setting status
Setting status

“Done” is where you want to get to: it’s a special column that’s always to the right edge of every Task Board and Scrum Board.

(You can always chose to hide the Done column, of course, just like you can hide every other column on the board.)

Marking a card as “Done” is simply a quick way of moving it to the Done column, which can be handy when you have a very elaborate workflow — and we have seen folks whose boards have up to 20 columns!

In the near future when we add Work-In-Progress (WIP) Limits for Task Boards and Scrum Boards, the Done column, of course, will not be subject to WIP.

We are also planning on adding more metrics to help Project Leaders and Account Owners understand how well their projects are going, and these will naturally make use of the Done count.

All posts in this series:

Using status indicators on Task Boards and Scrum Boards: Is Blocked

Agile & Scrum, Kanban & Lean, ,

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

In our last post we talked about how to use the “On Hold” flag; today, let’s take a look at “Is Blocked”

Setting status
Setting status

“Is blocked” sounds similar to “On hold”, but it should be used in a different context: Blocked is a red flag to the team — it indicates that you are unable to proceed with a task, and you need help.

The essential difference between Blocked and On Hold is that:

  • You, or perhaps your boss, chose to put something On Hold.
  • You were forced to mark something as Blocked.

For teams working in a Kanban or Scrum model, the highest priority for a Project Leader should be to unblock cards.

Unblocking cards (and hence, people) is the most useful thing that a Project Leader can do to help move work smoothly.

This is why “Is blocked” is shown in red on a card, so that you can literally raise a red flag!

All posts in this series:

Using status indicators on Task Boards and Scrum Boards: On Hold

Agile & Scrum, Kanban & Lean, ,

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

In our last post we talked about how to use the “Needs rework” flag; today, let’s take a look at “On hold”.

Setting status
Setting status

In an ideal world, you would simply pick up a task, get it done, and move on to the next one.

In the real world, you must often put aside something you are working on, in order to work on some more urgent and probably unexpected.

This is when you can mark cards as being “On hold”: it’s an easy way to let the rest of the team know that you are not currently working on something, even though it’s assigned to you.

From the Project Leader’s perspective, having too many items “On hold” is a warning sign: it’s often an early indicator that people on the team are starting to thrash between tasks.

If you see that anyone on your team has several items “On hold”, it might be a good idea to check in on them and see what’s happening: why they are picking up so many items and leaving them unfinished.

All posts in this series:

Using Status Indicators on Task Boards and Scrum Boards: “Needs rework”

Agile & Scrum, Kanban & Lean, ,

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

In our last post we talked about how to use the “Needs review” flag; today, let’s take a look at “Needs rework”.

Setting status
Setting status

In an ideal world, cards would only move from left to right: starting off on the left-most column, e.g. the Backlog in a Scrum Board, and moving in stages to the Done column.

In the real world, however, work can sometimes need rework, and that’s what the “Needs rework” status indicator can be used for.

The amount of rework that’s needed will vary widely, depending upon the project and the team:

If someone new has just joined a well-established team, that person may need some time to understand exactly what’s expected of them at each stage of the project’s workflow: they may, for example, be too quick to move a card from “Planning” to “In Development”, without realizing what’s expected of a card that’s fit to exit the Planning stage.

This new person may find that her work gets pushed back to the left, marked as “Needs rework”.

It’s imperative that whoever pushes back work as “Needs rework” also provides some precise description of what rework is needed.

This is most often done using chat, but sometimes a marked up document, screenshot or other materials may be more useful, particularly if the task is complex.

But, simply marking a card as “Needs rework”, without providing a good explanation, is never a good idea: it will generate ill-will within the team, discourage the new person, and simply result in more work for everyone.

Some times of work will always require a lot of rework: e.g. design.

Mockups of new products or features, or copy for new advertising, will go through a lot of rework before it is considered ready to move along a workflow.

This is quite normal, which brings up another critical point: good Project Leaders will ensure that there is no stigma attached to cards being marked as “Needs rework”.

If people are made to feel, however subtly, that their work is of poor quality because many of their cards are frequently marked as “Needs rework”, this will have a very bad effect on individual and team morale.

It’s really incumbent on the Project Leaders to ensure that people understand that “Needs rework” is simply a status indicator, not a judgment of someone’s abilities!

All posts in this series:

Using Status Indicators on Task Boards and Scrum Boards: “Needs review”

Agile & Scrum, Kanban & Lean, ,

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

In our last post we talked about how to use the “Ready to pull” flag; today, let’s take a look at “Needs review”.

Setting status
Setting status

This status is easy to understand: “Needs review” means just that — a card needs to be reviewed by someone before it can move further along on its way to Done.

There are many common scenarios where this is useful:

  • Perhaps a supervisor needs to review your work before it can progress further.
  • Perhaps an expert, e.g. a security expert, needs to review your work before it goes further.
  • Perhaps you are simply seeking comment from others on a draft idea…

Marking a card as “Ready for Review” can be done alongside a workflow that involves more formal review steps.

Here, for example, is a software project that has “Code Review” as a stage in the workflow:

Review as part of a workflow
Review as part of a workflow

This image is from one of our projects, and as you can see (if you squint hard enough) we have a “Code Review” column on the board that’s part of our Sprint workflow.

We use the “Ready for review” status flag at all stages of our workflow: for example, after a developer has done some technical planning for a new feature, she may mark the card as “Ready for review” and leave it in the Planning column.

A more senior developer may then pick up that card, provide her review comments — as chat, notes in the card’s details, or even an attachment (if the comments are extensive) — and attach them to the card before taking off the “Ready for review” flag.

The “Ready for review” flag can be used in both push and pull models of project management.

All posts in this series: