Jason, a good BA is worth his/her weight in gold in a good team, and that’s exactly the point, it’s a team effort and, it seems, unless that team consists entirely of developers, you’re uncomfortable.

I will happily concede that the very best BAs are former programmers with some business experience so that they have a common language when communicating with both “camps”. Can a great developer fill this role? Well I’ve never met a great BA who is also a great developer and (you’re not going to like this) I’ve never met a great developer who’s also a great BA. Surely not everyone in your team can fill both roles…properly?

If I’m hiring developers, I want a great developer who can focus on his work and use his/her creativity and ingenuity to provide a brilliant solution. Just like I don’t want a plumber who also does heart surgery to do my bypass, I don’t want a dev who also does analysis sitting in front of my customer, sorry.

As Dave says in his blog, the only problem with this is that the customer isn’t always available on-demand when the developer needs an answer. They may not even be there for sprint planning.
Then who does the developer ask for clarification?

Will he sit there wasting time waiting for a meeting, just develop what he thinks is right, or maybe ask the BA who’s sitting across the room?

Not sure Jason’s got a chip – more like a whole sack of spuds.

It sounds like you are explaining problems associated with a waterfall approach rather than scrum. My reply was so long it created a blog post for it which can be found here:

http://blog.davehawes.com/post/2010/03/05/Developers-are-only-a-cog-in-a-software-development-project.aspx

Definately a good debating point!

If the team sends a developer to talk to the customer who requested a feature, why _wouldn’t_ we send the developers(s) who will be writing that code? Is it ever any better to send a developer to elicit undertanding from someone we sent to elicit that understanding from the customer? That sounds like Chinese whispers whichever way we paint it. If if that analyst “speaks both languages” they must be a programmer, too – since the developer’s language is code. So why aren’t they writing the code? If your BA doesn’t write code, then they don’t speak the developer’s language, which makes getting precise, executable requirements out of them no easier than agreeing them with a non-technical customer. They are a step in the process that adds no value in that sense. A C# compiler that just gives you more C#

I do not agree that teams should not have testers, but again, the most useful testers are the ones who can write executable tests and automate them. Which makes them a kind of programmer.

Both roles – test analyst and requirements analyst – are one and the same in a test-driven approach. And since a useful analyst in both cases is one who both “speaks the developer’s language” (code) and can write executable tests (programs that test software), we inevitably reach the conclusion that the people most qualified to fulfil those roles are people writing code.

The true purpose of the development process is to translate customer requirements into 1’s and 0’s. Necessary in this is the need to narrow down ambiguity into absolute machine-executable precision. MDA, for example, attempted to “cut out the middle man” by having analysts create executable models and then machines turn them into the 1’s and 0’s. So managers could do away with costly and frustrating luxuries like programmers. The reality is that if someone can’t program, they can’t program at any level of abstraction. Logic is logic and Executable UML is a programming language.

And if what you get from an analyst isn’t any more precise and executable than what you get from the customer (and it very, very rarely is) then you’ve brought yourself no closer to satisfying those requirements.

What usually happens is that analysts and managers don’t explore the business goals of the project at all. The subject does doens’t come up. Instead, they shore up in a meeting room somewhere with the customer and emerge weeks or months (or years) later with a system design – a design for a solution nobody has bothered to try to understand.

And us poor programmers are handed this spec and we’re expected to make it happen. Which, of course, we can’t. Because it’s full of ambiguities, logical contradictions and fanciful pipe dreams – often not of the customer’s inception at all – that we’ll never have the time or money to realise. If we push back and say “sorry, here’s a reality check” we are labeled as difficult and obstructive. That’s why dotcom entrepeneurs often have such a low opinion of programmers. We’re spoilsports.

Then the goal of the project becomes about implementing this design rather than solving business problems. And you can’t blame us for being naturally skeptical about it all.

Programmers are no just glorified compilers. Projects need our creativity and spirit of innovation every bit as much as our technical know-how. We’re like actors. It’s no good just handing us a script and telling us to read out the lines (particularly when the scripts just says vague stuff like “Joe says something about his mother” or is loaded with nonsense and contradictions). We need to know our “motivation” for what we’re saying. We need back story. We need goals. We need consistent continuity and logic.

And the absolute worst place to find this stuff out us sitting in meeting rooms gassing about it with analysts and managers. Because, guess what, they probably don’t know, either

And it’s easy to dismiss such debate by saying “he’s got a chip on his shoulder”, but I think you underestimate just how sick and tired programmers really are of all this BS. And I’m speaking as someone who’s “managed” teams, been a BA, and an “enterprise architect” (whatever that means). It’s all 100%-pure magic fairy dust that businesses sprinkle on their projects. It’s magic beans we get in exchange for addressing the real problems.

If our programmers know what they’re doing, we don’t need them. And if they don’t know what they’re doing, we’re stuffed anyway. Short of a miracle, bad programmers will do a bad job.

Getting the business/customer and a developer talking the same language to explain and understand a real world problem that isn’t working in a piece of software isn’t easy. A good BA or ‘middleman’ who has a foot in each camp and understand the language of both can help.

Agreed, a poor BA or manager just gets in the way. But then a poor developer writes rubbish code.

Thanks for your post. A few observations.

“NOBODY develops software using Scrum”
Agreed. I toyed with “Developers in a scrum team should be cutting code – period” but it didn’t sound right.

“Developers MUST understand the problems they’ve been tasked with solving”
Once again, I’m with you on this and the place to ensure that the developers have this understanding is in sprint planning. But it’s rarely the case that the person/people who have that understanding (usually the person/people who asked for the feature) are available for sprint planning. The solution to that is to ship a developer off to every customer that has a feature on the PBL to elicit/gain the understanding that is required to develop the feature. Doesn’t that make them just as “bad” as BAs? If that developer doesn’t develop the feature but just passes his understanding on to another developer, all we’ve got is a developer as the middle man, not a BA.

“Again, I suggest that managers and analysts are hired because of perceived shortcomings in programmers or their customers that neither can address in any meaningful way”
Sounds to me awfully like a small cuboid of cut potato is resting somewhere near the top of your scapula. Managers and analysts are hired, very often on lower wages than highly skilled programmers, because good, skilled developers are a scarce resource and when you get a good one, you want him/her writing code. Perhaps if you began to perceive managers/BAs as resources that are there for you to use, you wouldn’t feel like this. That has certainly been the nature of the (very sucessful) relationships that have existed in teams that I have worked with in the past.

“the whole ‘hyperproductivity’ thing” & “management gets in the way”

If you’re a truly skilled manager, the team doesn’t feel like, or even know it’s being “managed”

Firstly, NOBODY develops software using Scrum. Scrum has got nothing to do with software development. It’s a very simple set of practices for managing projects. It takes 10 minutes to understand it and a day or two to master. That is why it’s so popular with managers

Secondly, it’s erroneous to suggest that understanding a problem and then coming up with a solution is “context switching”. Many of our woes begin and end with the fallacy of paying one set of people to analyse the business problem and another to design and implement a solution to that problem. That’s like having one student read the questions and another write the answers in an exam. Developers MUST understand the problems they’ve been tasked with solving. It’s inescapable. Putting a middle-man in between them and the customer is both unhelpful, and in many cases obstructive.

If you are no good at understanding the problem, your solution will not work. Programmers who can’t get their heads around the requirements and the business are not good programmers. Hiring someone specifically to understand it for them is dysfunctional, because the person writing the code cannot do so without that understanding.

Again, I suggest that managers and analysts are hired because of perceived shortcomings in programmers or their customers that neither can address in any meaningful way. Managers are like comments in your code. You shouldn’t need them. If you think you need them, take another good look at your code and ask yourself “what doesn’t make sense?”

I’ve worked on enough projects now to know de facto that when analysts and managers are brought in to productive teams, things get worse. Things would have had to have been pretty bad for them to get better.

And the whole “hyperproductivity” thing? If this ever does happen it is 100% down to the people actually doing the work. How they’re managed is only a factor when management gets in the way. So the best thing a manager can do to make their team more productive is stay out of the way

The “Flow” thing was originally proposed by Csíkszentmihályi. I found a reference to it here. Thanks for mentioning it, it’s a perfect description for that state of mind.

I can’t find a reference to it at the moment, but I remember watching a documentry on the BBC by Robert Winston about how people get into a ‘flow’ when they are working, once in a ‘flow’ productivity goes through the roof. To get in a ‘flow’ you need to be able to concentrate on one thing and not be distracted or interupted which is hard if you are wearing too many hats on a project.

I have devised a very effective technique to make sure that
1) People are fully aware that I am coding and don’t want to be disturbed
2) I am insulated from the outside and I can get into a flow

What is it? The biggest pair of noise cancelling Sennhesier headphones I could find.

(me at CharityHack 09 with my headphones (and Lee Mallon) allowing me to get into a flow and create an app for charity in 24hours)