We're back and the results are taking shape

After a month or so snowed under by our real jobs we're now back on the survey trail. That month snowed under was also a month to spend some time talking about what we'd learnt so far and what it meant for us and the survey. The good news for you is that Marc and I decided to hold nothing back and let you in on all we've learnt and all we're thinking.

 

And that learning and thinking is starting to take shape. We've knocked off a few more interviews over the past weeks and although they've all been very different we've seen several common themes emerge. It's feeling like there's going to be some interesting stuff to present. 

One of the things interviewees have been surprised to learn is the angle we're taking in interviews. Rather than the standard "what's your favorite tool?" type questions we've instead been trying to uncover answers to questions like "why that tool?", "what effect did it have on you, your team and stakeholders?" and "how did it aid or impede your agile journey?".

Taking this line has allowed us to form what we think are some unique insights into the issues surrounding the current range of tools. We'd like to think these issues are solvable though some are admittedly very challenging. Not only to agile tools but to software tools in general.

Of course for the details of those challenges you'll need to wait for the results. Marc's flying in to Perth mid November to spend the weekend with me putting this all together. Once that's done we'll let you know what form the report will take and set a date and place for the presentation.

Until then things may go quite again for a while. Don't want to let the cat out of the bag too early!

When "some other dude" buys your agile tool

Back again. We've started our interviews and wanted to briefly mention one of the trends already emerging. The trend was recently coined "Big Hire, Little Hire" by the folk at JTBD. It happens when "some other dude" buys your tool for you.

Stories to date suggest this occurs when we have teams and individuals practicing agile within large organisations. The teams have a clear understanding of their need and could no doubt make good buying decisions but working in a large organization find they lack the power to make or even influence the buy.

It's really interesting to hear who actually decides the tool to purchase in these cases. You would think the agile team that wants a software tool would make the decision. And in a smaller organisation we think this is probably true. However in large organisations you have competing interests from groups such as finance and the PMO and the decisions that result are interesting from afar and no doubt maddening from within .

This is what we'd call the "Big Hire" by the finance group and the "Little Hire" by the agile team. 

Peppering of these stories are emerging from our interviews and to see it raised at JTBD last week tells us the problem is not just limited to agile tools. 

JIRA Dominates

Perth is a JIRA town. 100+ respondents told us so. But rather than answer a question all this does is raise a new one of why?

The problem with surveys is they’re like photographs. A snapshot in time filled with the detail of a moment but with only a hint of the story behind it. To understand how this moment came to be we need to go back to the people present at the time.

But often one recollection is not enough. We're human. We have opinions. We don't all see things the same way.

Picture this situation; I'm an agile guy and we are on the same team and you say, "We should be using Pivotal Tracker?", and I respond back with "So what problems are you trying to solve exactly? Because the other day over coffee Mary said JIRA rocks and Bob was adamant we don't need a tool!......Now I'm confused :-s"

There are forces at play behind the opinions, a push to use a tool and a pull to the attractiveness of a solution. But there are also these opposing forces holding us back - an anxiety of sorts - we don't want to change the way we work but we might have to if we use a software tool.

These are the forces we need to understand to uncover the jobs we're really trying to get done. And that is the aim of our research.

We would like to thank everyone for their contributions so far, but we're not stopping here. Now we need to hear your stories and next week we start our series of interviews with those that have nominated to talk.

Marc & Tim pairing

The big company / small company dimension

We're now a couple of weeks into the survey and the count's at 83 responses. A big thanks to all of you for taking part and a special thanks to the 25 that have offered to chat with us over the coming months. It's the stories we uncover in these interviews that we're most interested in. As they take shape we'll have a meaningful and focused way of interpreting the stats we're seeing. 

To give you some initial insight into the survey... one of the tactics we'll be employing is to identify a set of dimensions. Yin and Yang classifications that might affect how you use the tools. Govt versus Private. Product versus Non Product. Co-located versus remote. If you're interested in reading up further on dimensions or the other techniques we're using then do a few searches on "jobs to be done" or #JTBD on twitter.

One of the dimensions we think holds promise came to us from a respondent's answer to our request for feedback. The answer read "Survey is a little bias to big end of town...". Marc and I never intended this in the survey but looking back I can see how it could be interpreted this way. And so this comment got us thinking. Did we bias it this way and if so why? I concluded that for myself at least I probably am a little big end bias and that the big end bias comes from the fact that my interest in how we use agile tools is rooted in environments that don't neatly fit the classic agile mold. Environments that you'll typically find in large organizations where the forces are - for wrong or for right - a little more complicated. 

Smaller organizations (and especially those with a clear product) fit the classic agile model well. I managed this type of environment in my time with a geophysics company and although we never used an agile tool I suspect if we had it would have worked pretty well. My reasoning is that the card wall we used worked pretty well and when I think about it that's what most (all?) agile tools do. Digitize the card wall experience.

But in more constrained environments the classic model of agile is often morphed to some degree and it's in these morphed environments that the tools start to fail. I'd like to know why and I'm hoping that in exploring this dimension we'll find some clues. 

The big company/small company dimension (or perhaps better termed the classic/constrained agile dimension) is not the only dimension we're considering but right now it's the one I'm most interested in.

Tim

 

BTW in case the you're wondering... these public posts won't be a substitute for the respondent only report. We'll be walking that fine line of giving you a feel for what we're up to without spilling any details of our conclusions.