Let's look at QA!

A personal note: I've formally left my BA position and am transitioning to a Project Manager role (PM) in another group at the bank I work in. Not to fear though. As a PM, I will have oversight of all the activities going on, including BA, QA and development.

I've been thinking about quality for the last few weeks and I've realized that we really aren't doing a good job at QA. At least on the first few tries! We release software that is riddled with bugs, that have data integrity issues and crash as soon as the user tries something new.

First of all, where I am, QA is given short-shrift. We don't think of them till the very end. They're out of the loop for the most part and then are brought into Mission Impossible: Make sure this application is ready to go in 3 days!

The thing they say about quality is true: You never have enough time to do it right, but you always have enough time to do it again!

How do we ensure quality? or more realistically, how do we aim for as high quality as we can get? Quality is elusive. Heck, Pirsig wrote a whole book on it (Zen & the Art of Motorcycle Maintenance).

Well, I'm no quality expert but I have learned a few things in the last few months.

1. You need to have a separation of concerns. The team pushing out the software (BAs, PMs, Devs) should not be responsible for Quality. You need a Congress to push back on the President. The mindset for driving out and releasing software is at odds with ensuring quality. I've signed off on software to be released just so I could get it out there only to find that there was a crash a day later. My goal as a BA is to satisfy the user and to get the software out, not to find fault and hold it up. As long as the former is my motivation, I cannot do an adequate job of QA'ing anything.
2. We need to have some sort of up-to-date specification to hand off to QA. I've been a cowboy for the last year or so, BA'ing by the seat of my pants, embracing agile, and iterative development. Which really translates to: No writing any specification documents. I would instead create prototypes, mockups, write up notes in Excel and have plenty of phone conversations and netmeetings with my team. This was swell and we produced some good results which were very close to the mark to what I required. However, QA suffered. The way I handled QA was to also do the netmeetings, and do demos and such and then let them play with the software. QA could write up their own test-cases based on what I showed them. Voila! No spec needed. After all development created the software without a spec either. However, and here's the kicker: I realize now that I only show QA what *I* think is important. I demo features that I think should be tested, so when they go away, they concentrate on that. Of course it's the features that I don't show them (because I don't think they're important to demo) that wind up being used by the user and then fail! It's really remarkable (and arrogant of me) to think that I know what QA should do. Again, as a BA or anyone looking to driving software into the marketplace I am severely hampered by this same motivation from ensuring as high a level of quality as the software (& user) deserve. So which translates to: have a spec ready that highlights what the software does and let QA work off that, not what I show them. Guess specification documents are a *good* thing! :)

What led me to posting this about QA was some recent experiences (or failures) with our tools. I did an analysis and here's what I've come up with.

1) Bug because of a hidden feature that wasn't tested.
Occurred because (1) I didn't demo that feature to QA (see point #2 above!), so QA never even knew to look for it or that it existed, (2) test cases from v1 of the tool were not reviewed and used for v2; the test-cases may have had this hidden-feature; in essence, no Regression-testing! and (3) there was no written spec given to QA which would have had this feature detailed.

2) Bug because a common case was not tested.
Occurred because again (1) I didn't demo this to QA or stress it at all as a point to be tested. They saw what I showed them and mimicked it. (2) Test cases from v1 not reviewed and used.

There were a few other things that contributed to the breakdown:

• Inadequate training of QA; a junior QA person with not much experience signed off on the project.
• QA not brought in early enough to the specification phase of the project
• QA spec/test cases should be developed ahead of time and be prepared/reviewed. QA needs to have this as a mandatory deliverable. Even if they are brought in dead-last in a project, their efforts should result in a test-case deliverable that can be re-used for the next go-around.

So in summary, here are some essentials:

• Always get QA to hand over a test-case or QA deliverable that can be re-used or handed over in case resources get shifted (QA seems to be get 're-deployed' more than any other group these days)
• Use above deliverable as basis for modifications and to use for regression-testing in major releases
• BAs need to write a spec specifying what the system does as a deliverable to QA (and to developers, although in my instance, I don't seem to have all that much trouble getting development to deliver what I want since we're both aligned towards the same goals) so they can poke holes and create their deliverable.

QA will either use your spec (or any other documents, literature, conversations, screenshots, etc) or if brought in really late, will use the actual working software itself to create test-cases. This deliverable is vitally important. (Implementation-wise, if QA keeps it in a doc or in a tool like Quality Center, it is irrelevant)

A PM's utility

Warning: This post is really an experimental one; just playing with some thoughts about the PM function. Not my intention to offend but the question is:

So how useful are PMs (Project Managers just in case you didn't know)?

Frankly I'm not very sure!

Of course it depends on the project. Not every project needs a BA or PM.

Everyone on a team should be thoroughly invested in 'caring' about the product, not just task-mastering so that things get done. PM activities are essential actually. But is a separate PM truly necessary? I think the best approach is to either hire BAs with PM experience or Developmental Leads with PM experience. That way PM tasks are kept to a minimum but also reside with personnel who are invested in the product.

In Six Sigma terms, the most useful ppl to have on a project are those who are adding value to the product.

A BA talks to the business and therefore represents and speaks for the business to the dev team. The BA represents the business so s/he wants to ensure a quality product.

The developers are developing the product and so will put care and precision into crafting something of quality.

In my own (and certainly limited experience) PMs engage in many not-required non-value-add activities. Is the customer willing to pay for communication or chasing down people to get tasks done? These are overhead tasks that are necessary but also don't add value. In six-sigma terms, these are NVA, non-value add activities and should be minimized. Hence, my call to eliminate the PM position in areas where you are able and to place only the least amount of PM activity with other members of the team who also engage in value add activities.

Let's look at wikipedia's definition of the activities a PM engages in:

1. Analysis & design of objectives and events
   
2. Planning the work according to the objectives
   
3. Assessing and controlling risk (or Risk Management)
4. Estimating resources
5. Allocation of resources
6. Organizing the work
7. Acquiring human and material resources
8. Assigning tasks
   
9. Directing activities
   
10. Controlling project execution
    
11. Tracking and reporting progress (Management information system)
12. Analyzing the results based on the facts achieved
13. Defining the products of the project
14. Forecasting future trends in the project
15. Quality Management
16. Issues management
17. Issue solving
18. Defect prevention
19. Identifying, managing & controlling changes
20. Project closure (and project debrief)
21. Communicating to stakeholders
22. Increasing/ decreasing a company's workers ...
    

In particular contexts, these activities make sense and in others they don't. If you're running an agile or lean software development project then a lot of these can be eliminated entirely and others can be offloaded to other personnel.

The gist of this post is to just get you thinking on the type of projects you're running and not to blindly throw a PM, BA, Dev Lead team together and expect to get the job done. You could be slowing the project down actually. The BA and Dev Team could run with the project a whole lot quicker than with a PM overseeing everything trying to get updates.

In my environment, what seems to truly work is:
1) Hire BAs who are comfortable with and can talk to both the business & development on an everyday basis.
2) Hire BAs with PM knowledge
3) Hire Dev leads with PM knowledge

Lean Sigma Thoughts

I've recently been going through some training on the Lean Sigma methodology. It's all about Process Improvement and it employs the DMAIC (or DMAEC) steps: Define, Methodology, Analyze, Implement (or Engineer) and finally Control.

It's a very sequential model (not unlike a waterfall software life cycle methodology) with tollgates at each step. It's pretty interesting and I'm learning a lot of academic material. I'm doing my Green-belt training and I am using the textbook material on an actual project that is causing my boss pain. However, as I've been digging into the project, I've discovered that a lot of the steps were carried out 2 years ago on much the same pain points. In fact, there are reams of documentation all the way to the Engineer Phase. The solution was never implemented however. Now there's a big project underway (of which I'm working on a very small chunk) that is looking at the same issues again. So my question is: why? Why will the result be different from last time? Why wasn't the last solution that was brought to the table 2 years ago not carried out?
Heck, we can do a Lean Sigma project on this question alone!

And furthermore as I was digging into the items, I started getting innovative ideas. What if we could do this or that? and implement it with a small group? If it worked, we could spread it to the other groups. And then it hit me. The Lean Sigma process to some extent is devoid of innovation! That flash of inspiration; that 'hmm, what if we tried this?' is somehow lost along the way. A practitioner can so concentrate on each one of the steps at a time that s/he never sees the issues holistically. The emphasis on only defining a problem or measuring or analyzing precludes the 'what-if-we-did-this?' The problem is engineered to death.

In this project I'm on, the solutions proposed from the last go around made sense. I have a feeling that the stakeholders involved were change-averse to implement some of the bigger changes and didn't want to rock the boat. I also feel that our Lean Sigma group is seen as 'outsiders' or consultants who come in, do their thing, drop you the results and leave. Their stuff is good but they're done and they're off to the next thing. Stakeholders might like the analysis and agree with some of the solutions but they take a risk when implementing. If the proposed solutions don't work out in the stakeholder's favor, the project manager is left holding the bag. When Lean Sigma or management consultants leave, the project manager (who may have contributed to the development of the project) is not invested in the solution, so will be less likely to implement it (at least from the e.g. I've seen).

Again, on this particular project, I saw comments from one of the stakeholders who more or less shot the proposed solution in the foot. The Powerpoint slides depicting the proposed changes were passed around and then the stakeholder fwded the slides to his managers with many more criticisms rather than favorable remarks. It's no wonder the project stalled. What top level manager would give the go-ahead if their employees thought there were unresolved issues?
Questions:
1) Why wasn't the solution developed jointly with the stakeholders?
2) Was there a chance to rectify/address some of the concerns of this particular stakeholder?

There've been tons of issues with this particular product line; everyone agrees it is broken; The product line manager is definitely risk-averse and doesn't want to do anything drastic.

A BA should act as PM (sometimes)

In our environment, in order to maintain quality of the project and make sure communication is flowing to the right people, the BA needs to step forward and own the PM space. Doing the requirements piece is essential and is a first step; the information then needs to flow downstream to all the other parties in IT. The BA is at the forefront of this endeavor. If the BA stops there and expects the PM to take care of the flow of communication, the project more than likely will come to a grinding halt; either that or it will start to flounder. The BA should either work hand-in-hand with a PM who does take ownership and is vitally interested in delivery of the project OR the BA should own this piece as well and ensure that the right people are playing their parts & on time; thus the BA is acting as PM.

The benefit of having a BA act as PM on his/her own project is that since the BA is present at the inception of the project, s/he has interacted with end-users and felt their pain, needs, requirements, etc. from a first hand basis. This makes the BA a representative of the business and the BA can really strive for what is important. The BA playing a PM role can stress the right areas to focus on in the short-term and push off the less important items. A separate, detached PM may not take these things into account, especially if s/he is not as invested in the project. In fact, having a PM involved at the outset may be too much overhead.

The beginning of the project is very vital. A BA/PM can push for a working first iteration of the software that does the most important things first; the initial software will have limited functionality and the BA/PM can even act as an initial QA resource, vetting the design and construction of the software as it progresses by doing quick checks of functionality; and in order to make sure the software is aligned with the original vision. The BA in fact is in a most unique position, especially at the beginning of a software project, because s/he can play those 3 roles: BA/PM/QA and the reason should be blazingly clear; The BA is the one who feels the client's pain and will do his/her damnedest to make sure that the client is being given what they need (if you're a conscientious BA that is)

As the project progresses, matures and gets more intricate, there will have been some momentum built and other dedicated resources can be brought in to handle specific areas of the project: a dedicated PM, junior BAs, dedicated QA, etc.

Get Developers thinking in terms of Features EARLY

Developers aren't used to thinking in features at the beginning of projects. They are usually so engrossed in the details that they immediately start thinking of the tasks they need to do in order to build a piece of software.

Show them a mockup of a screen, give them sample data and whatever else they need, and developers will immediately list their tasks:
1) Create database schema
2) Normalize schema
3) Create middleware
4) Create screen

etc.

The problem is that users and BAs (and everyone else who rolls onto a project after it's started) talk in terms of features. There is a fundamental communication problem.

So how do you effect this transition of language that developers speak from tasks -> features?

As a BA, specify to the developers that you want a first round iteration of software that does the bare-bones. Pick the 2 or 3 important pieces of functionality; intentionally limit the scope and let 'er rip! If developers come back with something they feel is too complicated or unknown, defer it. The BA should be able to specify EVERYTHING in the first iteration. There should be no loose ends. This allows the developers to go away and code; if they have questions, the BA can answer them and if need be, further limit the scope.

Now, let's say the developers have done their part and delivered a working piece of software for the first iteration. If the BA gets a few people (including people who may not even be on the project) to put their eyes on the software along with the developers who created the software, those people will give a tremendous amount of feedback.

But these people (who may or may not be developers themselves) will naturally start talking about what the software lacks or needs more of or could be better, etc. They'll be speaking in terms of FEATURES! The developers who hear this then start to think in terms of features.

The cool thing about having a working piece of software is that once it works, there is tremendous incentive to keep it working! If developers implement something that breaks the software, they'll back up and fix it! Once you have running software, you're not thinking in terms of tasks to get the software up and running. Now you're thinking of what new features you can add! This allows IT to organically grow the software to fit user needs; and not to create something big, ugly & over-complicated that was never needed in the first place. This can easily happen when you're in 'design' mode and thinking in terms of tasks.

Once the developers start thinking in terms of features, then they'll think about the tasks they need to get it done on their own. But now the channel has been crossed; BAs, PMs and Developers can start talking in the same language: in terms of features. The sooner this transition happens the better. What's required is getting that first working iteration out the door.

As well, talking via 'features' makes everyone naturally more delivery-focused. Features add value and customers are able to naturally relate to that; they'll instantly understand what you're talking about.

IT is the problem!

What has slowly revealed itself over the last few weeks is pretty insane! But I had a glimmer of insight a little while ago which gnawed at me and I'm fairly certain that this is the central issue: that IT is the source of our own woes.

Much as we would like to (and actually do!) blame our customers and clients, IT is the guilty party. Certain refrains can be constantly heard:
"They don't know what they want!"
"Why can't they make up their minds?"
"They're asking for the impossible!"
and on and on.

Frankly, in my experience, when talking to the business, I can pretty much be open/honest about what can/can't be done & how long it's going to take. I mean these guys don't know IT and a lot of them don't pretend to. They really have to go by what you say. So unless you're just plain intimidated by the business (and a lot of IT ppl ARE) in which case you'll overpromise stuff, the business will take you at your word and get on with their lives. After all, they have more important things to do like make $$. It's our fear or overeagerness to please that gets us in trouble here.

But even more than that, recent experience has shown me that I as a BA am actually afraid of my development team! I've been nervous changing requirements on them because I fear they'll get angry or lash out and give me those above retorts (in other words, treat me as if I'm the business, although I actually AM playing that role; but the difference is they'll say it to my face). Sure, I can pass the buck to the business, but as the BA, I am smart enough to know how requirements gathering works. It's done iteratively; no customer knows what they want right off the bat. Everything in the beginning is an approximation. However, dev teams think it's written in stone and proceed that way. Then when the BA comes back with more detailed/refined info or changes the plan, the grumbling begins.

What's needed is for IT to be patient; to realize that they shouldn't put much work in the beginning of a project in terms of development, and that things can change. If the initial plans are vague, then build a fuzzy prototype that does the bare minimum. but above all, EXPECT CHANGE. Because if you expect it, then you're prepared for it. If you're prepared for it, then well, there's nothing to complain about when it actually happens. I am working with an off-site dev team now and I said from the get-go that the project is going to be iterative and that we'll need to do several versions. Well, whaddaya know? We got some more stakeholders involved and they requested their own changes. So back to the drawing board! But this is great, because everyone's voice is heard & we have more information as a result of the 1st iteration as well.

BA Skillset

Here are some skillsets and basic tools that I feel a BA should have:

• MS Office Suite
• Word
• Powerpoint
• Excel
• Access

Word & Powerpoint are no-brainers. Excel also; but more than a passing familiarity with Excel is a good thing. Knowing how to chart, use pivot tables, sort, filter, and even do some VBA are all exceedingly good things to know.

Learning Access is one of those things that can put you over the top. You can quickly create solutions for small groups of people and do a bang-up job. There're lots of instances where a simple Access database can do the trick but many BAs don't have the skillset to address them. Instead the project become overblown and a 3 tier solution with an Oracle DB and a middle tier and a web front-end are devised. This takes too long, is too expensive and more likely than not, you'll have to wait for resources to be freed up.

Training your users to use an Access Database is also probably a good thing to do. Lots of spreadsheet users invariably complicate their spreadsheets with tons of tables and VLookups, whereas a simple join in Access would do the trick.

Another useful thing with Access is if you do lots of data analysis. Comparing reams of data and figures on multiple Excel spreadsheets can get quite laborious and tedious. If you dump each of the sheets into their own tables in Access and do joins you can quickly find which ones match and which ones don't for example. Access (or knowledge of some database) is a must for the serious BA.

Other skills:

• SQL
• Communication/Writing Skills
• A strong desire to play with & learn new software; being a software evangelist
• An ability to filter out extraneous information and to focus on the details that drive a project forward rather than getting bogged down with too much detail: There's a time & place for everything. Sometimes getting all the information up-front is not such a good thing (your head probably won't be able to process it :)
• An inquisitive nature to find out what people do & why they do it. As a BA, you need to help automate things for your customer so you need to drill into all the particular details of what they do, what actions to take when certain events occur, when they do it, how they do it, how they know when to do it, etc. Getting the whole picture will eventually reveal the grand scheme and then you will be able to propose a solution.

A balance b/w taking into account the customer's concerns vs. ability to drive a solution forward is quite key: Let's face it. If you were to build a solution that took into account EVERYTHING, you would be in a quagmire. Automating error handling for every instance of something going wrong can be fruitless. Some things should just be manually handled. A lot of people, both BAs and customers get caught up in thought exercises and intellectual games following all kinds of paths to come up with some grand solution. Implementing something like this and then debugging it can be a nightmare. Remember that you need to not just satisfy your clients but your dev & qa teams should be considered as well. If your solution solves 80% of the customer's problems, then you should strongly consider pushing that forward. The rest can be 'phase 2-ed'. When I use this phrase, it allows the customer to relax knowing we can deliver something quick in phase 1 that'll handle most cases and then we'll handle the rest later. But you know what? Many times Phase 2 never even happens because Phase 1 is completely adequate!

Strategy(ies)

Some cool things to try:1) Ask employees for initiatives that have worked, that have not worked, what they've tried that they think will work well across the organization. That way, management would get ideas people have tried in their own units that have worked well and that should probably be evangelized across the organization.

2) Prototyping and front-end development responsibilities should be kept in the high cost center arenas. Integration with the back-end should be done in the high cost center. [See my previous posts for this subject beaten to death].

3) There seems to be a running theme in many of these applications we create at the investment bank. Take someone's spreadsheet and turn it into an application. Front-office users are adept at Excel apparently. Here's the progression:

1. They create the spreadsheet, start really using it, and get dependent on it.
   
2. They start mailing the spreadsheets all around.
   
3. They wind up with multiple copies all over the place and they get out of sync.
4. Then they ask IT for help...
   
5. IT comes to the rescue with a solution with 3 tiers and 6-12 months development time.

We should start looking at other solutions. If we keep following this procedure, IT is reduced to not adding any real value; we're placed in the position of playing constant catch-up. And IT is not really innovating or doing anything kewl.

Instead why don't we:
1) Train business users to use IT more wisely. There are a myriad of technologies out there. When I stop by a business user's desk, the same things strike me each time: how few applications they have installed on their box and how non-facile they are at using applications. As part of their on-boarding, they should be indoctrinated into the tech tools that are available to them; for instance, an introduction to using Sharepoint technologies; If they use an online-spreadsheet in the first place, IT might never have to build them an application at all. And even if they needed something extraordinary, we could build them a Sharepoint component to help them, for example vs. building them a whole new app. Hell, even use something like Google docs!

2) IT should get away from the mindset of creating applications from scratch. In this world of plug-n-play, we should be leveraging other solutions. That means hiring people who like to play with new technologies, with vendor products, experiment, attach the output of one product as the input to another product and integrate them, etc. We should be coding only when we HAVE to. Even the idea of taking code from one application and using it in another is often far-fetched. In reality, ripping this stuff out and using it elsewhere doesn't work so well in practice. And you usually need the guy who developed it in the first place to stick around. If he's not, good luck!

Get IT to play with experimental technologies and to prototype with them [I'm thinking of using frameworks to prototype quickly: Rails, django, adobe flex, etc].

A BA should be a RAD developer. Not!

Ok, so I started hacking up some HTML using our corporate branding standards and the free snippets we have. While it was cool and easy for me to just drag a snippet into Dreamweaver and have it appear on the page without any work, there's a lot of customization involved to get it to look exactly the way I want. I just don't know enough HTML to start playing with divs, tables, spans, colwidths, etc. and putting various elements exactly where I need them, nor do I have the inclination. We really do need a full-time expert on this kind of job! It was a good exercise for me to try in any case. I now am familiar with the space, know what kind of expertise is required, how to set up other people to do the same thing, and I know enough to make a case for bringing this kind of expertise into our firm.

My philosophy is: talk is cheap; only by doing do you really know [and what I mean by know is knowing by your gut]. You just gotta experiment and try different things and see what works.

Can't commoditize the "experience"

Here's something that I find interesting.

We've long ago commoditized many kinds of products. Services have been the next to go. We have BPOs happening in India, outsourcing of all kinds to many different types of firms all over the world. Some of it is good, some bad, but they're getting better. The next step up from services some say is the experience. Starbucks may not have been the ones to pioneer this, but they certainly have made it a household word. Starbucks just doesn't give you coffee (a product), or give you mere service; they've transcended into the world of experience.

So what's the point I'm making? Well, if services are becoming commoditized (and many of us are busy still making sure that goes OK), then experiences, which is next down the list, still need to remain close to the customer. We can't outsource the experience. I don't even know what that means or what it would look like! So applying this to software, we have U/X engineers: U/X = User Experience Engineers. Since the GUI is what the user sees as the entire application (users are blissfully unaware of all the middle tier and back-end stuff), we need to ensure their experience with the software is a positive one, not a traumatic one. We also need to show them that we are responsive to their needs. Thus the user experience is something we dare not commoditize and ship overseas. We need to keep this one close to our chests.

A BA should be a RAD developer. Maybe Not!

So I've had some more thoughts along these lines.

After delving into the world of Dreamweaver and XHTML, CSS & Javascript [we'll see about AJAX], and talking to a real good front-end developer and senior BA, I've come to realize that my assertion about BAs becoming RAD developers is probably far-fetched. I was eager to learn it and with a bit of training and getting up to speed, I could probably create some workable pages (which I'm in the process of doing).

But I saw after my interactions with these guys that the front-end development I was thinking about is probably going to require someone devoted entirely to that task: a full-time HTML or ASP.Net front-end developer. There are just too many details that would need attending to. This is really a developer task. While I might be able to deliver workable pages (something perhaps good enough to show my users) they probably would be hacked and not very tightly coded; definitely not worthy of production. And I personally wouldn't want to go that route. My interests aren't in developing HTML pages.

So my thoughts have changed. I would say that having a BA along with a front-end developer at the high-cost centers (read: NY, London, anywhere that's close to the user) should be the new paradigm. The front-end IS the application from the user's point of view. If we get that right, everything else follows. But we need to get that right. We need customer involvement in getting there.

So if a BA and a front-end person meet with customers or users and are able to rapidly turn around the requirements into a working, clickable prototype, GREAT! You could have them iterate as much as they need to get it right. And then the front-end developer could deliver working XHTML code to the back-end developers. You can also start utilizing the front-end developer on other projects if the back-end people take a bit longer to deliver their pieces (or maybe not, depending on the methodology you're using: waterfall vs. XP for e.g.).

The main point here is that having a front-end developer to carry out RAD very close to the customer is the item that will start to foster good relationships between IT and business. The business will see that IT is more responsive because IT is able to come back in a few days with improvements in the interface that were requested. BAs will have more definitive answers and be more confident about what they're asking developers to do. And the RAD developer can deliver production-ready front-end code that back-end developers normally want nothing to do with. This is a win-win situation!

In our particular environment, we have branding guidelines we need to adhere to. The branding department has provided us with a framework of html and css (both with and without Javascript) as well as various code snippets. The front-end developer doesn't need to start up from scratch on each project. This makes high-fidelity prototyping or RAD more within reach than ever before.

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.