Category Archives: Technology

Posts related to technology in general

Microsoft Project for Agile?

Kerika, Technology,

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

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

Here’s my response:

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

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

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

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

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

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

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

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

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

a) Is considered immutable from the very start.

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

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

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

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

Agile & Scrum, Technology

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

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

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

My answer:

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

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

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

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

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

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

Consider killing some of your bright ideas

Technology, Usability

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

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

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

And to improve the fix.

And to make the fix even better.

(You can probably see where this is going…)

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

Here’s another approach you can try:

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

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

Paying down technical debt when working with a Scrum team

Agile & Scrum, Kerika, Technology,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi folks!

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

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

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

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

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

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

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

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

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

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

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

Why we are integrating with Box; Part 8: Our experience with Box (so far)

Kerika, Technology,

(The eighth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

We have finished our development work on the Kerika+Box integration, and have started internal testing this week!

Our philosophy all along has been to “eat our own dogfood”: every new feature that we have ever built has been used internally, for real, by the Kerika team for its own product development and team collaboration. Since we are ourselves a distributed team, spread out between Seattle and India, it makes perfect sense for us to use Kerika to build Kerika ;-)

Here’s what our Box integration testing board looks like:

Box integration testing board
Box integration testing board

We haven’t run into many problems so far: we did find one small bug in the Java Library for the Box Collaboration API, and we have been extremely impressed with the responsiveness of the Box team.

  • We first logged the bug at Github, where we had assumed (incorrectly, as it turns out) Box would want their bugs reported.
  • Having logged the bug, we pinged Indy Sen at Box, by Twitter and by email.
  • Indy responded within 15 minutes, on both Twitter and email.
  • Indy got us in touch with the API team at Box, and asked us to log the bug on Stack Overflow, where Box does its platform support.
  • We did that later in the evening, at 11:04PM.
  • Within 4 minutes a support engineer confirmed that the bug existed.
  • Later in the evening we asked a follow-up question, to confirm that our workaround was sensible.
  • The next day, before noon, their support engineer confirmed that our workaround was fine.
  • A couple of hours later, Peter Rexer told us they had fixed the bug and merged the code onto Github.

Now, admittedly, the bug was very trivial — a single misplaced character — but the responsiveness of Box as an organization just blew us away!

Contrast this with the experience we have had in the past with Google Drive, when problems would mysteriously appear and then disappear just as mysteriously, either the same day or several weeks later…

The full series:

Why we are integrating with Box; Part 7: Disentangling from Google

Kerika, Technology,

(The seventh in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

Having decided to add a second cloud platform, we had to go about the cumbersome, risky process of disentangling Kerika from its close embrace of the Google stack.

This has taken us several months, if we are honest about counting the entire effort and duration.

The first part of this was to create a more layered architecture: wherever there was a direct interface to a Google service, we had to create an intermediate shim that allow us to substitute the Google service with another.

And to be frank, when we first started work on Kerika in 2010, we hadn’t seriously considered the possibility that we would use any other cloud service so our architecture had become, over the years, more Google-focused than we had realized.

Disentangling from Google Contacts was the easiest step, and in fact we had already taken that break some time ago in response to users being fearful about Kerika accessing their Google Contacts.

In terms of login, however, things got much more complicated: we had originally integrated with Google using OAuth 1.0, and then later upgraded to OAuth 2.0 as OAuth 1.0 started to get deprecated.

In theory this meant that we could easily integrate with any other OAuth provider, e.g. Box, Facebook, Yahoo, etc.

But as we developed our long-term strategy and talked to prospective customers, it became clear that sooner or later Kerika would have to provide direct signup/sign-in, in addition to OAuth: a significant contingent of folks wanted to be able to sign up directly at Kerika.com rather than use existing credentials from Google, Box, etc.

(We are not quite sure why this is really advantageous for anyone, but the sentiment is real nonetheless.)

So, we decided to implement our own OAuth server, which would act as a gateway to OAuth servers from Google or Box.

This had to be implemented such that the entire sign-up and sign-in process remains unchanged: someone coming to Kerika.com would get redirected automatically to the correct authentication service, which could then redirect the user’s browser back to the Kerika application server.

And, obviously, the entire process had to be smooth, fast and completely transparent to the end-user: how we implemented multiple OAuth sign-ins wasn’t the user’s concern! This had to work really well for both free users of Google, e.g. folks with just a regular Gmail account, and premium users who had signed up for Google Apps for Business or any of its variants (for Government, Education, and Nonprofits).

Fortunately, we already gained experience in dealing with the complexities of browser redirects in enterprise environments, where any sloppiness in terms of using HTTPS, for example, can trip up security alarms in large organizations.

And, we had learned the hard way to look for various edge cases, like restricted domains — if someone from within a restricted domain tries to add someone from outside that domain, we need to trap that condition so that the user experience remains excellent, rather than landing anyone on some scary error page from Google!

The other major complexity was to normalize the service we provide, so that the user experience is equivalent for both Google and Box users.

An example of a “normalized user experience”: an existing Kerika, who uses Google Drive, decides to invite someone to join a project. At that time, we need to check whether the invitee is already registered as a Kerika user or not. If the invitee is already a Kerika user, we need to see whether that user is also using Google Drive.

If it turns out that the invitee has been using Box, we need to make sure the invitee is correctly prompted to switch from using a Google-based Kerika account to a Box-based account, so that she has all the proper access to the new project’s files. And this switch between accounts needs to be a single-click, to keep the Kerika user experience excellent!

Other examples: exceptions and error conditions as reported by Google and Box are very different, reflecting the peculiarities of each service. We need to make sure we capture all these and try to keep the end-user experience as smooth as possible. Fortunately, we had developed a great deal of experience managing exceptions generated by Google Apps, so we could bring all this to bear on our Box implementation.

To get all this right, we had to carefully plan a series of milestone releases that were done in parallel with our regular development: although the work was going to take several months to finish, we needed to keep supporting our existing users with critical updates, bug fixes and limited new product enhancements.

Fortunately Kerika lets you have multiple Scrum Backlogs in the same account, and that’s what we did: we created a separate, smaller Product Backlog consisting of just the OAuth work, and let that development run in parallel while we continued to draw down on our Main Product Backlog.

The OAuth work finally got done in four Sprints, each of which was organized as a separate Scrum Board.

As we came to our regular release cycles, we would pick up items that were complete, from either the OAuth Backlog or the Main Backlog, and merge these to create a new release package.

To get this right, we used git to the fullest, putting each feature into a separate branch so that we could retain the maximum flexibility in terms of what made it into a particular release.

Without this use of multiple git branches, our release cadence would have been tough to maintain.

The full series:

 

Why we are integrating with Box; Part 6: The Box Option

Kerika, Technology, ,

(The sixth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

And this brings us to Box…

We first heard of Box through cloudPWR, a Kerika partner and long-time Box reseller: Shadrack White, Dennis Brooke, and Cullen Hower suggested to us (a year ago!) that we consider integrating with Box.

Shad and Dennis were both enthusiastic proponents of Box: they had done several implementations of Box, including a very interesting use-case for Washington State’s Liquor Control Board which found itself in the business of regulating medical marijuana this year.

And Dennis in particular has been a great proponent of Kerika: he had introduced it to some of his clients.

As we looked at Dropbox and OneDrive as possible alternatives to Google Drive, Box came up repeatedly in the conversations we were having with enterprises.

It was clear that Box was treated very seriously by some folks that we considered very smart and knowledgeable — a senior director at Amazon, for example, told us (off the record) that he considered Box to be the most enterprise-ready cloud storage platform — and so we decided to take a closer look at the Box platform.

We attended Boxworks in San Francisco last summer, and were immediately struck by the differences in tone and substance between Boxworks and DBX.

While Dropbox is a consumer-oriented company with a newly developed interest in the enterprise, Box is a very enterprise-focused company (with little or no interest in consumers).

We took a close look at the Box API, and were very pleased with what we found: Box’s API was very close to what we were getting from Google Drive, which meant that a Kerika+Box integration could offer a really good user experience:

  • If you add a file to a card or canvas on a Kerika project board, it will automatically get shared with everyone who is part of the project team.
  • People’s access to project files will be automatically controlled (and updated in real-time) based upon their roles: Team Members will get read+write access; Visitors will get read-only access.
  • There will be no need for users to manually adjust or manage permissions on any files: Kerika will provide a great contextual layer on top of the cloud storage platform.

Box has another great advantage: it doesn’t have its own proprietary format for storing Word, Excel, etc.  This is a big issue for many enterprises who would like to use Kerika, but don’t want to move away from Microsoft Office format.

If we can the great Kerika user experience, with an enterprise-class cloud service, and the convenience of Microsoft Office, we think we will have a winner on our hands!

So, from a technology perspective a Kerika+Box integration makes a lot of sense. But what about from a market perspective?

When we polled some of current and prospective customers, however, the reaction was somewhat mixed:

  • Folks who were knowledgeable about Box were very supportive. (Good!)
  • Folks who were already using Box were very enthusiastic. (Excellent!)
  • Unfortunately, too many people still haven’t heard about Box… (Not so good…)

Box’s biggest challenge at the moment is name-recognition: far too many folks we talked to confuse Box with Dropbox.

The name confusion vis-a-vis Dropbox is a pretty big issue that we are betting that Box can ameliorate on its own, and Box’s pending IPO should certainly help with gaining greater name recognition and a more distinctive personality in the marketplace.

We are also hoping to build good partnerships with Box resellers, like our friends at cloudPWR, who have long-standing relationships with enterprises that would be great candidates for Kerika’s work management tools.

The full series: