Microsoft Project for Agile?

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.

We released Kerika+Box today!

At long last, and with considerable effort, we finished and released Kerika+Box: a seamless integration of Kerika with the Box cloud storage platform.

Kerika+Box works just like Kerika+Google, the old integration of Kerika with Google Drive: both offer a complete work management system that works seamlessly with your cloud storage platform of choice.

We are really excited about this new release; we have found that there are a ton of advantages to using Box as a cloud storage platform:

  • It’s free for personal use, which means it’s easy to get started.
  • You can sign up with an existing email address: you don’t need to get a new ID.
  • It’s got the best security and enterprise management features of any cloud storage platform out there.
  • The company is very accessible and offers great support.

We have also updated our website, to make it more responsive (i.e. display better on mobile devices), and we have included a number of customer profiles to give you an idea of the very broad range of people who are using Kerika.

Check it out!

Signing up for Kerika
Signing up for Kerika


LinkedIn endorsements: revisiting the long tail

Eleven months ago, somewhat bemused by the surprising number and variety of LinkedIn endorsements I was getting, I wrote a blog post graphing the “long tail” of these endorsements:

Arun Kumar's LinkedIn endorsements
LinkedIn endorsements (August 2013)

At that time, I was astonished to find that I had a total of 251 endorsements across 35 categories of skills!

I was fairly certain I had maxed out, and was sure that the entire practice of LinkedIn endorsements would die out altogether since I felt the currency had become already become devalued: LinkedIn was aggressively suggesting endorsements to all users, pretty much every time they logged into the site, and this was creating an inflationary bubble.

So, 11 months later, what does the picture look like?

LinkedIn endorsements (July 2014)
LinkedIn endorsements (July 2014)

What had previously seemed an unrealistic set of numbers (251 endorsements across 35 categories), is now 411 endorsements across 50 categories.

The tail is even longer, as you can see: 10 categories where I have 1 endorsement only in each category, and 15 categories where I have just 2 endorsements each.

Last year, the top 5 categories represented 55% of all my endorsements; this year, the top 5 categories represent 50% of all my endorsements — more proof that the tail is flattening and lengthening.

And in my previous post, I had argued that LinkedIn was hair-splitting: too many categories sounded like they were the same.

This year, the effect seems even more pronounced; here are categories that I would recommend be collapsed together to provide a more coherent picture of a person’s skills:

  • Entrepreneurship, Board of Directors, Board of Directors Experience (really?), Startups together as “Entrepreneurship”, because all of that relates to the startup world.
  • Cloud Computing, Scalability, SaaS together as “Cloud” because all that relates to, well, cloud.
  • Online Marketing, Go-to-market Strategy, Competitive Analysis, SEO, Product Management: all this is part of “Marketing”.
  • Program Management, Project Management, Software Project Management, IT Management, PMO, SDLC together as “Program Management”.
  • Strategy, Strategic Planning, Management Consulting, Consulting together as Strategy.
  • Enterprise Software, Integration, Outsourcing together under something I would prefer to call “Big Company IT”.
  • Management, Executive Management, Team Leadership, Cross-functional Team Leadership, Leadership, Communication Skills all are part of “Leadership”.
  • Business Process, Process Improvement and Business Process Automation could be just “Business Processes”.
  • Analytics and Business Intelligence could be together.
  • Acquisitions and Mergers & Acquisitions should certainly be together!

If I normalized this data, it would look like this:

Normalized LinkedIn Endorsements
Normalized LinkedIn Endorsements

Now my top 5 categories account for 66% of all my endorsements, which would give you a much sense of my skills!

Maybe I should award myself an extra endorsement for “Analytics”?


Why we are integrating with Box, Part 9: Final QA

(The ninth 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 been doing internal testing (“eating our own dogfood”) of Kerika+Box for the past three weeks, and the results have been much better than we expected!

We have found very few bugs so far, which is great — it’s feels like a huge vindication of our decision to invest several Sprints in improving our internal QA processes, clearing the backlog of old bugs, and generally improving our software development processes with code reviews across the board, for even the smallest changes.

In other words, we didn’t move fast and break things: we moved slowly and broke nothing. Which makes sense when you have paying customers who rely upon your product to run their businesses…

Since Kerika makes it really easy to have multiple backlogs in a single account, we put all the OAuth and infrastructure work in a separate backlog, allowing a part of the team to concentrate on that work somewhat independently of other, more routine work like bug fixes and minor usability updates.

And, as before, put every feature in a separate git branch, making it easy to merge code as individual features get done.

Here’s what our Box QA board looks like, right now:

Box QA board
Box QA board

The user interface for Kerika+Box is essentially the same as for Kerika+Google, with a few quirks:

Box requires more frequent logins: Google provided us with relatively long-lived refresh tokens, so a user could close a Kerika browser tab and reopen it a day later and log right back in.

With Box, you are going to see a login screen much more often, along with a screen asking you to re-authorize Kerika as a third-party app that can access your Box account.

This is kind of irritating, but apparently unavoidable: from what we have found on Stack Overflow, Bug views this as a feature rather than a bug.

The other, really big difference is that files are edited offline rather than in the browser itself: when you click on the Edit button, you will end up downloading a local copy of the file, using Microsoft Office for example, and then when you do a Save of that file, your latest changes are uploaded automatically to the cloud.

Here’s what you see when you open a file attached to a card on a Kerika board, when you use Kerika+Box:

Example of opening a file within Box
Example of opening a file within Box

This works great most of the time, except when two people are making changes simultaneously: in that situation, Google’s in-browser editing seems a lot more convenient.

On the other hand, downloading local copies of files means that you get the full power of Microsoft Office, and we know that’s very important for some of our users, e.g. consultants dealing with complicated RFPs or government users dealing with official documents.

Performance also seems a little less than Google Drive, although we would stress that this is highly variable: while Google Drive files generally open within 1-3 seconds in a new browser tab, they can take much longer if Google’s servers are slow.

Overall, we are very pleased with Kerika+Box: we are planning to do all of our new development with this new platform, to continue eating our delicious dogfood ;-)

The full series:

A case study in transforming a Government Agency

Dan Genz from the Washington State Auditor’s Office gave a presentation at the 2014 IPMA Forum describing how the state agency is adopting Lean principles, while serving hundreds of state, county and local municipalities with a distributed team of auditors and analysts spread out across the state:

A case study in building an Agile PMO

Will Treinen, founder and CEO of Treinen Associates gave a presentation at the 2014 IPMA Forum describing his experiences in building an “Agile PMO” to handle the extraordinary growth of his consulting business (600% in the past year!).

Will relied upon Kerika to create the perfect collaboration environment for his distributed teams of project managers, business analysts and business development staff:

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

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

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

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.