Daniel Harrison's Personal Blog

Personal blog for daniel harrison

Close To The Problem November 16, 2007

Filed under: development — danielharrison @ 12:59 pm

I work in a small growing company and to our competitors I think we’re a bit disruptive. I was musing the future and something occurred to me, is the reason why small agile companies can be so successful is that they can get closer to the problem than established enterprises? When going up the adoption curve, just after crossing the chasm and being small, light the company structure tends to be pretty much flat with zero barriers to communication. When a company is small and growing you tend to hire after the fact, resources are constrained, so engineers are intimately connected with users because there’s no intermediary. To some extent I think during the growing phase they tend to be almost jack of all trades and the stretch is a good thing. Developers/Engineers are forced to make decisions all the time which have big implications for the success of the software. Being so connected at that stage I think means that the decisions made tend to be the right ones because the technical staff are closer to the problem, hence solutions that are innovative and solve user problems. Is the stretch a function of success or a prime contributor?

This leads to a point in that’s been rambling around in the back of my head, what does this mean for the role of the business/product analyst or more generally a position that owns user interaction and requirement elicitation? Do you really want developers who can’t talk to users or elicit requirements? I think having an intermediary instantly means a choke point. Every meeting and conversation requires the intemediary. User interactions are now owned by a particular person and serendipitous solutions that once occurred because of the close interactions start reducing. Going directly to users for their thoughts means you are encroaching on the intermediarys responsibilities and can pretty easily come off as lack of faith in their judgement or as sidelining. The upside is more predictable release schedules, issue resolutions, easier to build software, … .

Part of my musing was kicked off by 37 signals article on personas, which to me crystallised a number of thoughts I was having. Being close to the problem means you can more efficiently solve user problems. Analysts given responsibility to produce personas, use cases, the whole kit and kaboodle to communicate user desires implicitly turn the focus from what the user wants to the documents, written output as a review process. Reviewers, technical staff, documenters, testers, designers loose the ability they once had to frame the solution from their intimate knowledge of the user, and rely on the persona’s to frame the solution, which could very well be the wrong solution. Review becomes about the ability to build the proposed solutions, it’s schedule, look and feel, testability instead of the naked problem. The people doing the work become too distanced from the problem.

Does this mean I think we should kick out all the analysts like some agile solutions. Well I’m not prepared to go that far yet and I’m not convinced that it’s the best course of action. I think my main thinking is that development and user communication needs to be an inclusive process. Developer’s must be close to the problem.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s