Why does DAD not have an explicit role for an Analyst? This is a hot topic for those in this profession, and a subject that I have been asked to talk on, notably for the IIBA. Without question classically trained analysts bring much needed soft skills and a structured approach to requirements elicitation and negotiation which may not be present in the other roles such as a product owner or a developer. However, having these skills alone is not enough in an agile and lean world.
Unfortunately, professional organizations such as the Project Management Institute (PMI) and the International Institute of Business Analysts (IIBA) tend to encourage us to seek specialization and certifications over being cross-functional team members, which will be far more effective and valuable in the future. This is not to say that these organizations do not deliver value in developing and maintaining standards of professional conduct and capability. Attaining certifications (that require some degree of commitment and experience beyond a 2-day workshop) demonstrate commitment to a professional specialty. This is admirable but I would suggest that this base of knowledge is just the start of being an effective team member on an agile project. We should look outside our area of specialty to learn all we can about other aspects of software development.
It is my belief that in the near future, analysts will need to be competent testers if they intend to prosper in their profession. An increasingly important skill is the ability to write requirements as executable tests. My advice to analysts is to learn as much as you can about agile testing and seek opportunities to write your requirements as tests wherever possible.
For Business Analysts that are not interested in moving more toward the testing end of the spectrum there is another way to go. Analysts can be good Product Owners, representing the customer on the project and by managing the scope and priorities. In this role they can use their elicitation and facilitation skills to gain a clear understanding of what the customer needs (vs. wants).
Another potential career path is for the BA to move more into the area of traditional management consulting. The IIBA is positioning the Business Analyst profession to be more strategic, identifying the need to have them present at the management table when key decisions are made regarding how the business and its architecture should evolve. Our book on Disciplined Agile Delivery is about agile software development. But not all business issues are solved by software. Often it is the business process that needs to be fixed, and this is where traditional Business Analysis skills will always be needed.
In my opinion, one career path for analysts is going the way of the dinosaur though. And unfortunately this career path is often the status quo. Traditional projects expect Business Analysts to document business processes and requirements in batch up-front in a linear, waterfall fashion. They then must obtain sign-offs before actually proceeding with implementing any of the requirements. Subsequent changes to those requirements are discouraged, unless through a formal, time consuming and wasteful Change Request process. This model clearly is flawed, and eventually most companies will change their approach. High ceremony and bureaucratic organizations such as government will be the slowest to adapt, but private companies in a competitive environment will adapt their requirements capture approach to a more agile alternative or risk being left behind by their competitors that will be more “agile” in adapting both their business processes and the solutions that support them.