10,000 Foot Developer

A long time ago I was in one of those corporate rah-rah training programs that dealt with teamwork.  One of the exercises was putting together a difficult puzzle as an individual while team members watched, knowing the solution, but could not help you at all.  One particular person we got to watch absolutely could not rotate a block to solve a puzzle and the amount of frustration we felt was incredible.  But moreso, was watching how the poor puzzle solver was locked, locked into a solution they tried over and over again, and kept failing over and over again.

I see this often in the real world.  For instance, many developers come onto a new project and immediately criticize the frameworks or implementations having never mastered any of it.  I saw a developer who had not even gotten a running instance up insult the MVC framework of an app just recently — even though he had no experience with it and had just recently started to read about them.  Many people criticize technologies like Flex or relational databases having never ever written line 1 of code in them.   The same certainly applies to management.

Recently my team was told to use JIRA as a PM tool — not just as a bug tool, but also as a PM tool.   I thought, what the heck why not.  I have extensive experience with JIRA as a bug tool; Rally,  XPlanner, and to lesser extents Mingle, VersionOne, and Pivotal Tracker as PM tools.  Of course MS Project Manager (the goal of all these hahahaha  🙂  ).  In a later article I will comment on JIRA used in this manner, or maybe if we get Greenhopper — and believe me it needs commenting.  But for now we are using JIRA as a bug tool.

What amazed me was that when I sat down with the product owner and the PM, they immediately wanted to change the tool, start adding fields and workflows.   Neither had used JIRA before, neither had received training.  While its true they had their organizational knowledge, and that cannot be understated, it was very interesting to watch people project their expectations onto a tool without even knowing what it was.

The only thing to do was to actually look at the tool, hear experiences, and gather requirements for our needs.

For instance the PM wanted to use a date field as a “hand off” field for task people — but the workflow already handled this.  The product owner had an interesting view on the status values for his purposes, not even having looking at them!  I explained OK, maybe we could do that, but it might break its usefulness for the task people.  We had to figure out the scope of each activity as it pertained to whomever would be using it.

We started to review each field and what it could be used for, and how it might fit our project.  Then we looked at the flow and statuses.   I explained to them how I had used this tool (quite often) in the past and why those flows or statuses were there, and if we changed them what the implications might be.

This has happened quite a bit in my career — management teams and builder teams have different flow and status needs.   They cannot be merged into one, they can only be layered.   This has to be called out or someone will be very hindered or have to do double entry of status somewhere, which defeats the purpose of using tools — saving time.

In the end we agreed to try it out in its vanilla state and incrementally recommend change.  The idea of process that changes over time was kind of new to them, but they saw the value in it right away.  We’ll find the balance.  Also, we are hindered because the entire company is using JIRA so addinng a field might not be such a good idea if it only pertains to us (since everyone else will get that field too).  The super-high level people peeking in don’t want that.  SCOPE!!!!

This hasn’t always went well at places I’ve worked.  I year ago I noticed a huge breakage in our flow at a place I was consulting — basically we needed a build number in our stories so we could track checkins for the QA and BAs.  There was a whole huge manual workflow around this that wasted time and cascades even up to what was deployed at the release level.   A simple field would have solved this.  But the director saw no use in it for his own needs from the tool, so it was never added.  Que sera, sera.

The lessons:

• Learn the base tool before making use decisions.
• Training sure would help.
• Know your own flow.
• Be ready to change.
• Make sure you gather requirements and use cases for all concerned parties.
• Don’t use a tool if someone will find it burdensome.
• Keep a flexible mind, because your method may not solve that puzzle.