The Vanguard

Giving Props to the Business Analysts
I am taking a slight change in direction and will be reviewing a recent class I took. I'm fortunate to be working for a company that is willing to invest some funding into developing its people. I attended a Business Analyst Boot Camp offered by ASPE Technology. To preface that, this entry is to pay some respects to the business analyst (BA) world and explain why I feel developers can benefit from learning BA skills.

In the class, I received exposure to several aspects of business analyst work. I've been primarily a developer most of my professional life, but I will give my first employer, EDS, some credit for trying to teach us budding systems engineers BA skills. I've since worked with several companies and many different BAs. BAs are like developers: there are many out there, but only a minorty are outstanding. And when you find a good one, he or she is worth keeping.

At the Starting Blocks
Business analysis is where it all starts when it comes to a software application. It's the tip of the sword and while good work at this stage can be compromised by deficiencies in development, testing, and change management issues, bad work here will almost certainly lead to problems in the overall effort. Only the presence of experienced developers and project managers might be able to still guide such a project to a successful end, and they would do this by willfully partaking of some of the BA duties. In fact, this has happened on many of my past projects and it was when the developer was willing to hash out the business issues and processes rather than make assumptions that downstream pitfalls were avoided.

That leads me to describe my past experience with BAs. Some had decent domain knowledge and were good communicators and had helpful attitudes. Some even had technical skills and that could be a boon. But I've worked with more than my share of people that probably shouldn't have been in IT, much less BAs. I've met a few that simply were non-factors; they didn't participate, they didn't provide timely answers for developer questions, weren't too hot on requirements documentation, didn't get involved in testing or user training, and didn't forge relationships with stakeholders. In effect, if they at least had a helpful attitude, they were glorified secretaries that organized meetings.

That is why I as a developer took this course. The BA skillset includes things like requirements definition, interviewing, conflict resolution, project initiation and elaboration, meeting management, and a whole host of both written and verbal communication skills. All of those things are valuable skills even if you're not formally a BA. A developer, even with the assistance of a good BA, will still have to be able to elicit requirements. There are always going to be missed gaps and unforseen issues, especially on complicated systems. Remember, making software is easy, but making it right is hard. Being able to perform these duties just makes a developer more rounded. In the agile development methodologies, this is even more important because there might not be a BA; the developers and functional owners are co-located and work together in real-time.

Quality is Everybody's Responsibility
Not to belittle a good BA, but most of the BA skills are ones that can be harnessed by anyone that wants to participate in the role (in fairness, I earlier wrote that anyone can become a programmer too). So I took the class because my experience has proven that when a developer is materially involved in the requirements research, it leads to less risk that the software will fail to meet those requirements. This is one of the points that defines software quality.

Some developers would not like this. They would say, "I don't want to document the requirements, I'm a developer." What they really mean is that they'd prefer not to document anything and they would rather just hack away.

For the developers that get outstanding requirements handed to them by either a BA or a developer willing to do BA duties, fine. But at least in the US, conventional wisdom is that code-only developers will become rarer as companies look at offshoring models. And the reality is that most of the time, there isn't a tight requirements document handed over. So, to uphold some measure of quality, good business analysis must be done and it doesn't really matter if it's done by a BA, a project manager, a developer, a functional owner, or a raccoon. If it's done, and done well, it makes a difference. Quality is everybody's responsibility.

In the next entry, I'll write about the class.