Tuesday, 16 October 2007

Tools for the Development Team (2)

coffeeprocessTo continue where I left off, the management team, of which I am a member, looked at Jira in a totally different manner. Each person had their own needs for a tool ever so slightly different to Jira. This caused some problems as I was then asked to evaluate a number of other tools that, perhaps with some compromise, everyone can use. Some suggestions were forthcoming and I dutifully took at look at each one.

The problem with the approach that I made to the management team was that I had obviously failed to impress what the development team needed in the tool. You see, I was out to sell the tool to the rest of the company and in doing so I was focusing on their needs instead of the development team's. This meant that instead of learning how the development team were going to contribute and communicate better, they were thinking "how can I use this new tool", which invariably led to "I need this tool to do X, and I know one that does X much better than this". Of course, that meant that they were thinking of their own needs and Jira just didn't cut it for them. Dang, I missed the plot there.

I got suggestions to consider like Phpaga (http://www.phpaga.net). This is an excellent tool for contacts, invoices, financials, and billing tasks, but it has little to nothing to do with the development process. After discussing this and writing up a small review for the management team I suggested that a CRM package was more in line. They have one so will look again at using it effectively.

Almost all applications I looked at served a single particular purpose, and added some other purposes somewhere along the scale of between "ok" and "that really sucks".

So lesson learned. What I should have done is sold it as a development tool. I could have shown the management team how much better the development team was going to be, how much more accountable, how they will now get both statistics and answers from this bunch of strange speaking weirdos that did things magical and totally unknown things that produced the final products. Now they might understand what's going on there and the tool will be well supported.

As I stated in my last post, I have a number of tools that I will touch on briefly over the next few posts, but as you might have guessed, we have finally decided on Jira. Surprisingly that decision was not made by me. The development team were also asked to review a few of the more successful tools and give their feedback but it was their own decision that we should go with Jira. While Jira did not have the nicest interface or the best reports, and it was only an issues register, it was voted in as the tool to use.


  1. "As I stated in my last email,": you probably meant "last post", right? :)

    Anyway, I felt I could leave a line here to say that it's a nice work you're sharing here... Even though I'm currently a one-man-shop, I'm thinking on evolving sometime next year and saving some time cutting through a gazillion dev tools by reading your impressions on those is surely a good thing!

  2. Woops, fixed it now. There's always an error somewhere. Thanks for pointing that out.

    It's been good to put these trials down on my blog like that, rather than in fancy reports. I have some leeway in a blog rather than in a clinical report.

    I could have simply made the decision and enforced it on the team, but when recommendations started coming in from others who read my blog, it was prudent to look at these others, and even involve the team.

    Thanks again.


Note: only a member of this blog may post a comment.