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.

Idlewild Boat Race Clone

Sure. I'm going to say that Atwood's Law applies here.

Things We're Exposed to as Children that We Forget for Work

Oh Bert'n Ernie.  I'd like to think that I am Bert most of the time, but I'm sure I'm guilty of being Ernie when describing the rationale for requirements to others.

If you didn't catch Harrison Ford make a reference to this with Glenn Close you need to watch Air Force One NOW.  But seriously.  Expectations management is hard.  Scope creep is a bitch.

This was the best Telephone game video that I could find on Youtube.  It's surprising how often you see everyone in the room take little notes in their note pads to take off to their teams on what happened.  Heck, I've seen this happen when people enter things in a spreadsheet, and then someone else has their own spreadsheet, and they work together to make one AWESOME spreadsheet!

User Stories - Asking some Questions

If you're looking for me to spell out what specific elements a User Story should have, I'll just point you to test framework called Cucumber where you write "Cukes" to describe the behavior you're testing.  When thinking about how you're going to test something, the User Story becomes pretty apparent.

http://cukes.info/

But rather, when Business Analysts, Developers, Product Owners, whoever is writing user stories, there are a key questions to ask that can drive what your User Story should look like and more importantly, what supplemental information may aid in the development process.

Whose problem are you trying to solve or alleviate?

If this isn't the first question you're asking, you might as well go home.  Now.  You're home?  Step outside.  Walk a block.  Ok.  Go home.  Look at cukes again.  I'm not saying you should be using Cucumber for your test framework, but they have very good ideas.

How can someone validate this?

See the cukes.

Who's Going to Consume Your User Story?  Who participates in the release cycle?  Who are responsible for validating your implementation against the User Story?

To me, these are all the same question.  However, you may get different answers to these questions, depending on who you're asking.  This is something that's very specific to your project and organization.  However, all the people that may be identified as answers to these questions can benefit from reviewing the User Story.  Why is that useful?  How often do you find yourself having to demonstrate a feature to someone to explain to them what the feature is?  How often are THEY then demonstrating it to others to explain to them what the feature is?  Your organization can have a slew of handoffs where a clearly defined User Story can save time and reduce the Telephone Effect.  Here's an overloaded example:

Product Owner -> Developer -> QA -> Training/Documentation -> Support

In a conversation the other day, an IT manager that supports a huge bio-research organization mentioned that the largest challenge towards their adopting Scrum was that [non-developers] think that it's "just for developers."  Without diving any further into the specifics, I feel that this is due, in large part, to some organizations not disseminating User Stories out to non-developers.  In a more Waterfall environment, you may have a very extensive requirements and design document... that nobody reads.

One potential pitfall for a User Story when it's "just for developers" is when someone, in reality, is simply writing a technical task to be done.  With that, I simply point back to Cukes again.

Do you need buy-in for your User Story?

This heavily depends on your organizational culture and how much trust everyone puts into the Product Owner.  However, when seeking feedback, identifying potential gotchas, or simply being able to come up with a better design, answer the following as part of your supporting material can greatly provide food for thought.

• What's the current behavior?
• Why is it not optimal / desired at all?

When working towards buy-in for your User Story, it not only helps people feel more valued, but also increases the organization's trust in your being able to identify the overall direction of the product.

With that last sentence, if not to be more efficient, increase organizational cohesion, and increasing clarity in the process, just simply thinking about these questions when writing User Stories can make your life easier when people trust you more.