Things I wish I could change in JIRA

I've now setup JIRA to be used in 3 different companies and have I ever learned a lot.  In general, I really like it, but I can see how others can share different opinions.  I do enjoy how Atlasssian has been making some great improvements lately, especially around the "Project Overviews" and Git integrations.  They generally do a great job of walking a really fine line between being completely customizable (and utterly confusing, umm, I'm looking at you IBM Rational Team Concert) and being overly simplistic (Asana? Trello?).  With that said, there are a complaints that I find myself using ugly work arounds for or unfortunately just having to live with:

1. Email Notifications!  JIRA sure is good at sending out emails (or NOT).  Want to make one tiny little change to a non-critical field on an issue?  Sure, but that means the 6 other team members following that issue will all get an email.  Make a typo in that first update and want to fix it 10 seconds later?  That's okay, JIRA will send YET ANOTHER EMAIL.  Why not try something like this:

• Allow each user to tailor their own email preferences, instead of it being globally set
• Change the content in some email template to better allow users to setup their own inbox filters so they can see the emails they need to see and allow themselves to systematically exclude themselves from emails they don't.  Github does a good job here - I'm added in the "to" field if I'm tagged in a comment, but other emails I get (such as a new Pull Request that I'm not a reviewer) I'm BCC'd
• Just as users can decide to send an email or IM, let them decide whether or not the particular change they are making should or should not send an email.  Oddly, Atlasssian does this quite well in Confluence, just not JIRA
• Bundle up changes made within a few seconds of each other into just one email

2.  Backlog management.  I've tried a million strategies but everything always ends up with ugly work arounds that nobody else understands or can reasonably be expected to maintain.  There must be a better way to manage a product backlog.  The "Plan View" of sprint boards comes close, but what if you want to use a Kanban Board instead?  My current approach is to bastardize the use of "Sprints" in order to be able to find/plan/communicate what work is in progress, up next, or at the top of the backlog.  This is confusing, especially because in doing "planning" I inevitably end up sending a bunch of system generated emails out to users as I make changes, then reassess and update them a 2nd time.  

3. Searching for Children.  In the On-Demand version which doesn't allow plugins, it's impossible to find child items of an Epic based on particular attributes of that Epic (such as Status or Label).  I always find myself wanting to write queries that include searches like this, especially for Epics that cross multiple projects (such as a feature being added to both an Android and iOS app).

Letting Unimportant Tasks Go: Declaring Job Bankruptcy

I've had an interesting couple of years; today I just left my 4th job in 18 months after working at the same company for the first seven years of my career.  Most of this was unplanned; one was a failed startup, and two were related to an unexpected move from Boston to San Francisco.  Leaving each job always comes with a certain amount of sadness when leaving behind co-workers you enjoyed working with and not being able to see your product vision to its conclusion.  However, each departure has also brought this wonderful feeling of being able to let things go that I never seemed to find time to do.  You know what I'm talking about; I'm sure you've been putting off replying to that pesky email that's sat in your inbox for months just like I did.  This is work that I know is not important, yet I'm never quite able to let it go until I finally have no choice. The relief one feels by letting go should not be underestimated.  In fact, it's a shame that one cannot enjoy this relief without having to leave a job.  I think that twice a year taking an honest look at everything on my plate and assessing the items that truly can be forgotten will allow me to recharge and focus on important items.  In effect, I'm going to declare bankruptcy and get a fresh start.  Getting the mental weight of these items today makes me feel like a million bucks right now; I am super excited to start my new job next week with a clean slate.

Why create a Minimum Viable Product (MVP)?

The concept of creating a Minimum Viable Product (aka MVP) before investing in a full featured product has been frequently written about in the past few years.  What is a MVP you ask?  Everybody seems to have to have their own definition or analogy, but one of the best I've seen lately that helps explain this concept to anybody (even someone not experienced in technology or building products) was created by Anders Ramsay here.  He writes:

The Hudson Bay Company, which sold provisions and gear to fur-trappers in northern Canada, encouraged their weather-beaten customers to conduct a “Hudson Bay Start.”  This meant that, after they’d finished picking up their gear and provisions from the northern Canada store, they’d make a couple hours trek into the woods, set up camp, and then just stay there for a few days.  Now, why would they do that?  Hey, they ain’t gonna be doin’ no fur-trappin’ that close to town.  No, what they were doing was conducting an MVP.

The gear and provisions they had brought with them represented their best prediction of what they’d need over a period of several weeks in the Northern Territories. Simply camping out in the woods for a few days quickly revealed any major flaws in this prediction.  The cost of making this discovery at that point was low, just a couple hours trek into town. Making the same discovery out in the middle of nowhere might be costly indeed.

So which part of this is the MVP?  The process of selecting gear at the supply shop?  The camping out in the woods to see if they had the right gear?  The discoveries they made by doing this?

The answer is…all of the above.

Making decisions on the best way to create an MVP is difficult.  But thinking about it in terms of what am I testing (what gear do I need to worry about), how do I test it (deciding to hike only a few hours out of town), and what have I learned (did I have all the gear I needed) is a great analogy to keep in mind that can make framing discussions a little easier.

Is it better to specialize or generalize?

I've been doing a lot of soul searching lately about where I see myself in the next five years.  In almost all aspects of my life (work, school, recreation) I seem to come back to the realization that I'm really good at many things, but not truly great at any one thing.  Taking sports as an example, I'm better than average at tennis, baseball, soccer, running, skiing, biking, etc., but I'm far from being truly exceptional in any of those.  Or in my career, I have experience in a number of specialized areas such as web development and UX design, but my best skill is probably connecting and leading those with the specialized skills to deliver successful projects.  I'm now at a cross road where I'm trying to figure out if I want to pick a skill and specialize in it, or if I want to continue to generalize. Nora Dunn, a writer at Wisebread.com created a great pros/cons list, especially the cons of each such as:

• You have less job security if your area of specialty becomes obsolete.
• If you are too specialized, the company can’t use you for other tasks or jobs, thus decreasing your overall flexibility as an employee.
• Less focused job searches are more difficult to endure.
• Employers might not know how best to place you in their organization if your skills are too spread out. They may not view you as reliable or tenacious enough with any one job or skill set to be worth hiring.

I think great companies realize the need for both.  Without specialists, a company can never separate itself from the competition with truly amazing or unique products/services.  If a company could only exist with one or another, there is no doubt that a company of specialists would become more successful.  But, with too few generalists, a company risks a few things.  First, their vision and focus might become too narrow if everyone is an expert in specific types of trees, but nobody knows how to navigate the forest.  Second, the role of a successful generalist is in many ways that of a "Connector" (as outlined in The Tipping Point by Malcolm Gladwell).  They understand enough about the problem at hand, the skills of the specialists in the company, and they understand possible solutions for the problem enough to be able to connect the right people to bring about the best solution. The toughest problem with being a generalist is trying to measure your impact and convince others of the value you bring to the table.  I know that I would be a tremendous asset to many teams.  It warms my heart to hear former developers I led say things like "When you were there was some fun while developing apps.... Day by day that fun deteriorated... ".  My struggle remains convincing someone that hasn't worked beside me before have confidence that I would be the best decision they could make.