{"id":287,"date":"2011-03-30T06:07:07","date_gmt":"2011-03-30T13:07:07","guid":{"rendered":"http:\/\/10kdev.ivystreetinc.com\/?p=287"},"modified":"2011-03-30T06:07:07","modified_gmt":"2011-03-30T13:07:07","slug":"the-base-nature-of-a-technology-but-not-necessarily","status":"publish","type":"post","link":"http:\/\/10kdev.net\/?p=287","title":{"rendered":"The Base Nature, of a Technology (But Not Necessarily)"},"content":{"rendered":"

A long time ago I was in one of those corporate rah-rah training programs that dealt with teamwork.\u00a0 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.\u00a0 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.\u00a0 But moreso, was watching how the poor puzzle solver was locked, locked<\/em> into a solution they tried over and over again, and kept failing over and over again.<\/p>\n

I see this often in the real world.\u00a0 For instance, many developers come onto a new project and immediately criticize the frameworks or implementations having never mastered any of it.\u00a0 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.\u00a0 Many people criticize technologies like Flex or relational databases having never ever written line 1 of code in them.\u00a0\u00a0 The same certainly applies to management.<\/p>\n

Recently my team was told to use JIRA as a PM tool — not just as a bug tool, but also as a PM tool.\u00a0\u00a0 I thought, what the heck why not.\u00a0 I have extensive experience with JIRA as a bug tool; Rally,\u00a0 XPlanner, and to lesser extents Mingle, VersionOne, and Pivotal Tracker as PM tools.\u00a0 Of course MS Project Manager (the goal of all these hahahaha\u00a0 \ud83d\ude42\u00a0 ).\u00a0 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.\u00a0 But for now we are using JIRA as a bug tool.<\/p>\n

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.\u00a0\u00a0 Neither had used JIRA before, neither had received training.\u00a0 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. <\/em><\/p>\n

The only thing to do was to actually look at the tool, hear experiences, and gather requirements for our needs.<\/p>\n

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

We started to review each field and what it could be used for, and how it might fit our project.\u00a0 Then we looked at the flow and statuses.\u00a0\u00a0 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.<\/p>\n

This has happened quite a bit in my career — management teams and builder teams have different flow and status needs.\u00a0\u00a0 They cannot be merged into one, they can only be layered.\u00a0\u00a0 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.<\/p>\n

In the end we agreed to try it out in its vanilla state and incrementally recommend change.\u00a0 The idea of process that changes over time was kind of new to them, but they saw the value in it right away.\u00a0 We’ll find the balance.\u00a0 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).\u00a0 The super-high level people peeking in don’t want that.\u00a0 SCOPE!!!!<\/p>\n

This hasn’t always went well at places I’ve worked.\u00a0 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.\u00a0 There was a whole huge manual workflow around this that wasted time and cascades even up to what was deployed at the release level.\u00a0\u00a0 A simple field would have solved this.\u00a0 But the director saw no use in it for his own needs from the tool, so it was never added.\u00a0 Que sera, sera.<\/p>\n

The lessons:<\/p>\n