All posts by user

Using status indicators on Task Boards and Scrum Boards: “Ready to Pull”

Agile & Scrum, Kanban & Lean, ,

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

Kerika makes it really easy to flag cards on a board, if you need to alert your team members; here’s an example:

Examples of status flags on cards
Examples of status flags on cards

There are several statuses that you can report on cards (in addition to “Normal”, the default setting), and we will try to provide some advice in these blog posts on how best to use them.

First up: “Ready to Pull”

Setting status
Setting status

Ready to Pull is great if your team works in a “pull” environment, rather than a “push” environment. Here’s the easiest way to differentiate between the two:

  • In a “push” environment, work gets pushed onto people — quite literally. For example, Project Leaders (or even Team Members) decide that a particular card should be handled by a particular person, and they assign that card to that person: in other words, they push that work onto people.
  • In a “pull” environment, people only assign work to themselves: as they get freed up from whatever they are working on, they look at the board and pick up whatever task is waiting to be pulled (i.e. done) — in other words, they pick up a card that is marked as “Ready to Pull”.

There are advantages and disadvantages to both models, and it’s really a question of how your team prefers to work.

Particularly in organizations that are still transitioning from traditional (Waterfall-style) project management, the push model can be the easiest way to adopt a tool like Kerika: it helps retain the traditional role of a Project Leader as someone who is responsible for the assignment of work among the team.

This is definitely the easiest pathway for organizations that are still in the process of transitioning to a Lean or Agile model — a process that can take months in most cases.

There are, however, some disadvantages to the push model:

  • It can delay the organization’s cultural transformation to Lean/Agile: people feel less empowered, and can be more passive if they wait for work to get pushed to them by others.
  • A less empowered team is often slower to take the initiative.
  • Someone who has had work pushed onto them may feel less ownership of the outcome.
  • It provides a misleading picture of what’s actually getting done: this, in our experience, is the biggest shortcoming of the pull model!

When work gets pushed onto people, you can find that individuals have 10 or more items currently assigned to them. There’s no way they could be working on all 10 items at the same time, so one of the biggest advantages of Kerika — providing an accurate, real-time view of what’s getting done, and by whom — is somewhat negated.

The pull model is truer to the spirit of Kanban: it allows people to work at their own (true) pace, and empowers them to pick up new work as they get freed up — or blocked.

The Kerika team itself has transitioned from push to pull: with push we never had a true sense of what’s getting done; with pull, we do!

There are disadvantages to the pull model:

  • It requires more training and cultural change up-front: even for a team that generally feels empowered, it is a big shift in thinking and process to move from push to pull.
  • It can require a more complex workflow: for example, here’s a partial (!) view of the workflow that we adopted as part of transitioning to Pull, to make it work within our constraints:
Understanding the Pull Model
Understanding the Pull Model

Pull is best implemented in conjunction with Work-In-Progress (WIP) Limits, which is a feature that we will be adding shortly to Kerika.

So, how should you use “Ready to Pull” as a status indicator?

If you are working in a push model, there’s nothing to do: you don’t need this feature.

If you are working in a pull model, whenever a user is done with a piece of work, she should mark it as “Ready to Pull”, and then take her name off the card.This will clearly signal the rest of the team that the work item is ready to be taken on by someone else.

All posts in this series:

Partial searches just got easier in Kerika

Technology, Usability,

Thanks to feedback from users at Washington State’s Department of Fish and Wildlife (hat-tip to Ryan Koval & team!) we improved our Search feature to make it easier to do wild-card searches.

Wildcard searches let you easily find anything, anywhere in Kerika, by just typing in a little bit of text — as little as a single character — and get back results that match on that text.

(Of course, typing in just a single character will return too many results to be useful… :-) )

In general, there are two ways to do partial searches:

  • By implementing wildcards in the query that the Kerika user interface delivers to the Solr search engine that we have implemented.
  • By using a NGram Filter or an EdgeNGram filter.

Using filters could result in a huge increase in disk space utilization, and a significant drop in performance, so we opted for the wildcard approach instead.

To implement the wildcard query, we manipulate two variables in Solr: PARTIAL_MATCH_BOOST and EXACT_MATCH_BOOST.

  •  If you search with just one keyword, we show you the exact matches first, and then partial matches: we use PARTIAL_MATCH_BOOST and don’t use EXACT_MATCH_BOOST.
  • If you search with multiple keywords, we show you the results that match across all keywords first, using EXACT_MATCH_BOOST, and don’t use PARTIAL_MATCH_BOOST.

There are more ways of fine-tuning search, of course, but for now we seem to have made enough of an improvement to keep our users happy!

Internet Explorer remains the odd man out on tablets

Technology

We have been putting in a ton of effort to improve the Kerika user experience on tablets: while Kerika runs OK in the Safari and Chrome browsers on iPads, the experience is somewhat uneven across other tablets, particularly Android and Windows tablets and “convertibles”.

It’s a little frustrating to find so many oddities about Internet Explorer 11 (the latest, greatest version from Microsoft) when it comes to Windows 8.1 tablets and convertibles.

Looking at our internal Scrum Board for our tablet work, we are struck by the many ways in which the touch and swipe gestures in Internet Explorer are different from the Webkit-based browsers (Safari and Chrome):

IE11 problems

I met my old lover
On the street last night
She seemed so glad to see me
I just smiled
And we talked about some old times
And we drank ourselves some beers
Still crazy after all these years
Oh, still crazy after all these years

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.

We released Kerika+Box today!

Kerika

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

Ephemera

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”?

 

A case study in building an Agile PMO

Agile & Scrum, Team Collaboration, , ,

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?

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.