A BA should be a RAD developer

I had this idea today and wanted to explore it.

I've been busy reading various books on agility:

• Extreme Programming Explained
• Planning Extreme Programming
• Project Management with Scrum
• Refactoring
• 37signals' book: Getting Real

I've still got to go through:

• Agile principles, patterns, and practices in C#
• Agile project management
• Joel on software

so I've been delving into the literature quite heavily. I've also been looking at Ruby and Ruby on Rails as a development platform.

I have a lot of ideas and concepts swimming around in my head and am still trying to put it all together. But I'll give it a try.

1) It is far more preferable to be a generalist than a specialist. (or to hire a generalist rather than a specialist). Why? Because you want someone who can adapt. An employee who can do only one thing well and refuses to adapt is more trouble than he's worth. You want someone who'll help out the team in whatever capacity is needed. The truth of the matter is that when you begin a new job, your day to day responsibilities may have little in common with what was originally in the job ad. Many of us may grumble about this but the truth is that the boss needs you to do something here and now and it might not be what you originally had in mind. I think this happens most of the time. I personally would want to work with someone who's eager to learn new skills and take on more varied responsibilities, who begins to get the big picture (and getting the big picture may require taking on many different tasks), and who's willing to go the extra mile to get the job done, even if it's not part of their job description. Even better is someone who actually seeks out new challenges and responsibilities; who having done their job to the letter of the job description asks, "What else or more can I do? How can I move us further along?"

A note here about this: This kind of expansion of a person's role can be perceived as threatening to others on the team or organization who are used to a system or workplace that has ascribed rigid roles and titles (most organizations in general!). Indeed, even I've had thoughts or feelings about people who seem to be "acting-up" or "showing off" or "trying to get ahead" which can breed resentment. All I can say here is that change often feels threatening even when it's for the better and the good of the team. It might be worth it to actually get involved and see how you yourself can help and adapt. It's ok to be swept along in someone else's enthusiasm and to contribute and support that person.

It's been pretty well documented that smaller software teams get much more done than larger ones. However, on those smaller software teams, members don't just subscribe to narrow, rigid roles. They wear many hats. This is exactly why a generalist is more valuable than a specialist. So if you want to build good software, make your teams more lean and make sure that the staff on those teams are willing to learn other skills.

This really struck me when I read "Getting Real". 37signals would never hire an IA (Information Architect). That is just too small a role for their team. They need people who can shine in many areas.

2) Let's face it: In a perfect world, a BA is not necessary. The basic components of a transaction are a customer and a supplier (or software developer in this case). If software developers cultivate those soft skills and learn how to communicate in the customer's language, a BA position would be extraneous. They could just do the requirements gathering themselves. This is an extreme example, of course (and that is why Extreme Programming is thus named!). However, with more outsourcing, offshoring and nearshoring, the BA position has come into its own. We do need customer representatives and SMEs that can stand in for the customer. In an investment bank arena, the BA is really the customer. The BA is in fact the customer (or customer advocate) but also represents the development team. He constantly has to wear multiple hats. Of course I still need to go back to my real customers and have what I think are their requirements validated.

In fact, this latest exercise in going to the users was very revealing. I had really developed my wireframes and prototypes very well. I put some nifty features in there that I thought would wow the users. But I go down to show it to them only to get "uh huh." or "I guess that would be nice". Not the overwhelming compliments I thought they would bestow. What does that tell me? A lot! It tells me that we can design all the coolest, niftiest features in the world, but if the user doesn't care for it, it's a waste of time. It would be great if my piece of software does everything possible with every data set but is it necessary? I realized it's very easy to get ahead of myself and over-design but without real user input to validate, it might amount to nada. That's why it's important not to design too far ahead of development. The waterfall method of stacking up a bunch of requirements months in front of development is not recommended!

3) In my current project, I'm pretty much at the point that development can start. I've got all the keys questions answered. I have wireframes. I've built a prototype using a tool, etc. Now all I need are development resources. Unfortunately the resources are busy working on something else for the next 2 or 3 months! Aaargh. One of the things I was afraid of was going to the user with wireframes, getting them excited about what we were going to do for them only to find out we can't deliver. Not a good way to build relationships.

So I'm idle and started thinking about what I could do. I'm not a fan of the functional spec document which is what traditionally would be written at this stage. However, there's no rush since there's no development team to do anything with it. I would rather do something more useful. I've started the foray into Dreamweaver and XHTML and CSS in an attempt to bring my mockups to life. Our company has code snippets for much of our internal branding standards so I should be able to design my application using those snippets. The end product could then be delivered to the developers who would not need to spend any time doing gui work. I think this would be a huge win and streamline the process. In fact, this is also a great idea for outsourcing as well.

Why not take this one step further? If Ruby on Rails really is that awesome that I can create a blogging site in 56 lines of code, why not use it to create an app for my users? Let 'em have a go at it and get the ultimate feedback! Forget the functional spec. I can hand my development team a working application AND I'll be around to answer their questions. What can be better?

This is exactly why I titled my post "A BA should be a RAD developer". It was tempting for me to sit back on my heels and do nothing, after having spec'd out my first release. But I asked myself, "Where else can I play a role? fill a need or gap?" And being a developer occurred to me. If I could get a html site up, my users would have something to play with and give me even better feedback!

So a Business Analyst's main role is to get the requirements right. The real, surefire way of doing that is getting the users an actual application to play with. Doing that quickly especially if you work in a non-agile environment is of paramount importance, especially if your culture is (as it is where I work) that IT takes forever to get things done.

I'm also looking at this method as a way of spurring management into being more forward thinking about adopting agile. If I can wow my users with useful applications and have them email me and cc my managers about how exciting it was to see the application, I'm betting that Senior IT managers will jump and want to deliver those projects.