Friday, July 11, 2014

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.

Sunday, April 27, 2014

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.


Saturday, April 19, 2014

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.


Sunday, April 13, 2014

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.

Friday, April 11, 2014

Saturday, April 05, 2014

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.

Monday, March 31, 2014

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.