Category Archives: Technology

Posts related to technology in general

Agile for large and distributed teams: conversations with Al Shalloway, Mike DeAngelo and the Wikispeed team

Three great conversations about Agile and Scrum in recent days, with Al Shalloway of the Lean Software and Systems Consortium in Seattle; Mike DeAngelo, Deputy CIO of the State of Washington; and Clay Osterman and Joe Justice from Team WIKISPEED in Lynnwood. Common threads in these conversations:

  • Scaling up Scrum to large projects (e.g. the global WIKISPEED team numbers close to 300 people), and
  • Adapting Scrum for distributed teams (where people are located in multiple offices).

Agile purists might well recoil at the prospect of Scrum teams that can’t be fed with a single large pizza (the traditional rule-of-thumb for the optimal team size, still followed at companies like Amazon) or having to deal with people in multiple locations that can’t have face-to-face contact., but these are real-world problems for many organizations, and simply saying “No”, because the idea of very large or distributed teams offends one’s theology about Agile, isn’t a useful stance to take.

Increasingly, large organizations are distributed across cities, timezones, and even continents, and complex systems require large delivery teams. A pragmatic approach is necessary, not a purist one: we need to consider how we can adapt the basic principles of Scrum to meet the real-world needs of large organizations. Here are some lessons learned over the years in how to adapt Scrum for large or distributed teams:

  • Let multiple project teams push/pull items from a single Backlog, so that many small teams can work in parallel on a single system, rather than a single, large team take on the entire Backlog. This requires coordination among the various teams through a “Scrum of Scrums”: each individual team does it’s Daily Standup, and then the Scrum Masters of each team participate in a second meta-Standup where they report to each other on their particular teams’ progress and impediments.
    To succeed, you need project tools that make it very easy to have multiple teams push and pull items from a single Backlog. The project management system must make it easy for any any member of any team to have real-time visibility into the progress of every other team, so that the task of managing dependencies can be pushed down to individual team members rather than concentrated within the Scrum Masters. (Leaving it up to the Scrum Masters alone to manage all the inter-dependencies leaves you with the same single-point-of-failure that you have with traditional Waterfall approaches.)
  • Try stay within the “1 large pizza” size for individual teams. There’s a simple, practical reason why you should avoid having individual teams become much more than 8 in number: the Daily Standup takes too long, and people start to either under-report, or tune out much of the discussion.

    If a team has 20 people for example, and each person simply took 30 seconds to say what they had done, 30 seconds for what they plan to do next, and 30 seconds to describe impediments, that still adds up to a 30-minute long Standup!

    When faced with a Daily Standup that has become something of an ordeal, people tend to under-report, as a coping mechanism, and, frequently, what they under-report (under-discuss?) are the impediments.

    This can be fatal to the team’s overall success: problems and worries are not discussed very well, and eventually accumulate to the point where they become fatally large.

  • Split up the work, not the team. If your people are distributed across multiple locations, it is far better to split up the work rather than the teams: in other words, give each location a different set of deliverables, rather than try to get people working in several locations to work on the same deliverables.
    Too many organizations, particularly when they first built onshore-offshore teams, cling to the myth of “following the sun”: the idea that a team in India, for example, could work on a deliverable during Indian working hours, and then hand that work off at the end of the day to a California-based team that is conveniently 12-hours away.

    This is the myth of continuous work: the notion that the same deliverable can effectively be worked on 24 hours a day, by having two shifts of people work on it in non-overlapping timezones.This simply doesn’t work for most knowledge-intensive professions, like software development or product design.

    A huge effort is needed to hand over work at the end of each workday, and invariably there is a significant impact upon the work-life balance of the people involved: either the India team or the California team, in our example, would have to sacrifice their evenings in order to accommodate regular phone calls with the other team. Eventually (sooner rather than later), people get burned out by having their workdays extend into their evenings on a regular basis, and you are faced with high turnover.
    Splitting up the work means you can have loosely-coupled teams, where there isn’t the same burden of keeping every person aligned on a daily basis. A project tool that makes it easy for everyone to have a real-time view of everyone else’s work is essential, of course, but you no longer have to have Standups that would otherwise easily take up an hour each day.

What do you think? Let us know your best practices!

Another week, another update: this time, it’s mostly styling (and better user management)

We are trying to get back to a faster rhythm of releases. Our goal is to have releases within 3 weeks: we want to complete our development and QA within 2 weeks, and then use the third week for “dogfooding” the software.

(As you might expect, we are fervent users of Kerika! Everything related to our business is done using Kerika project boards, and to make sure we are putting out the best possible product, we use a daily build of the software on a test server. This keeps us firmly on the bleeding edge of our own software development: it means that we get to try out our software in a real-life scenario — one that is absolutely mission-critical for the company! — before we pass it on to our users.)

Our newest version, released today, contains a number of under-the-hood fixes that will help us manage our growing number of users. And, we are happy to report, our users are indeed growing: we are adding new users in March at twice the rate we did in February!

From your perspective, it’s mostly some styling and minor user interface changes that will be visible. We have a better way to expose the Cut, Copy, Paste and Delete functions for cards, having heard from too many users that they couldn’t easily figure out how to delete projects, we have more uniform use of colors, and there is a right-click menu for dealing with project cards as well as task cards.

The more uniform use of colors is a step towards a larger update/refresh of our look-and-feel. We have been hearing from users that our user interface is “too grey”, and we are working on that issue. We are also looking at improved notifications, both onscreen and through emails. Stay tuned!

A comprehensive template for implementing an Electronic Health Records system

With help from Paul Seville, MD, MBI, CSM, (who, by the way is a very impressive guy: experienced physician turned informatist!) Kerika is now offering a comprehensive process template for medical practices that need to implement an Electronic Health Records system: the template deals with all the stages of an EHR implementation, as recommended by the authoritative folks over at HealthIT.gov:

  • Stage 1: Assess Practice Readiness. This comes with 7 cards, representing the key work items needed to complete this stage.
  • Stage 2: Plan your Approach. 9 work items that include document templates for analyzing and mapping your practice’s current and future workflow.
  • Stage 3: Select or Upgrade to a EHR. 8 cards along with templates for evaluating vendors.
  • Stage 4: Conduct Training & Implement EHR. Checklists and templates for test plans for the implementation stage.
  • Stage 5: Achieve Meaningful Use. This is the most critical phase of implementing an EHR, of course, and we have cards for each of the 15 “Core Measures” and each of the 10 “Menu Measures” recommended by the government.
  • Stage 6: Continue Quality Improvement. This includes templates for conducting patient surveys.

This is the master process template for health informatics: over the coming days we will be providing more focused templates for each of the sub-projects involved in deploying an EHR: for example, templates for each of the Meaningful Use measures.

This project template includes a large number of document templates for the individual work items (e.g. a spreadsheet that you can use to evaluate EHR vendors). All document templates are available in Microsoft Office format as well through Google Docs.

These templates are available to everyone, right now: when you start a new project, you will find “Implementing an EHR” among the choices for Task Board projects:

Selecting a process template
Selecting a process template

When you use a Kerika project template, you also get copies of all the document templates that are part of the project template. These are copied into your own Google Drive account, and can be shared with others on your project team.

Please let us know know what other templates you would like to see! (And our thanks to Dr. Seville for help with this particular template.)

Our new version: even better integration with Google Drive, and even better tablet support

Our next release is mostly about improving our Google Drive integration: we are making it a lot easier for you to manage your Google Docs from within Kerika itself, so that your content has a very useful “contextual layer” on top! Here are some of the improvements we be rolling out this weekend:

  • The file organization inside your Google Drive will be a lot more streamlined: a single, top-level folder called “Kerika.com” will have subfolders for each account to which you have access.
  • Better synching between Google Drive and your Kerika projects:
    • If you rename a file that’s attached to a Kerika card, that new name will show up in your Google Drive as well.
    • If you rename a file in Google Drive, that new name will show up in your Kerika cards.
    • If you delete a file that’s attached to a Kerika card, that file will get moved to the Trash in your Google Drive as well.
    • File sharing within your Google Drive will be done at the Kerika project folder level, which means faster performance and a cleaner interface.
    • Duplication of file folders will be eliminated.
  • Content that is attached to cards can be renamed easily: if you rename a file that you attached to a card, this new name will show up in your Google Drive as well, and you will be able to easily rename Web links as well.

We are also improving the Kerika experience on iPads and cellphones: as before, you can access Kerika right from the Safari browser (or Chrome, if you prefer), without having to download any special apps, and we are adding:

  • Better support for “double-tapping”, similar to doing a double click on a desktop.
  • Better support for phones.
  • Improved performance.

General improvements to the user interface will include:

  • A new set of tutorial videos, all under 2 minutes in length, to help you get more out of Kerika.
  • Cut-and-paste of entire projects.
  • Any URLs that are referenced inside cards or on chat messages will appear as clickable links.
  • Content inside chat messages can be easily copied.
  • A cleaner way to customize the workflow for your project.
  • A cleaner layout of icons on cards.
  • Some cool animation effects that make it easier to understand how canvases work, particularly if your projects contain multi-layered canvases (where one canvas contains several others).
  • A new to mark cards as “Needs rework”.

And, a final note: this version has taken quite a bit longer (4+ weeks) that our previous versions, largely because we allowed “feature creep” to happen… We kept adding usability tweaks to the release, particularly with respect to the iPad experience, and that chewed up a whole week. We need to guard more closely against feature creep for our next release.

Coming up: we are adding tagging as a new feature, which will make it easier to create quick filtered views of large projects!

Managing your Account Team

Your Kerika Account Team consists of you (the Account Owner), and all the people you have added as Project Leaders or Team Members, across all your projects. Each person is counted just once, regardless of how many projects that person works on, and Visitors are not counted at all.

When you sign up as a new Kerika user, you get set up with a free Standard Account, which lets you have up to 3 people in your Account Team — and that includes you, as the Account Owner.

As your projects get larger and you add more people to your teams, you will need to upgrade your account to a paid Professional Account, which you can do within the application itself. Here’s how you can manage your account team, and the type of account you have with Kerika: click on your name or photograph, which appears in the top-left corner of the Kerika application.

Accessing your Kerika Account
Accessing your Kerika Account

This will show you a menu of actions:

Getting to your Account details
Getting to your Account details

From this menu, select Manage my Account and you will see your Account screen, right inside the Kerika application. It looks like this:

Your Account status and Account Team
Your Account status and Account Team

If your account is currently over its allowed size, you will see an alert here. (In the example above, the account shown is authorized for 3 users, as a free Standard Account, but is currently hosting 13 users).

Below this alert is a list of everyone who is part of your Account Team. If you want to reduce the size of your Account Team, perhaps to account for changes in your organization, or perhaps simply to reduce your use of the Kerika service, you can remove people easily by selecting them from this list.

Your Account Team
Your Account Team

Hover your mouse over that entry in the list of Account Team members, and you will see a full list of all the projects that person is working on:

All the projects someone is working on
All the projects someone is working on

To remove someone from your Account Team, click on the “x” button at the right end of the listing:

Removing someone from Account Team
Removing someone from Account Team

Before the person is actually removed, you will see a warning message that reminds you which projects will be affected:

Warning before removing someone from Account Team
Warning before removing someone from Account Team

If you are sure, go ahead and click on the Remove user from my Account button on the bottom left of this warning. (We have deliberately put it there, so you don’t click on it by accident.)

Removing someone from your Account will remove that person from every project where they are working, and this is will immediately affect your Account Team size.

 

 

The best lines from Tim Cook’s Q&A at Goldman Sachs Conference

The transcript at the Wall Street Journal is extensive, and makes for great reading. Here are some of our favorite bits:

On whether Apple is too frugal:

My definition of a depression-era mentality wouldn’t be of a company investing a pair of tens over two years. [“tens” refers to $10 billion.]

On Einhorn’s lawsuit and Apple’s Proposal 2:

You’re not gonna see us do campaign mailing, you’re not gonna see a “yes on 2” in my front yard. This is a waste of shareholder money, it’s a distraction, and it’s not a seminal issue for Apple.

On innovation:

If there was a formula, a lot of companies would have bought their ability to innovate…

Consumers want an elegant experience where the technology flows to the background

These skills, this isn’t something you can just go write a check for. This is decades of experience

On specs:

Do you know the speed of an AX processor? You probably don’t. Does it matter? You want a fantastic experience

On iPad market share:

I have no idea what market share is, we’re the only company that really reports the units we sell.

On cannibalization:

I think if a company ever begins to use cannibalization as a primary or even a major factor of what products to go to, it’s the beginning of the end.

On iPad Mini:

I think this is gonna be the mother of all markets.

On the value of Apple Stores:

The tablet was ingrained in their mind as this heavy thing the Hertz guy held. But our store is the place to go and discover and try it out and see what it can do.

On being a good corporate citizen:

I’m very proud that we’re out front, that we have a spine on supply responsibility.

 

 

It seems older browsers simply won’t go away

Kerika uses a ton of Javascript, and by the word “ton”, we mean “well over a hundred thousand lines of Javascript”. It is one of the most sophisticated user interfaces ever developed for the browser, and it delivers a fantastic, real-time, desktop-like experience right inside the browser. And it does so on Internet Explorer, Safari, Chrome and Firefox.

The problem has always been with Internet Explorer: versions before IE9 have very poor support for Javascript and HTML5 in general. In years past Microsoft gave lip-service to the idea of supporting the (then-emerging) HTML5 standards, but their pre-IE9 versions did a very halfhearted job of supporting Web standards. Too many people at Microsoft were still fixated on the idea of maintaining a proprietary lock-in by encouraging their users to stick with the Microsoft-specific extensions that ran only on IE Server and the IE browsers. Things turned around only with IE9, spurred, no doubt, by the surprising inroads that were being made by Firefox and Chrome. Now, happily, the thinking at Microsoft has really come around to supporting Web standards!

Well, Kerika doesn’t run on pre-IE9 versions of Internet Explorer. This was a critical design decision we made when we first started coding in 2010, based on the assumption that IE9 — which was then in beta form but already looking reasonably robust — would be quickly launched and vigorously promoted by Microsoft, and as quickly adopted by the IE user base.

That doesn’t seem to have happened, at least not as far and as widely as we had hoped, and a call this afternoon with a user who was stumped trying to make Kerika work on his office PC, which still runs IE8, prompted us to look at NetApplications data on browser market share and adoption curves. The data are, frankly, dismal.

First of call, let’s look at overall browser market share, as of Dec 2012:

Browser market share on Dec 2012
Browser market share on Dec 2012

Overall, Microsoft is in a position to say they are still the most common browser out there, but not by much: total market share for Internet Explorer, across all versions, is 54.77%. The following graph, however, really puzzles us: it suggests that browser market share hare remained essentially static for most of 2012, which doesn’t quite jive with anecdotal evidence we have been getting from users suggesting that Chrome is making surprising inroads among both Mac and Windows users:

Browser market share in 2012
Browser market share in 2012

Looking at specific versions of Internet Explorer shows some data that matches our intuition and general market understanding:

IE10 Market Share
IE10 Market Share

But there’s other data that are really puzzling: why would IE6’s market share rise in mid-2012? Were a bunch of old laptops suddenly taken out of storage and donated? No new machines could have come into the market with IE6, nor could many machines have downgraded to IE6 (unless everyone has been saving their installation disks for Windows XP and decided to collectively reinstall their desktop operating systems in July…)

Browser market share in 2012
Browser market share in 2012
IE6 Market Share
IE6 Market Share

Perhaps the data aren’t so reliable after all, although NetApplications has long been the most highly cited source for data on browser market share.

We need some of those curves to start bending soon…

 

When prosecutorial misconduct lurches from farce to tragedy

Aaron Swartz didn’t have to be driven to suicide by the horrific prospect of spending decades of life in prison for the “crime” of publishing taxpayer-funded research. There’s a petition at the White House to fire Assistant US Attorney Steve Heymann, who proudly put out this press release on July 9, 2011 to pat himself in the back:

If convicted on these charges, SWARTZ faces up to 35 years in prison, to be followed by three years of supervised release, restitution, forfeiture and a fine of up to $1 million.

That’s 35 years in prison for publishing taxpayer-funded research — yes, that’s right: we are talking about research funded with your tax dollars. And the farce that’s wrapped up inside this tragedy is that JSTOR, which housed the research that Aaron downloaded, has already decided to make all these documents available free to the public.

When someone screws up this badly in the private sector, he is fired, fast, and deservedly so. Why not in the public sector as well?

60 usability improvements (and we are not done yet!)

Kerika got updated today, with around 60 usability improvements based upon feedback from our early adopters. Many of the changes are quite small, but you should notice that now it is even easier to:

  • Add people to projects.
  • See who is part of each project.
  • Chat about cards.
  • Work with templates.
  • Catch up on updates from coworkers.
  • Use Kerika’s unique canvas feature.

There’s also a simpler and easier welcome experience for new users, and improved performance with faster downloads.

And speaking of performance, that’s our next focus: we want to kick that up quite a bit, so it’s even easier to use Kerika with public WiFi networks like coffee shops.

Giving real thanks, this Thanksgiving

This Thanksgiving holiday, we have good cause to be grateful to all the folks who gave us detailed feedback on our new task management software, and helped us identify about 25 different improvements that we plan to make over the next week covering areas such as:

  • Eliminating any confusion that might exist regarding project privacy;
  • Making it easier to edit card titles;
  • Making it easier to chat on individual cards;
  • Improving the emails that are sent when people are added or removed from projects;
  • Improving the overall performance, by at least by 50%;
  • Simplifying the experience for new users;
  • Simplifying the use of canvases and whiteboards;
  • Adding helpful hints throughout the product; and
  • Eliminating references to “Kanban” which some people find confusing (without eliminating any functionality).

We will be updating Kerika next week, and will continue to release new versions every two weeks, and over the next month we plan to market and publicize the software more.