Making a Distinction Between Functional Skill Set and Institutional Knowledge in Employee Development

Earlier in the week I did a poll on topics and the number 1 pick by an overwhelming margin (beyond Sad Ass Salad) was "Business Domain vs Functional Domain in Performance Evaluations."  

Project Success does not equate to Individual Success in Performance Goals

Successfully support the <milestone> for the <project name>

Many managers use this boilerplate performance goal for just about any employee.  It's lazy. It reflects nothing with regards to the expectations of the employee, nor does it reflect at all, in what way would one grow in their capabilities.

Why is it not great to tie project success to performance goals.

Simply stating success of a project without identifying how they should be contributing to the project does not set them for success in being able to support the NEXT project on a DIFFERENT team in a more COMPLEX situation.  This not only provides no guidance to the employee on what they should be improving upon, but also may not give you, as the manager, the right capabilities in succeeding should any adversity arise.

Most importantly, many software projects fail due to circumstances that have absolutely nothing to do with the execution of the project.

Why is project success commonly tied to performance goals

• If a project succeeds, the company would make more money, therefore, there's more money in the pool to pay for raises, right?
• A manager's thinking: if a project succeeds, then I succeed, and that means the individuals of the team succeeds right?

What should performance goals include instead?

Activity and contribution to a project should be an EXAMPLE of how you want them to be performing.

Focusing on Software Developers: 

• Three Basics
• Ability to tackle complex challenges.
• Ability to interact with their colleagues in the form of clean code, communication in PRs, and overall communication with the team via chats, email, IRL
• Ability to interact with stakeholders in the form of requirements feedback for clarification and further getting feedback on software behavior. 
• The thing that I care about the most 
• How accountable are they in production and are they able to observe the behavior of their code out in the wild?

If you really want to talk about it in the context of a project:

• How did they contribute to projects last year, and is there any difference in contribution that htey should be doing in future projects?  Spell it out.
• Are these projects more or less complex that last year's projects? How does completing these projects demonstrate their skill set? Explain how this project is a more significant challenge that will test capabilities that haven't been tested before.

Bottom Line:  Goals should not be effectively "yeah do what you did last year but more". You need to give them explicit skills to level up and a clear example of how you plan to observe it. for some managers, that is solely based on the success of a project, and that's a shitty manager.

Soapbox Moment

In developing and operating software, it all boils down to how much trust do you have in the employee. When shit hits the fan, will you call on them? When a brand new paradigm needs to be investigated, will you ask them to spike it? When another member of the team is not around, will they be able to temporarily fill in?  These should all be straight forward yes/no questions and for the situations your team finds themselves in, you should have a pretty clear list of which members of your team are your primary, secondary, "bench" type people for a given situation.  

For each of these moments, based on an employees skills, potential, and professional interests, their goals should be balancing enhancing their skill set so that they can contribute more for your team that suits both their interests, capabilities, and team needs.

Who said management is easy!?

Support you should expect from HR and your Org in prepping to give a Performance Eval

So previously we discussed the importance of being well prepared for your performance evaluation. However, every single different company is different both from an HR perspective and an Organizational perspective. However, they should all be able to provide you some foundational resources in 

• being able to clearly explain why they are getting the performance scores they're getting
• understanding how your eval may impact their salary next year
• understanding how your eval may impact their odds of a promotion next year

What HR Should Provide

HR should be able to provide you basic overviews of the current state of your direct report as well as some high level information on the process for 

Your direct report's job title (and tier if there is one) as well as their salary and the standard salary band for that title.

In many organizations, raise calculations take these 3 things into account along with your performance evaluation. If there is a standard raise calculation, you'll have a decent understanding of what their raise may be.

Your direct report's previous performance eval, if available

It's valuable to review past performance evals, not just to know where they've excelled or struggled in the past, but also to refresh your memory on past goals you've set for them and where their skill set is today versus the previous year. Especially when you observe noticeable improvement (and they're at the same job tier), that should impact your performance score today.

Each Performance Category

In general, performance categories are pretty broad from the HR level. This is where your own org and your seniors should be able to provide more granular guidance.

From your org (and your seniors)

Rather than "doesn't respond well to feedback", your org can give you more explicit guidance like "do you find yourself repeating yourself over and over in their PRs." In absence of any formal documentation, your org and your own manager should provide you with additional context in how your direct report treats their work and their teammates.  

How each Performance Category applies to your direct report's job function

This can provide you examples where to look or what to ask about from peers regarding their work. 

• Aptitude => Are they entrusted with more complex challenges than others? => do they ever get assigned an 8 point story to oversee
• Communication => Do you encounter surprises from them? => system behavior that a product owner did not anticipate and it's already in production?
• Versatility / Team Player => do they shy away from duties that may not be their primary? => are they an asshat when they're on-call?

For each performance category, a discussion of situational example or a behavioral example. Sometimes it's easy to hone in on a specific situation where they may have gone the extra mile or have fallen short, but it's important to make the distinction between what may have happened at a particular instance vs an established behavioral pattern that they have exhibited (and did they improve on it when given feedback about it).

Guidance on for gathering feedback if you're not a hands-on manager (because that's how the org structure is)

If you do not directly interact your direct report (I mean... that sucks) your organization should provide you with the appropriate tooling to gather feedback from those who are better equipped than you are. Discussion with tech leads and 360 Reviews are decent subjective methods in understanding one's performance. Quantitative tools may be a method to open up a conversation with a tech lead, but generally not a great way to gauge whether one is an asset or burden to their team.

My HR nor my Org has this

lol, buddy. sounds like you get to establish this yourself and set the precedence, should you choose to accept it.  Nobody will thank you.

Solidifying Trust when giving Performance Evaluations

The performance evaluation is the pivotal point of the power dynamic between a manager and a direct report.  

In most cases, this is when a manager is making a final decision to move someone to a Performance  Improvement Plan or make a recommendation for a promotion. In many cases, direct reports are using this to gauge whether they want to move to another job within the company or apply for a job elsewhere.

The biggest takeaway for this post is to understand why it is extremely important to be blunt in your feedback at this important confluence of expectations, impressions, and receipts.

A quick look at motivation

Because this is my first people management post we're going to do a quick primer on motivation and the basic structure to a Performance Evaluation.

There can be 3 categories in an employee's motivation: 

• Compensation
• Authority / Respect
• The work, itself (interesting problem to solve, they like the outcomes the business is driving)

We're mainly going to focus on the top two, as those are the pieces that a lot of people generally care about, especially earlier on in their careers. In the performance eval, you need to be able to answer 

• Am I going to make more money next year?
• Will I have more authority next year?
• How can I make MORE money the following year? 
• How can I have MORE authority next year? 

Footnote: for many people at certain parts of their career, they're extremely happy where they are financially and in the work they get to do. Being able to confirm that is important. But honestly these people are few and far between.

You can look at a performance eval in three parts.

• Explain to them what you, as their manager, can do to help them make more money or get more authority next year
• Review of their performance and how does that impact your decisions.
• What should they be improving upon so that you'd pull the levers at your disposal harder for them?
• Many organizations have goal planning and performance evals as two separate exercises, sometimes months in between. However, 

Many managers just go through the performance metrics and that's it. Just because you filled out the space allotted doesn't mean your work is done.

Why they are falling short... of a PROMOTION

9 times out of 10 you will not be offering someone an above average raise or a recommendation for a promotion, and this is where you need to make sure that your understanding of their efforts throughout the year is crystal clear. You need to have the receipts for both situational occurrences where they could have improved and, more importantly, behavioral / skill set patterns that may be preventing them from getting as good an evaluation as they would like.

Why is it so important to lay it all out

Everything boils down to trust. The performance eval is the pivotal spot for a manager to make or break the trust that you've been building all year.  Your direct report should have a clear understanding about the process, what is in your control, and how their actions drive compensation and career track.  The review itself is more reflection of your understanding of their contributions, their impact, and their skillset that allows them to help the team become successful. 

Goals set next year are not only a commitment from your direct report on achieving certain goals, but also a commitment from you as a manager that you will ensure that they have the opportunities to achieving them. This is the key mutual relationship between you two that need to be established for both of you and the team to succeed.

It's definitely a balance

All of this is a balance of trust between you and your direct report that if they accomplish what you set for them, you will help them achieve more of what motivates them.

In the end, what you have to be is honest and demonstrate that their work and effort hasn't gone unnoticed.  The amount of effort that you put into these reviews is the clearest artifact of your commitment to a direct report's success. If they ever sense that it is half assed, they're on their way out.

Man, it's been nearly 10 years.

 Alright going to start writing up stuff again so what's happened.

Since Grubhub I have been at Paypal where I was absolutely not a good match for the Braintree nor Paypal culture.  

I joined Chowbus an early employee to head their operations and helped them expand up to a Series B round.

I'm now CTO at Bucket Listers where we're 1 year into operating a ticketing marketplace to promote cool things that are happening in your town.

All in all I've gotten to really flex on my convictions, some to great success and others to not so great success. I figure I have about 5 years left in my career so let's see where this all goes.

Logstash Examples with Data Generators

Logstash is a pretty cool application that generically takes some input, does something with the data, and spew it out somewhere else.

It's commonly used in conjunction with Elasticsearch, a Lucene based search service, and Kibana, a dashboard UI for Elasticsearch.  You can easily consider this as a "Splunk without super awesome ad hoc query capabilities" but the software itself is FREE so there's that.

The documentation for Logstash is pretty straightfoward, but I thought it would be nice to have some hard examples to work off of that involved the whole ELK stack:

Logstash Examples

Right now it just has two examples: file and log4j.

File:

• Write to a file
• Logstash monitors the specific file and does some grokking before passing it to Elasticsearch
• Load the provided kibana dashboard.
  

log4j:

• Spew log4j stuff out with SocketAppender
• Set up Logstash to monitor a port for log4j messages and grok before passing it to Elasticsearch
• load the provided Kibana dashboard

So yeah I hope this serves as a quick and easy way for people to observe the awesomeness that is Logstash.  Feel free to add your own examples to this guy as well.

IT'S A TRAP

Wife:  "How do you think I've been doing with my makeup lately?"

*pause*

Wife:  "... IT'S A TRAP!  No, seriously.  You have to answer."

Read the Freaking Documentation to Couchbase!

Just wanted to point out a pretty awesome product with pretty awesome documentation:

Couchbase.

We're using it for a pretty specific use case and for that, it's handling things extremely well.  However, we noticed that it was using a ton of swap space to the point I was thinking we were on Windows boxes.

Buuuut lo and behold we didn't read all the documentation on how our nodes should be set up and here it is for v2.2 that we're using.

http://docs.couchbase.com/couchbase-manual-2.2/#swap-space

Actually that screenshot is further down in the issues section, complete with impact and JIRA issues!

It's actually pretty awesome to be able to track something down this easily.  Obviously, other people have encountered this that has lead to issues but it's great to see the trail and the resulting recommendation.

Searching Pull Requests in Stash - You Don't

A pretty popular JIRA Issue for the Stash project is this guy, STASH-3856:

Search for pull requests

Specifically, the only reason why I'm searching for a pull request after the fact is to see if there were any conversation regarding a particular design decision or if there were any explicit things that were abstained from for later work.

Also, it's a super quick way to see when a given feature was merged into a particular branch like Master.

With that said, chances are, you're using JIRA alongside Stash.  Let's be honest, the only reason to use Stash over other solutions is for its JIRA integrations.  If your issues are directly associated with your Pull Requests, you should then be able to easily search your JIRA issues using its robust search features.

JIRA Development Panel

So unfortunately, if you're eagerly awaiting STASH-3856 to be implemented, I highly doubt that they're going to accomplish this any time soon.  There are definitely some Stash specific searches that would be nice, such as when a pull request's been merged or dismissed and when it's been updated.  However, until then searching for the JIRA issue can resolve the vast majority of people's use cases.

JIRA - Old School Greenhopper and Milestone Management with Versions

I wouldn't be surprised if there are still a lot of organizations that are still using the Classic Boards in JIRA Agile to manage their medium to long term plans in JIRA.  I want to just go over really quickly how one can manage these in the Classic Board before I talk about a much more complex scenario in a future post and I also want to go over the limitations of this approach.

First, you'd establish Versions in your Project that represented different Milestones with dates associated with them.  From there, you'd have your actual release Versions that are directly associated with the releases that you're cutting.

With the Classic Planning Board, using the SubVersion feature, you can readily see which Release versions that build up to Milestones that build up to broader Milestones.  You'd associate stories to your release versions and from there, you can track the progress of your Parent Milestone versions.

I wanted to work this particular feature in here as I still find it to be extremely useful today that few people pay attention to.  That is the Merge Version feature.  Essentially, if you already established a Patch release and realized that this guy isn't going to be released until the next Minor version, you just merge the Version into that Minor version.  From a Git Flow perspective, this would be comparable to the idea that you had a Release Branch prepared but never merged it to Master, but rather, just merged changes (if any) back to Develop.

So anyway, the biggest limitation to this approach are the following:

• FixVersion in JIRA suddenly becomes an overloaded Term.
• This method is limited for a Single JIRA Project.

Specifically, Atlassian realized that using FixVersion for so many different things, especially sprints, was not going to be a good fit for organizations that require some flexibility.  That is one of the core reasons why the Sprint field is a new core field for JIRA Agile.  Also, when a field starts to mean multiple things, 

Organizations can establish JIRA projects in a variety of ways for a variety of reasons.  However, when you have two projects gearing towards a common milestone, a lot of organizations start getting into the habit of having versions of the same name in multiple projects and identify them as the same milestone.

This can lead to a lot of confusion and inflexibility in how a new project can be established.  Also, you're shoehorning an association between two fields that the system doesn't natively support, you're probably using that field wrong.

Soapbox Time:  It's pretty hilarious how we, as developers of software for others to use, really suck at using the tools as they are originally intended.  Shoehorning functionality that doesn't exist "just because we want it that way" either means that we're just using the wrong tool or we honest don't know how we want our processes to function.  

Anyway, if you are still using Versions in this manner in JIRA Agile, I'd be very interested in what you like or don't like about using this method.  Next time, I'm going to cover the more recent JIRA Agile functionality that's be introduced circa 2011 that provide some more flexibility, but still have a lot of limitations.

Tracking Multiple Sprint Teams with a Common Goal

... or rather, a goal that YOU have that you're depending on other teams to accomplish for you...

So one thing I feel that people using JIRA Agile should get used to is the notion of building and breaking down Agile boards for targeted efforts to allow them to track something very specific and eventually just get rid of the board when they're done with it.

Here's a query:

"Epic Link" in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR issue in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR labels = myEffortLabel ORDER BY Rank ASC


What this query essentially means is "Give me these Epics, give me the Issues in these Epics, and give me any issue that I happen to label it.


This gives you a quick and hopefully, targeted view of a set of milestones in the form of Epics that you and other teams are driving towards. My personal observation is that the majority of teams pretty much ignore epics and epic links anyway, so establishing this linkage to the actual stories that they are working on should have minimal impact.

At the very least, you can keep an eye on the general progress of a concerted effort.

Just remember to clean up after yourself and delete the agile board when it's all said and done!

New Job, New City... so Let's Talk St. Louis

So how long does it take for one to find apply, interview, accept a job, prepare a house for sale, move, and settle down for a weekend?

About 3 months, apparently.

BTW, Google "days since april 17, 2014" and you get to a nifty app that tells you how many days.

So anyway, I don't usually talk about St. Louis on here as that's what's Yelp's been for.  Aside from our friends in the area, I'd like to take some time to point out some things that I enjoyed in my 10 years there.

La Pizza / Protzel's Deli / Bob's Seafood

Mmmmmm....

These are the 3 establishments that I will miss the most.  Not because of what they offered, but the people who worked there.  Heck, the La Pizza guys convinced the Bob's Seafood guy to let me pick up 60 lbs of live crawfish on a day they were closed.  That's how awesome they are.  I think I'll be hard pressed to find places comparable.  On top of that, these places were within 5 miles of each other, which leads me to my next point:

Regional Convenience

Sure, you could talk about what other cities have that St. Louis doesn't have, but if it were in St. Louis, it was dead simple to get there.  We lived in a spot where we could get to just about anywhere in the region in 30 minutes or less.  Also, 30 minutes typically means ~20 miles away.  Seriously.  The other day the wife was looking for things within a mile away from our place in Chicago and she was like "that's FAR!"

There's no Mitsuwa in St. Louis, but it might as well be because I have no idea how often we're going to get out that far into the Chicago burbs from the city.

Ok, I'm lying.  We have some good friends who live nearby and we'll likely use them as an excuse to go to Mitsuwa at least once a month or so.

Hometown Pride

To be honest, I think just about every single midwest city suffers from some form of inferiority complex.  Chicago included.  St. Louis is definitely not an exception, but the passion for working towards improving the area is infectious.  The atmosphere in the more urban neighborhoods is leaps and bounds more lively and optimistic than they were even a couple years ago.  The Loop, the Grove, Cherokee, even Downtown, which many left for dead multiple times in the past couple of decades, all have some pretty significant work going on that I was pretty gosh darned excited for.  

View from the top of the City Museum
http://ruff-ranch.blogspot.com/2009/07/city-museum.html

STL is one of those areas that is still transitioning from manufacturing to technology and sciences.  They definitely have some big trials coming up on the jobs front but there're enough skilled passionate people who actually have loyalty to the area itself to establish themselves and make it work.  Square, Woot, and Riot presences past or present were as much personal decisions as business decisions.

St. Louis has been good to us and I have nothing but fond memories of the area.  It will forever be the first place I've been an "adult" at and has definitely shaped my outlook on things.  See you around.

Microservices! Rorschach Reactions.

+Martin Fowler and James Lewis of ThoughtWorks have a really in-depth and thoroughly thought out article talking about Microservices.  There's particularly a nice blurb in it comparing the term to the more generic SOA.

The context of this article is kept at a more technical execution level.  I'd like to bring up some thoughts on the requirements and communication that can be involved.  In reality, this is more of a Rorschach reaction to the pretty awesome images that they had on their article.

Generally, three things a software development team thinks about are:

• What is my Deliverable?
• How is it going to change over time?  What are my requirements?
• Who are impacted of my changes?  How do I coordinate with them?

However, there's another question that, surprisingly, a lot of IT organizations are still extremely immature at handling:

• What deliverables need to be changed for my needs?  How do I get those changes to happen?

Here's a pic from the article discussing a functionally siloed organization and the corresponding Architecture that tends to occur.

Because of Conway's law, the architecture reflects the org structure, and this is also a representation of how requirements flow.  The UI folks have some user-facing use case and they need a service change from the middleware folks, who in turn, need something of the DBA guys.  One common disadvantage to this is the further away you are from the original requirement, the more you get some odd telephone game situation going where the API isn't exactly what the UI guys are looking for or the DBAs decide to ignore the middleware guy's model design.  This can lead to a lot of churn and rework.

With a cross functional team, you have teams that are more focused on the use-facing use case, rather than entire groups of people who are only focusing on their immediate deliverable.  One excellent point that is also made in the article is that large monolithic architectures can be organized "too many contexts."  The article posits that this tends to be a result of cross-functional teams in a monolithic architecture, but I think this happens regardless of how your teams are organized.  This is a big reason why we can get a lot of spaghetti logic, where a module may be trying to satisfy too many things at once, as opposed to being split into separate modules.

Something that these pictures also accurately depict is that your cross-functional teams would have fewer people of each function focusing on particular business logic and can likely be working on a particular microservice.  Looking at this from a requirements flow perspective, you can potentially get resource constraints (or managers imposing them), which is one of the main reasons why functionally siloed organizations exist to begin with.

This comes back to the questions:

• What microservices need to be changed for my needs?  How do I get those changes to happen?

Do you make requests to a microservice's backlog to be prioritized?  How do you deal with that team's resource constraints?  How do your requested changes impact other teams consuming that microservice?  These questions aren't specific to microservices, but with more granular teams, this amount of "red tape" may seem daunting to more traditionally managed organizations.

In addition,  with that many more deliverables in the form of microservices, ensuring that the consumers of your deliverables are prepared for the changes you're making.

In the left side for monoliths, consumers of modules have the option to choose which version of the module to include in their process at build/deploy time.  On the right side, the consumers have the option to choose which module to utilize by communicating with the appropriate service at run-time.  Fundementally, there isn't too big a difference in these dependencies, but operationally, in terms of identifying your dependencies and working with your sys admins on deployments, it is pretty different in terms of how you're communicating changes, dependencies, and to whom you're communicating to.

It all boils down to how well your organization can communicate across your teams.  For a small organization, physically talking or chatting on email or a chat service works out.  However, with large geographically distributed teams with potentially different cultures and whatnot, this gets unwieldly very quickly.

This post is getting long so I'm going to cut it here.  I'm not just talking about microservices, I'm talking about any organization that has multiple internal deliverables across teams.  How can a large geographically distributed organization, consisting of multiple teams, meet customer expectations while ensuring smooth operation from build, to test, to deploy?  I'll run through some thoughts on the challenges and solutions that may fit your given culture.

JIRA Shenanigans - @mention Multiple People

So previously, we talked about how the @mention feature in JIRA is pretty nifty.  However, the current feature only allows you to @mention a specific profile, one at a time.  Therefore, if you want to keep the conversation going in JIRA, all the participants are going to either need to be @mentioned every single time or they can be added to the Watch List.

Ripped off of
Atlassian Blog

If you have the appropriate permissions, you can add specific people to the Watch List yourself.  They may not appreciate it, but if they don't want notifications, they can always take themselves off.  I think this would be particularly interesting in how they improve upon their HipChat JIRA integration, but I digress.

Enter an open request in JIRA to @mention a group.  This makes sense in that JIRA allows one to configure groups of profiles to be identified in various permissions, mapped to project profiles, and notifications.  However, there isn't a view-only permission for groups or a way for a user to resolve the group to list of profiles, so the burden is up to the JIRA Admin to set things up, maintain them, and let others know who the group members are.  There's an open request for this guy as well.

To take things further to allow more flexibility, I submitted a request for @mention to a Project Role, allowing each project to determine which profiles or which groups should get a notification.

Fortunately, there's a pretty dead simple way around this, which is to create a dummy profile whose email address is an email distribution list.

There are definitely quite a few issues/limitations with this approach.  Some of the immediate things that come to mind are:

• It will be dependent upon your email setup as to who can view the members of the list and who can edit it.  This is all dependent upon your organization.
• This takes up a slot in you JIRA user license.
• Unless you actively have a user for this distro in an externally managed system like LDAP or Active Directory, this requires you to create the user in the JIRA User Directory.  This may require some admins to fenangle with their current setup.

So as always, one of the easiest ways to keep up with the features that you want in any of Atlassian's tools is to add yourself to the watch list in Atlassian's own JIRA issues vote on them.  @ mentions can definitely be improved upon but the tool can only be as good as the feedback the developers get from those actively using it.

JIRA Shenanigans - @mentions are better than Email

One feature that has drastically changed the way we use JIRA among a geographically distributed team is the @mention feature.  This allows one to specifically notify someone: "hey I think this is important you should read this."

We all hate the telephone game and accountability is pretty important.  This is enforced in a strong way from Alice in this Dilbert comic:

The thing is that there are a couple issues with E-Mail.  The main thing is that it only resides in the inbox/outbox of the recipients/sender, preventing any normal person from taking a look at the conversation later on.  You'll get the whole "oh there's a thread floating around I'll forward it to you" scenario.

Especially when an email is just between two people, you run the risk of some valuable communication being lost when both are not around for whatever reason that may occur.

Enter JIRA Comments.  Having the conversation there provides a couple things.  It's a public forum so people tend to be a bit nicer there.  It's query-able, as all Issue fields are, and they persist so long as nobody deleted the issue.

There's this nifty @mention feature that you can use to direct a comment at someone.  This provides a notification to someone (usually in the form of a an email) with the comment.  However, this adds the context of the JIRA issue and the rest of the conversation.  Some annoyances from this feature comes when you're in a thread with multiple people and you want to ensure that everyone gets a notification.  In this situation, Watch Feature can be used to then keep up with the conversation as well as other changes.

After I wrote up all that (and most of the next post) I stumbled upon this blog post by +Dan Radigan that concisely describes using @mentions and Watchers effectively.  In addition, it also has some nifty queries to help people find posts that they were mentioned in as well.  Definitely check it out.

This post is getting long and I want to talk about how @mentions only allow you to notify one person at a time.  Wouldn't it be nice to quickly and easily notify a bunch of people at once?  Well, as of this post, JIRA doesn't support that, but there's a pretty nice workaround.  I'll get to that next time.

KineticJS on Chromecast

Pretty lame looking video of my getting that Idlewild Boat Race Clone on Chromecast, but I thought that was cool.

Why Story Points are Cool

Sure.  Dilbert Comic.

So to carry on the conversation where some people are saying that estimates, in general, are a waste of time, I'd like to cover some situations where having Story Points are particularly useful.

Do we agree on the requirements?
You really shouldn't need an excuse to drag product/business end users, qa, and developers to have one last sanity check on some requirements.  Getting everyone to agree, at the very least, what the requirements ARE and taking the next step to cover some technical detail as to what the effort would be.  You definitely don't want "the expert" to do the estimation as this is a method of risk mitigation of "expert getting hit by bus."

Do I have enough ready-to-work Stories in the Backlog?

As a product owner, you need to know whether you have enough stories pokered and agreed upon by the team for the next sprint.  This is dependent on knowing your team's average velocity, whether people are going to work vacation days, etc.

Also, depending on your team's process, a Product Owner can ensure that the backlog consistently has a decent amount of low point stories that the team can incorporate into their own sprint.  This is for teams that have the rule that a developer can bring in a story after the sprint start only if they think they can complete the added story within the same sprint.

When are we done with Planning?
Pretty much exactly the same thing as the previous point.  More importantly, when can you end the planning meeting?

Where Story Points don't help:
One scenario where Story Points may just be superfluous, and that is when a team typically breaks a story down to the point where they are all essentially equivalent levels of effort.  This exercise is particularly useful for teams with extremely short sprint times.  This all depends on what your team wants to accomplish and how they want to accomplish things.  However, if just about all stories are broken down to 3 point stories, you are still running through the exercise of Pokering, but rather than asking the question "what's the level of effort for this story," you're asking "is this story a 3 or not?"

... but don't get too focused on those Points

It's really easy to latch onto some quantitative value and to start drawing conclusions.  People are going as far as to asking "why are we FAILING our COMMITMENT?!"  In the end, Story Points are just a tool to help us answer the following, but not used as the ONLY metric to answer:

• Are we meeting customer expectations?
• Is there any action we can take to improve?

This is really hard to drive home for a lot of people and you're likely going to have a couple "electrolyte" conversations but it is truly worth it.

... but what about our commitment?

Either way, I hope this will provide some ideas for Product Owners in particular in using Story Points to help manage not just their own day-to-day work, but also drive home that it's just a tool to aid in efficiency and identify potential areas for improvement.  We should never become slaves to our estimates.

Whatever Happened to Risk when We Went Agile?

There seems to be some sort of rallying cry that Story Points and, in general, estimates, should be gotten rid of entirely from any sort of software development process.  I think this is, generally, a very strong kneejerk reaction to some pains through the development and release process in terms of managing expectations.

Usually said pains come from someone managing expectations in the following manner:

• A Release is planned with a set number of User Stories define
• Said user stories are pokered 
• Project Manager compares the sum of the user stories against the team's velocity and converts that into sprints - let's say they determined that it sums up to about 4 sprints.
• Project Manager sets a release date approximately 4 sprints from now.
• Project Manager attempts to hold team accountable to the Release Date.  The word "commitment" seems be the word of choice, lately.

The most glaring issue with this situation is something that doesn't get mentioned a lot in the agile process: accounting for risks when managing expectations.

We've all probably seen various different risk charts that show likelihood vs. impact with mitigation plans associated with each.  These have all but disappeared.  Granted, I'm not saying that a team should get back to long drawn out risk powerpoints, but it's the team's responsibility to bring up these risks.  It's usually the project manager's responsibility to communicate these risks out.

I get the impression that a lot of agile teams have lost sight of actively tracking risk and reflecting it back to project stakeholders.  It's not like they've gone away because you're doing Scrum.  

Here's my unscientifically backed opinion on medium to long term estimates: shoot from the hip estimates in terms of resources and man-hours from an experienced manager, in conjunction with a development leader or two, is just as good as a thoroughly pokered out backlog.  You take a look at it from a high level, identify some risks, and based on what you know from the team, manage the expectations of the stakeholders.  

Some may argue that more vague stories with point values far exceeding your sprint threshold are just as good.  I actually don't have much direct experience in trying that, but it would also be something to think about.  When you get story points that are as high 100 points, to me that's pretty much the same as a shot from the hip.

The last thing you want, however, is to attempt to define all the lower level user stories at the beginning.  You will find yourself spending an arduous amount of time at once to try to estimate something months in advance and opening yourself to the challenges that impact Waterfall.

In the end, it all boils down to plain ole communication, including the appropriate people in the decision making process, and getting buy-in for the final decision.  At the very least, you didn't spend an ungodly amount of time holed up in a room trying to think of every single thing for the next couple of months.

So why poker at all? Well, there are a boat ton of uses where pokering, with Story Points in particular, is very useful.  This post is getting long so I'll talk about how they help smooth out the process from sprint to sprint in the next post.

JIRA Shenanigans - Attach Screenshot Feature

If there was a feature in JIRA that was both awesome and not-awesome at the same time is the Attach Screenshot feature.  For an organization whose culture, for some reason, has been imbued with pasting screenshots into word documents, and then attaching the word documents in ALL of their tools, the attach screenshot feature can be both a time-saver for both the one reporting the Issue and the one consuming it.

ಠ_ಠ

Of course, one can point you to JIRA Capture, which, I'll admit, is a super awesome tool for testing web applications and contains a slew of features to aid QA in recording their test sessions and providing visual aids to others of what they're observing.  

Convincing an organization to drop more money on a tool is very hard, so let's get back to why the Attach Screenshot feature can be a pain:

Chrome and 64-bit Java + other Java Shenanigans

Here's one of the issue documented with this Java Applet (oh right, it is a Java Applet).

So straight out of the box, if you like to use Chrome and if you only have 64-bit Java installed, the applet will not work.  If you're not the admin to do the solution I'm going to describe below, you're going to have to do some configuration.

JIRA has historically been a tool directed at more technically minded users, but this specific limitation is extremely tough to get some people to A) find a fix on their own and B) actually be able/willing to fix it. 

Additionally, you can easily get the question:

"Why should I work so hard to get a tool that we PAID for to work the way I want it to?!"

My answer to that is that most people don't realize other comparable tools cost way more without the customization capability, but nobody wants to hear that.  It then isn't surprising that this very same culture will lead people back to the word doc attachments (without even considering that they can attach saved images).  It is quite the endless cycle of violence.

I didn't pay for Linux so it's OK that I have to
spend hours to make it do what I want!

So is JIRA going to fix this?  Indeed they are!  As of this posting the issue is "In Progress" so I'm hoping it shows up in their next minor version.  

JIRA Issue: "Rewrite screenshot applet using not-java"

Fortunately, we don't have to wait for the next version of JIRA to get this feature.  Atlassian Labs has a plugin in the Marketplace that isn't dependent on any 3rd party installation.  

Better yet, if you have troubles in your organization with making upgrades to existing tools (aka you're not going to make an upgrade to JIRA even if this feature is availble), you can install this plugin on older versions of JIRA.

Ripped off the Marketplace page

Getting a feature that works right away for all users is the best way to get adoption and can aid in quashing that Broken Window affect that may be plaguing your cultural processes.  

While you're at it, definitely check out other features that Atlassian Labs has developed that may go into future versions.  Find the appropriate feature request in JIRA, watch it, and upvote it.  The more you use Atlassian's JIRA as a user, the more you can figure out how it can help your organization.

Random JIRA Shenanigans #1 - Development Panel

I've decided to start putting in random JIRA configuration notes in here that may be of use to some people: JIRA's 6.2 release has a pretty sweet feature called the Development Panel with a lot of great features if you're using Stash and other git tools.

Unfortunately, we're not using any of those tools.

 BUT, we are using Fisheye 3.3.1 and the big bonus with this feature is that it explicitly shows us the branches an issue is being worked on. Technically, because we're using Gitflow, it shoooould be one branch...

Either way there were a couple of finicky things that we had to do that wasn't explicit in the documentation to make existing integrations with Fisheye/Crucible continue to work as expected.

Initial Configuration

• Fully Trusted Applications Links between JIRA and Fisheye
• All Users in Fisheye are in JIRA (but not the other way around.)  Fisheye uses JIRA User Directory for Authentication

Final Configuration

• Edited Application Link between JIRA and Fisheye
• Disabled Trusted Application Link
• Enabled 2-Leg OAUTH
• Impersonation Enabled.

The first finickiness was that I didn't have Trusted Applications disabled in the Application Link.  This prevented the Development Panel to show up to begin with.  A quick hit on Atlassian Answers gave me an answer:

Atlassian Answers Question

The next thing, however, was a little odd.  I did not have Impersonation Enabled with 2-leg OAUTH.  In hindsight I don't even know why I didn't do it, but when people were attempting to close their code reviews in Crucible, they were seeing this guy:

Fisheye was having an issue getting specific data for an issue in JIRA.  Enabling impersonation did the trick to allow users to transition the appropriately linked issue if so desired.  Specifically, because Fisheye's user base is entirely based off of JIRA's user base, we didn't have any issue with Fisheye utilizing this feature when interacting with JIRA.