Case in Point

When I was a programmer/systems analyst in my first job, we didn’t have any BAs, so I was responsible for gathering requirements and developing the software, working directly with the SMEs. In a later position, my project team included BAs who interfaced with the SMEs for the programmers. I quickly discovered that I didn’t like working with a go-between. I wanted to know what the business people were doing, why they wanted the software, and I wanted to see them use it at the end. My frustration in working through a BA is what led me to become one!

Do the developers have special training/certifications? Were they trained internally or before they joined the enterprise? Have they been working in this organization for a number of years or are they relatively new? Turnover in the IT industry can be very high. BAs must become very adept at building relationships with IT people wherever and whoever they are. To successfully work with the technical architects and developers, a BA must be able to communicate with them in the context of their environment.

When you are getting to know the developers, there are several things which will be useful for you to learn:

• Is the developer an organized worker? Does he or she keep a to-do list or rely on memory? Does he or she approach tasks in a sequential order or more randomly?

• Is the developer creative? When given a requirement, does the developer build as is requested or loosely use the requirements to build something that is clever, graphically aesthetic, or overly complex?

• Does the developer readily turn over his or her work, or does he or she postpone showing it to anyone while testing it, making sure that it is completely done? (In other words, does the developer test his or her own work? Is the developer a competent tester or only test cases that he or she knows will work?)

• Is the developer interested in understanding the business needs and user preferences? Does he or she ask detailed questions about business rules and then listen carefully and develop code that supports those rules?

• Is the developer familiar with the analysis techniques and presentation formats included in your requirements documents?

Understanding how a developer works best will help you decide appropriate requirements deliverables and communication approaches. One of the attractive aspects of the agile approaches to software development (see Chapter 5) is the myth of no requirements. Because many developers don’t like to read or follow written requirements, they are drawn to the idea that they won’t have to deal with documents. In reality, an agile project has just as many requirements as any other project. The requirements may be given to the developer verbally, but they still must be implemented. They are given to developers in small chunks, which works well for developers who are not used to working off of a to-do list. Providing one requirement at time with a tight deadline keeps the developer focused and discourages creativity.