One of the problems I have found when adopting an agile approach to developing systems (and I mean truly agile, according to the agilemanifesto.org rules, rather than a particular project management methodology), is that the high level of end user interaction in the development process can sometimes lead to the users, in effect, designing the systems. They often come with an idea for a technical solution to their problem and ask us developers to build that, rather than allowing analysts to design the solution.
I often use the analogy of a visit to the doctor’s surgery to illustrate this.
In recent times the old role of systems analyst or analyst/developer seems to have evolved into two separate roles – the business analyst (often with little or no programming skills or experience) and the software developer. In our doctor’s surgery analogy, the roles of user, business analyst and software developer are fulfilled by the patient, doctor and pharmacist.
It is the doctor’s role to investigate the symptoms, diagnose the problem and come up with a treatment plan, which they agree with the patient. It is then the role of the pharmacist to provide that treatment.
In software development projects, it is frequently the case that the patient (user) walks into the surgery with their own treatment plan in mind. They enter the room and ask for penicillin. It is too often, in my experience, that the doctor (analyst) then simply writes out a prescription for penicillin and hands that over to the pharmacist (developer).
Imagine the case, where the pharmacist spots a problem with the treatment plan (say the patient has a virus), doesn’t think it is wise, and says to the doctor, “I don’t think this is right”, only for the doctor to respond with: “That’s what the patient asked for, give it to them”.
I’ve seen this story play out in many a troubled software project!
Even worse, I’ve often seen the equivalent of the doctor simply leaving blank prescriptions at reception for patients to fill in themselves and hand to the pharmacist!
The business analyst role is not simply to liaise between users and developers (I’ve known business analysts whose time was mostly taken up being an email relay, or a chinese whisperer!). They need to be looking at the business needs behind any request and designing a solution that fits with any current systems that are in place, before bringing that to a developer.
In addition, it’s rare that an analyst with no technical or programming experience will have the ability to know the full extent of what a software system can achieve, or design solutions that fit into existing systems well.
Maybe it’s time to bring back the combined role of analyst/developer.
